Can not change value in SYSTEM SETTINGS

MandieLao · 31 May 2017 01:06

I found that no matter what I change in SYSTEM SETTINGS, the setting restore to the default value after I saved it.

I checked the log and there’s something wrong as below:
Wed May 31 08:58:07 2017 [13426][1][FATAL] ERROR: rmdir_recursive(): argument cache/themes/Suite7/modules is not a file or a dir.
Wed May 31 08:58:07 2017 [13426][1][FATAL] ERROR: rmdir_recursive(): argument cache/themes/SuiteR/modules is not a file or a dir.

What’s wrong? All system settings can not be changed.

pgr · 31 May 2017 15:03

Is this Linux?

Can you check your permissions?

MandieLao · 1 June 2017 00:28

Yes,is Linux.
What permissions do you mentioned? All the CRM files are set to 777.

pgr · 1 June 2017 08:18

It’s not a good idea to use 777 permissions, it is extremely insecure. And it’s not necessary.

The correct configuration can be applied with something like this:


    sudo chown -R www-data:www-data .
    sudo chmod -R 755 .
    sudo chmod -R 775 cache custom modules themes data upload config_override.php

(notice the dots “.” in the end of some of those commands)

But you have to change that www-data:www-data to match your web server user. So the first task is to find out which user your web server runs under, if you don’t know yet.

What is your SuiteCRM version? In newer versions it’s easier to find this out (after v 7.8.3)

MandieLao · 1 June 2017 08:37

Hi,
My SuiteCRM version is 7.8.3 . Could you please tell me how can I find out which user my web server runs under?

pgr · 1 June 2017 08:40

Sure. Go to Admin / Schedulers and at the bottom of the list you will find some instructions about configuring cron jobs. Paste that information here so I can look at it.

MandieLao · 1 June 2017 08:45

Hi,
The information you mentioned is as below:
In order to run SuiteCRM Schedulers, edit your web server user’s crontab file with this command:
sudo crontab -e -u www
… and add the following line to the crontab file:

cd /data/wwwroot/default/CRM; php -f cron.php > /dev/null 2>&1

pgr · 1 June 2017 08:49

Ok, the user is “www” but I remember now that we have to check the group also.

Please post the results of running this command inside folder /data/wwwroot/default/CRM

ls -al

MandieLao · 1 June 2017 09:00

The result after run ls -al as below:
total 1476
drwxrwxrwx 18 root root 4096 May 8 00:17 .
drwxr-xr-x 6 www www 4096 May 7 23:51 …
drwxrwxrwx 15 root root 4096 May 8 00:17 cache
-rwxrwxrwx 1 root root 3590 Apr 10 20:43 campaign_tracker.php
-rwxrwxrwx 1 root root 462 Apr 10 20:43 composer.json
-rwxrwxrwx 1 root root 17908 Apr 10 20:43 composer.lock
-rwxrwxrwx 1 root root 891 Jun 1 08:34 config_override.php
-rwxrwxrwx 1 www www 10738 May 24 09:30 config.php
-rwxrwxrwx 1 root root 5052 Apr 10 20:44 cron.php
-rwxrwxrwx 1 root root 2446 Apr 10 20:43 crossdomain.xml
drwxrwxrwx 9 root root 4096 May 22 16:32 custom
drwxrwxrwx 3 root root 4096 Apr 10 20:44 data
-rwxrwxrwx 1 root root 2388 Apr 10 20:43 dictionary.php
-rwxrwxrwx 1 root root 12403 Apr 10 20:43 download.php
-rwxrwxrwx 1 root root 2392 Apr 10 20:43 emailmandelivery.php
-rwxrwxrwx 1 root root 4912 Apr 10 20:43 export.php
-rwxrwxrwx 1 root root 967627 Apr 10 20:43 files.md5
-rwxrwxrwx 1 root root 2811 Apr 10 20:43 HandleAjaxCall.php
-rw-r–r-- 1 www www 1376 May 22 16:24 .htaccess
-rwxrwxrwx 1 root root 2371 Apr 10 20:43 ical_server.php
drwxrwxrwx 56 root root 4096 Apr 10 20:44 include
-rwxrwxrwx 1 root root 2374 Apr 10 20:43 index.php
drwxrwxrwx 6 root root 4096 May 8 00:02 install
-rw-r–r-- 1 www www 32711 May 8 00:03 install.log
-rwxrwxrwx 1 root root 30016 Apr 10 20:43 install.php
-rwxrwxrwx 1 root root 13373 Apr 10 20:43 json_server.php
drwxrwxrwx 3 root root 4096 Apr 10 20:43 jssource
-rwxrwxrwx 1 root root 34539 Apr 10 20:43 LICENSE.txt
-rwxrwxrwx 1 root root 2313 Apr 10 20:43 log_file_restricted.html
-rwxrwxrwx 1 root root 2376 Apr 10 20:43 maintenance.php
-rw-r–r-- 1 www www 906 May 8 00:17 manifest.php
drwxrwxrwx 2 root root 4096 Apr 10 20:43 metadata
drwxrwxrwx 3 root root 4096 Apr 10 20:43 ModuleInstall
drwxrwxrwx 112 root root 4096 Apr 10 20:43 modules
-rwxrwxrwx 1 root root 2890 Apr 10 20:43 pdf.php
-rwxrwxrwx 1 root root 2655 Apr 10 21:12 README.md
-rwxrwxrwx 1 root root 73 Apr 10 20:43 robots.txt
-rwxrwxrwx 1 root root 3588 Apr 10 20:43 run_job.php
drwxrwxrwx 11 root root 4096 Apr 10 20:43 service
drwxrwxrwx 2 root root 4096 Apr 10 20:43 soap
-rwxrwxrwx 1 root root 4091 Apr 10 20:43 soap.php
-rw-r–r-- 1 www www 124750 May 8 00:02 sugarcrm.log
-rwxrwxrwx 1 root root 5327 Apr 10 20:43 SugarSecurity.php
-rwxrwxrwx 1 root root 154 Apr 10 20:43 sugar_version.json
-rwxrwxrwx 1 root root 2263 Apr 10 20:43 sugar_version.php
-rwxrwxrwx 1 www www 25019 Jun 1 08:34 suitecrm.log
-rwxrwxrwx 1 root root 168 Apr 10 21:13 suitecrm_version.php
-rwxrwxrwx 1 root root 957 Apr 10 20:43 testinstall.php
drwxrwxrwx 6 root root 4096 Apr 10 20:43 themes
-rwxrwxrwx 1 root root 5843 Apr 10 20:43 TreeData.php
drwxrws— 3 www www 4096 May 8 00:17 upgrade
-rwxr-xr-x 1 www www 490 May 8 00:17 upgradeWizard.log
drwxrwxrwx 4 root root 4096 May 23 16:39 upload
-rwxrwxrwx 1 root root 2707 Apr 10 20:43 vcal_server.php
-rwxrwxrwx 1 root root 2980 Apr 10 20:43 vCard.php
drwxrwxrwx 2 root root 4096 Apr 10 20:43 XTemplate
drwxrwxrwx 8 root root 4096 Apr 10 20:43 Zend

pgr · 1 June 2017 09:09

Ok, I think your system needs quite a bit of reconfiguration. the permisisons seem messed up (all those “root”-owned files).

Run these commands:


    cd /data/wwwroot/default/CRM
    sudo chown -R www:www .
    sudo chmod -R 755 .
    sudo chmod -R 775 cache custom modules themes data upload config_override.php

Then run

crontab -e -u root

This is root’s crontab. Make sure there is no line there running SuiteCRM’s cron.php (comment it with a # in the first column, if there is)

Then run

nano /etc/crontab

This is the system-wide crontab. Do the same, remove any cron.php line.

Then run

crontab -e -u www

and add this line, if it’s not already there:

* * * * * cd /data/wwwroot/default/CRM; php -f cron.php > /dev/null 2>&1

Now your permissions are fixed and shouldn’t be broken again in the future, if all goes well.

Run a Admin / Quick Repair and Rebuild.

After a few minutes check Admin / Schedulers and see if your cron jobs are running without errors.

MandieLao · 1 June 2017 10:02

Hi,
I have run the commands you mentioned step by step.
when run ‘nano /etc/crontab’ , there shows “no nano command”;
when run ‘crontab -e -u www’, there shows “no crontab for www - using an empty one”;

Is the corntab setting problem cause the problem “Can not change value in SYSTEM SETTINGS” ？

pgr · 1 June 2017 10:06

Hi, it would be nice to know which Linux you’re using so I can advise you better.

“nano” is just a text editor that ships with Ubuntu. You can use any other text editor (“vi” surely exists, if know how to use it!)

The permissions issues have many different manifestations. I believe your system settings problems will be solved by the permissions fix, but the only way to find is to try.

The cron tab issue is important for permissions. If crontab runs as user “root”, it will start messing with permissions because any file it writes will get root ownership (you had plenty of files like this). So if you don’t fix cron running as root problem, you fix permissions today but they will degrade again tomorrow…

It’s ok to start a new crontab for “www” and add that line there.

MandieLao · 1 June 2017 10:16

Thanks for your help.
I’m using Linux CentOS 7.2 .
So what can I do next? And how can I start a new crontab for “www”?
Sorry, I’m new here , there’re so many questions for me.

pgr · 1 June 2017 10:23

You said when you used this command

crontab -e -u www

the system replied it was starting a new empty crontab for that user. Go ahead and insert the line there, and save.

Regarding the system-wide crontab (text file /etc/crontab):

You can try just displaying its contents with


cat /etc/crontab

if there is no line mentioning cron.php there, you don’t need to do anything more.

If there is, you need to edit that file and remove the line. Do you know how to do that with VIM?

Or if you prefer a simpler editor (I recommend it), install nano with

yum -y install nano

MandieLao · 8 June 2017 02:12

I have try to do what you mentioned , but it seem that there’s nothing help to the problem “System Setting can not be changed”.
I have restored the CRM to another server with the same data, the System Setting can be changed normally. even though there’s the same error in log. Do you have any other idea？ Thanks!

pgr · 10 June 2017 10:34

No, I don’t have any more suggestions before you try these easy fixes. There is no point in looking for issues in SuiteCRM before you are sure your permissions set up (including cron jobs user) is working properly.

95% of problems with SuiteCRM come from that (which is actually a sysadmin failure, not the fault of the app), and the manifestations are pretty random. So it’s always worth checking, and nothing else is worth checking until that is guaranteed to be working well.