SuiteCRM 8.5.0
MariaDB 10.5.22
PHP 8.1.27
Yesterday, for no apparent reason, when running a quick repair and rebuild, it failed right at the start with an ‘Unexpected error when calling action’ error.
Result = total system crash.
On review, it had wiped the cache/prod directory leaving just a single .lock file. The system would not restart without the directory, locking out all users.
We restored the directory from the previous night back-up and all came back. Everything seems to run as normal, other than a minor issue with Accounts, whereby when viewing Accounts for the first time after login, a filter is in place which you have to clear to see all records. It is a specific filter that someone has clearly set for a speific account type. Clearing it is fine.
However, the Quick Repair still fails with the same issue and same effect.
This is not something we have seen before nor understand how to fix. There is clearly something wrong which is stopping it from running but we can’t fathom out what it is.
So short term, we are running and operational, but need to fix whatever it is causing the problem but no error in the SuiteCRM log (set to Fatal). I am going to look in the prod log and see if there is anything in there but wondered if anyone has had anything similar.
All help gratefully received.
I am quite certain that you have ownerships/permissions problems preventing SuiteCRM from writing files, particularly cache directory.
Sometimes these problems hinge on minor and strange details - Selinux, htaccess files, umask, SetGID and SetUID bits affecting how new files are created…
A proof of this would be examining your system while it is broken, and finding files with wrong ownerships or insufficient permissions.
Ok thank you. I will do exactly that. I will also check if anyone has changed any permissions, which may have been in error.
I can then get them changed back and sort this out.
Thank you. Better break it again and get started before Monday 
Wow, what a minefield this seems to be.
I have also read a bunch of older forum discussions around similar issues and it seems to be a fairly common issue if something goes wrong.
So, where I am is that the system seems to be messed up somehow. This is a Unix installation.
The config.php file has the directory and file settings ;
‘dir_mode’ => 493,
‘file_mode’ => 420,
user and group are both set as ‘’
Wheras the /include/utils.php has these as 02770 and 0755 respectively. No idea why or how. I can see that we did a rebuild of the config file a while back and this must be what was set and I just re-did it (this works OK) and these did not change.
The Quick Repair still fails and crashes the system after I have set permissions to 775 but as we don’t have root access on the managed platform, I did this manually for cache and all sub directories - still failed.
Clearly something majorly wrong that my skillset isn’t able to find. It seems that most of the directories that should be 775 are 755.
I am thinking of creating a fresh install and checking everything at the outset, and doing a compare to see where things have gone/are going wrong. We can continue to use the system as is and if really necessary, switch the database across to a new install, as a last resort.
Worrying that something has clearly happened, possibly self inflicted, but with no issue being flagged until the quick repair situation.
Any further suggestions much appreciated.
Just a couple of clarifications:
Permissions when used inside PHP are prefixed with a 0 to signify that you will use octal notation. (chmod values are in octal). When you see unfamiliar values saved in config_override, these are just the decimal forms of the same number.
If your files are owned by the same user that your web server is using to run, then the second digit won’t make a difference, and 755 will work just as well as 775. Only one digit is ever used for a certain file, for a certain owner. If “file owner” = “process user”, then it’s only the first digit.