503 Service Unavailable after adding module in Module Menu Filters section

💬 General Discussion
1

I am trying to identify the cause of an error that occurs when adding a new module in the Configure Module Menu Filters section. This happens when saving. After this when trying to visit the site I get the message 503 Service Unavailable and in the logs the message [Thu Sep 12 14:43:01.629325 2024] [core:notice] [pid 3655] AH00052: child pid 4085 exit signal Segmentation fault (11). It was identified that the error is solved after clearing the cache. Once the cache is cleared, it waits for what seems to be a variable number of minutes between 1 and 3 and the site becomes accessible again

I’ve been investigating and I’ve noticed two things

The permissions of the newly created modules have changed to drwxrwsr-x instead of rwx--S--- which is how the previous ones were

Another thing I notice is the cache permissions. The ready

drwxrwsr-x  11 www-data www-data  4096 Sep 23 12:48 ./
drwx------  23 www-data www-data  4096 Sep 23 12:46 ../
drwxrwsr-x   2 www-data www-data  4096 Sep 23 15:27 Relationships/
drwxrwsr-x   3 root     www-data  4096 Sep 23 12:48 cache/
drwxrwsr-x   2 www-data www-data  4096 Sep 23 12:48 dashlets/
drwxrwsr-x   5 root     www-data  4096 Sep 23 13:31 htmlclean/
drwxrwsr-x   3 www-data www-data  4096 Sep 23 12:48 include/
drwxrwsr-x  38 www-data www-data  4096 Sep 23 17:25 jsLanguage/
drwxrwsr-x 368 root     www-data 20480 Sep 23 14:46 modules/
drwxrwsr-x   5 www-data www-data  4096 Sep 23 12:48 smarty/
drwxr-sr-x   3 www-data www-data  4096 Sep 23 12:48 themes/

I notice that for example modules/ the owner is root. Is this relevant?

Could this be a permissions issue?

The error has been occurring for about a month.

Suitecrm version: 7.11.19
PHP version: 7.1.33
Apache version: Apache/2.4.29

I will appreciate your opinion. Greetings!

2

yes, it is ownership issue.

 sudo chown -R www-data:www-data .
  sudo chmod -R 755 .
  sudo chmod -R 775 cache custom modules themes data upload
  sudo chmod 775 config_override.php 2>/dev/null

Let us know, if it is working for you or not.

4

Hi. Thanks for answering. I understand that the first commands are for the whole project. Then specific permissions for cache, custom, modules, themes, data and upload. Could you explain the last one?

Could I run it alone?

sudo chmod -R 775 cache

Well, as I said, deleting cache solves the error.

Also in the cache directory I notice that the cache and modules directories are owned by root.

5

It sets permission to 775 for config_override.php

sudo chmod 775 config_override.php

this command sets the specified permissions on config_override.php, running as an administrator, and suppresses any error messages.

Yes, you can run that.

Mark answer as solution :white_check_mark: which solved your issue, so it will help others in the future

6

The ownerships are very relevant and they should not be root.

The reason they become root is because some process running under root touched those files. The most typical situations are:

  • you log in as root, via shell, SSH, FTP, etc, and edit the files or move them around
  • your cron jobs are running as root user

Both of these things shouldn’t happen. Ownerships in SuiteCRM should be stable, and you shouldn’t need to reset them after the first time. This might not be easy to achieve in real life, but at least it should be the goal.

A couple more things to check:

  • default_permissions entry in your config.php
  • if you notice that new files are created with wrong ownerships or permissions in a specific directory (such as cache), check the SetOID and SetGID bits on the parent directory.
7

Hi, thank you very much for your reply. Could you please confirm that these are the correct permissions?

'default_permissions' =>
array (
'dir_mode' => 1533,
'file_mode' => 436,
'user' => '',
'group' => '',
),
8

It depends on your case, but it’s something like this:

'default_permissions' =>
array (
'dir_mode' => 02775,
'file_mode' => 0775,
'user' => 'yourWebServerUserHere',
'group' => 'yourWebServerGroupHere',
),

Note the leading 0 in the numbers, that signals to PHP that you’re using octal notation, which is what those more familiar permissions values are written in. Then after QR&R that might get turned into the equivalent decimal (like the values you have now, without leading 0).

9

I was not familiar with the terms SetOID and SetGID. I did some research and identified the SetGID bit is set. These are the permissions of cache/

drwxrwsr-x

So new files or directories inside cache/ should inherit the group www-data

Regarding the state of directories with owner root inside cache/ they were probably executed by a user who changed privileges to root and not the correct user

I do not have the authority to test if this solves the original problem. I will make the suggestion, as soon as it is done I will leave a comment

Thanks

1 Like
10

Hi Mario,

The following points can be done to resolve the mentioned error:

  1. Check File Ownership:

It’s important that the web server user (e.g., www-data for Apache) has ownership of the necessary files and directories. If directories like modules/ and cache/ are owned by root, this could lead to access issues.

sudo chown -R www-data:www-data /path/to/your/suitecrm

  1. Adjust Permissions:

Ensure that directories have the correct permissions. A typical permission setting would be 755 for directories and 644 for files. For the cache directory, ensure it is writable by the web server user:

find /path/to/your/suitecrm -type d -exec chmod 755 {} ;
find /path/to/your/suitecrm -type f -exec chmod 644 {} ;

  1. Fix Cache Directory Permissions:

If the cache directory has the wrong owner or permissions, it can cause the application to fail. Correct the permissions:

sudo chown -R www-data:www-data /path/to/your/suitecrm/cache
sudo chmod -R 775 /path/to/your/suitecrm/cache

  1. Increase PHP Memory Limit:

Sometimes, segmentation faults can occur due to insufficient memory. Consider increasing the PHP memory limit in your php.ini file

After making these changes, restart Apache