Trying for the 4th month to get a nice working installation of v8 without errors or directory permissions being changed. It is a challenge because most known errors could be preflighted before installation but that is really the missing component as I see it. Before installation, we should be checking directories, php versions, permissions, tmp file settings, cron user settings, urls and other things that somehow get changed after installation. Also, the preflight should be warning of any connected db that will get wiped. Today, installed then ran the permissions again before logging in and then somehow SuiteCRM or Linux changed directories to:
I see where PHP settings will adjust the SESSID tmp directory permissions and those can be adjusted in the php.ini file. But why do cache directories get permissions changed? Anyone? How can we prevent that? It seems that whatever is doing that is triggered by an ADMIN function.
I think if we could get the permissions not changing, life would be so much easier for V8 users and if there was a way to pre-check permissions before installation, life would be way better for newbies.
With respect, I do not believe that is a correct explanation. I set parent folders according to the install instructions. The program is installed. It runs fine. Once a change is made in admin setting and cache directories are created then things stop working and analysis shows weird permission settings as I posted above.
My user and group is “crm” and those are not changed anywhere and the program runs under that user.
I use DEBUG setting for the logs but no permission changes are visible so I do not think file settings are disclosed in the SuiteCRM debug logs. If we could implement some debugging code to show where these files are created and list the permissions I think SuiteCRM installation might become more productive. I see it online here that “resetting” permissions is the #1 impediment to adoption. We continually tell users to reset permissions & reset directory ownerships. No other program I’ve ever worked with behaves this way during install or post-install. I’m willing to help debug if we can narrow where to look but I am not the only one with mangled permissions and many more have likely given up. It is a serious issue and an impediment to adoption.
I don’t tell users to reset permissions and ownerships recurrently, I tell them to fix their installation correctly, and only once.
I do agree with you that SuiteCRM needs to improve, but it’s more of a transparency thing, helping people find out what is really going on. Other programs typically don’t write themselves (like SuiteCRM does when you do things in Studio) so they don’t have the same requirements and are simpler to install.
Is your web server Apache? If so, please run this command and tell me what it returns:
Ubuntu 20.04 LTS, dedicated test server v8.5: I’ve moved on to v8.5 which is better but still SuiteCRM is modifying permissions on this new test server. I have reset twice over the last few months and now having lots of errors so I did another check of the permissions using the command showing at the bottom of this image. Of course, we know it is SuiteCRM doing the permission changes when it creates new directories so it would make sense for the developers to allow those settings to be set at installation in a config file or other means. Until then, everyone here with ongoing errors will have to run the permission scans and re-permission changed directories and files including every new installation. How can anyone think that isn’t something to be coded? I would help find those spots in the code if I could use Codespace since this repo is located on Github and Codespace is free and does not require a testing server or any software on my computer. Testing and debugging would be virtual and quick. Some day we’ll get this done.
We will clean this up again with the instructions from this site. So, for new users, be prepared to have your server messed up by SuitecCRM with permissions mangled for directories and files. Some people actually run CRON jobs to check and fix permissions on a regular basis. This is the single biggest challenge to installation and usability IMO–an application that screws with your server.
Edit: All the file permissions are mangled again also.
find . -type -not -perm 0644
returns the entire list of cached files
A properly configured server will not change ownerships and permissions.
I never use, and never recommend, using those scripts to reset things, because they’re not needed, and using them only hides the cause of the problem.
Sometimes there are Linux issues that affect this, and that people are unaware of. Things like umask, and the setuid bits on the parent directory affecting the permissions of created files.
Hi Paul @pjdm
When you go to your Linux terminal,
and then cd to the base directory of your Suite 8.5 e.g. cd /home/suite85/public_html,
and then cd public/legacy
What’s the output of this command?:
