QuickCRM Mobile gives you access to SuiteCRM on your mobile, your tablet (iPhone, iPad, Android) or your laptop with QuickCRM native apps available on App Store, Google Play and Windows Store.
#2318 - Migrated suitecrm to new proxy'd container and mobile app won't connect, web interface is broken
I just migrated Suitecrm 7.11.8 to a new web-facing container (initially running it internally). I'm using NGINX to proxy a single real IP to multiple webapp containers securely with SSL (with redirection of 80 to 443).
The mobile app will not connect via the working dns name. It tells me the app requires the server piece, which is installed and registered. I've checked the permissions listed in the error, and all permissions are assigned to www-data in all the areas listed. I've tried http and https to no avail. When I connect with browser to /mobile, all of the images are broken.
Any help would be greatly appreciated.
- Most Recent Love from Users
atsakaliscrm- Ricardo Cairello
- gabriel1
- PLAN42 AB
- Ricardo Cairello
- chrisely
5 years ago
Hi,
First of all, please update your app to 6.8.4 if you are using Android. Also, redirections only work from browser. Can you check changing http to https in the app settings?
5 years ago
I am running the most current version. It looks like there are major permission issues. I've attached the console from the broken /mobile. I've uninstalled and reinstalled the module a couple of times. attempted the quickcrm check/upgrade as well as a quick repair of suitecrm.
5 years ago
5 years ago
You have to check permissions and ownership for these files and their folders.
5 years ago
I've recursively changed the entire mobile subdirectory to 777 after trying smaller r/w modifications. Everything is assigned www-data as user, and I'm using apache2.
5 years ago
I've also tried uninstalling the module, physically deleting the mobile folder, and re-installing the module to no avail.
5 years ago
1- If www-data is the owner of all files and folders inside your SuiteCRM root folder, 777 is not useful. Permissions should be maximum 755/644 Some servers refuse files writable by group (you might see this error in your PHP error log). 2- If the error persists, then, the problem might come from .htaccess file in /var/html/suitecrm or in /var/html
5 years ago
Thanks NS-Team. all of my permissions were 755 for www:data initially, and reset now. I've found that the latest suitecrm upgrade is what seems to be causing my issues, as other things like studio and dropdown editor aren't loading either. I have a feeling once I get these issues resolved, quick will work as expected. Please leave this open so I can update in case others experience the issues I'm having.
5 years ago
I believe 7.11.8 has quite a few problems. .htaccess file is one of them. You should stick to LTS versions which are much more stable. (But it’s too late now as you can’t downgrade)
5 years ago
Hi,
I found the problem with SuiteCRM 7.1.8: In .htaccess, you can see RedirectMatch 403 (?i)/+custom RedirectMatch 403 (?i)/+lib
If you remove or comment those two lines, it should work.
5 years ago
Awesome. Thank you. I got everything working again. It came down to 2 issues... 1. The htaccess - I actually deleted it, and suitecrm recreated it without issues. As soon as I did a rebuild in suitecrm on the .htaccess, it broke again (I'm sure due to the lines you reported). I ended up deleting and not rebuilding the file, and everything is working. Later I'll try rebuilding, and then commenting out the lines your referring to.
This was from a vanilla install using the downloaded Suitecrm 7.1.8 for linux, in a Ubuntu 18.04 lxd container, Apache2, php 7.2, with only the DB imported into the new install.
Thanks for your help, even though my issue fell outside of your software. That's awesome!
5 years ago
Hello again,
I didn't have to create a suitecrm/cache/index.php file to allow Studio and other features. But I had to remove in htaccess: RedirectMatch 403 (?i)/+build RedirectMatch 403 (?i)/+vendor You might not have had these problems if the files were in your browser cache, but they would appear if you clear your browser cache.
5 years ago
Thanks again. I rebuilt the .htaccess, and then applied your suggestions, and all good.