Hi,
i use suitecrm day in and day out.
oftentimes it has âundefinedâ elements appear, so if i F12 it - i will see 403 on specific files.
that is because the permissions on my unix centos change from 0644 and 0755 to 0600 and 2700. or sometimes other permissions. very often it is en_us.js file. the issue is that even if i manually change it back to 0644 it will change to 0600 again and again.
any solution for me on how to keep the permissions 0644? besides for running a cron jobs
Hi,
It sounds like you dont have the settings correct in the config.php. When Suite modifies a file or recreates a file on repair it will set the nessisary settings for the file. In the Config.php file there is a section as follows.
array (
'dir_mode' => '1517',
'file_mode' => '420',
'user' => '{server_user}',
'group' => '{Server_group}',
),
these settings are the comon ones we use however they may differ slightly between servers.
Hope that helps.
Ian.
As I have already highlighted in another post this is THE problem that has to be solved within SugarCRM (and all its forks).
The SugarCRM code is written in an inconsistent way and the config.php permissions settings are not always respected.
This leads to a huge mess with huge malfunctioning and, at times, this problem makes the instance unusable so you have to proceed with a clean install (with all the consequences involved!)
I believe that the most attention of developers should be towards solving this huge problem for once and for all!
Although not fatal, this issue is really present and anoying.
Personally, I perform a chmod on an hourly basis (via cronjob).
âundefâ messages almost dissapeared.
A chmod ran hourly doesnât overload my cheap server and cronjob are easy to setup.
Sure, itâs not elegant, but why not use cronjobs ?
I guess you can use cron jobs to chmod/chown SuiteCRM however you do not need to as long as you set up the settings in the config file correctly. this would remove the hassle of setting up a cronjob and the script to do the work. as long as you get the config settiungs correct then you should not see any more of these undefined elements.
doing this as a cronjob does fix the issue every hour but there is also the rest of the hour which the system is unsetting the work that the cron job has just done which might cause problems with other things and not just the undefined elements that you see on the page. e.g the error log.
Thanks.
Ian,
I wish it were the way you say.
Unfortunately the truth is different:
Continuously changing permissions
Even if you set them up correctly permissions keep on changing to any figure. (most of them are similar, but some have completely different values)
So the only solution is a:
Cronjob to reset them back to the initial starting point.
I have made a script (see below), which I run every ten minutes and it takes just under 10 seconds to execute.
Unfortunately, as you say it will leave me uncovered for 10 minutes and this is a true problem, because, when something happens because of bad permissions, it has happened to me that the damage was irreparable and Iâve hade to proceed with a fresh install (which takes a long time and it is quite hard to back everything up once the system is broken so some data gets lost!)
Fatal vs non Fatal issue
Xar says that, for him, âAlthough not fatal, this issue is really present and anoying.â.
I cannot disagree more!
In a production envirnment with users who have not a clue of how the system works the undefined error is not admissible and it is Fatal!!! If it continues, after sometime everybody will want to throw this system away!!!
The worst thing is that the undefined error is not the only one. Most of the times wrong permissions lead to huge problems in SugarCRM.
For these two reasons (1. Make the system usable by non technichal people and 2. Avoid really fatal errors) for me this is the number one priority within SugarCRM and its derivative forks, including SuiteCRM.
I bet you that IBM, which recently switched to SugarCRM (pro), has obliged them to solve this issue in the Pro edition so, if it has been solved there it can be solved also in the Community Edition. The problem is that SugarCRM is a company and if the Community Edition was perfect nobody would buy their pro editions!!!
As I promised here is the code of my cronjob which runs every 10 minutes:
<?php
// $script_time_start = microtime(true);
function chmod_file_folder($dir) {
global $perms;
$dh=@opendir($dir);
if ($dh) {
while (false !==($file = readdir($dh))) {
if($file != "." && $file != ".." && !in_array($file, $perms['exclude_folders']) && !in_array($file, $perms['exclude_files'])) {
$fullpath = $dir .'/'. $file;
if(!is_dir($fullpath)) {
chmod($fullpath, $perms['file_perms']);
}else {
chmod($fullpath, $perms['dir_perms']);
chmod_file_folder($fullpath);
}
}
}
closedir($dh);
}
}
$change_folders = array();
$change_folders[]=array('change_dir' => '.',
'file_perms' => 0755,
'dir_perms' => 0755,
'exclude_folders' => array('cache', 'custom', 'data', 'modules', 'themes', 'themes'),
'exclude_files' => array('config_override.php')
);
$change_folders[]=array('change_dir' => 'cache',
'file_perms' => 0775,
'dir_perms' => 0775,
'exclude_folders' => array(),
'exclude_files' => array()
);
$change_folders[]=array('change_dir' => 'custom',
'file_perms' => 0775,
'dir_perms' => 0775,
'exclude_folders' => array(),
'exclude_files' => array()
);
$change_folders[]=array('change_dir' => 'data',
'file_perms' => 0775,
'dir_perms' => 0775,
'exclude_folders' => array(),
'exclude_files' => array()
);
$change_folders[]=array('change_dir' => 'modules',
'file_perms' => 0775,
'dir_perms' => 0775,
'exclude_folders' => array(),
'exclude_files' => array()
);
$change_folders[]=array('change_dir' => 'themes',
'file_perms' => 0775,
'dir_perms' => 0775,
'exclude_folders' => array(),
'exclude_files' => array()
);
foreach ($change_folders as $this_folder)
{
if(isset($perms))
unset($perms);
$perms = array();
$perms['file_perms'] = $this_folder['file_perms']; // chmod value for files don't enclose value in quotes.
$perms['dir_perms'] = $this_folder['dir_perms']; // chmod value for folders don't enclose value in quotes.
$perms['exclude_folders'] = $this_folder['exclude_folders']; // list of folders to exclude
$perms['exclude_files'] = $this_folder['exclude_files']; // list of files to exclude
chmod_file_folder($this_folder['change_dir']);
// echo "Changed permissions to: " . $this_folder['change_dir'] . " with : " . $perms['dir_perms'] . "<br>";
}
chmod('config_override.php', 0775);
// $script_time_total = microtime(true) - $script_time_start;
// echo "The script was executed in: " . $script_time_total . " seconds";
?>Thatâs it, I solved it permanently, without cron jobs! B)
Kind regards,
George Mogilevsky
CEO,
Methodical Solutions
george@methodicalsolutions.com
1 514 718 1169
2550 Chemin Bates, Bureau 107,
Montréal, QC H3S 1A7
1 514 718 1169 | www.methodicalsolutions.com
Config doesnât fix all of the issues. I have a different permanent fix that actually works.
Kind regards,
George Mogilevsky
CEO,
Methodical Solutions
george@methodicalsolutions.com
1 514 718 1169
2550 Chemin Bates, Bureau 107,
Montréal, QC H3S 1A7
1 514 718 1169 | www.methodicalsolutions.com
Dear George,
could you please share with everybody the way you solved this issue?
It will be useful for the whole community!
Thanks!
I regularly run into the same problem and was thinking about doing the same, I found the following bash script which also does the job and all you need to do is update the first lines to match your installation:
#!/bin/bash
APACHEUSER=âwww-data:www-dataâ
SUGARPATH=â/var/www/sugarcrmâ
find -P $SUGARPATH/ -type d -exec chmod 755 {} ;
find -P $SUGARPATH/ -type f -exec chmod 644 {} ;
find -P $SUGARPATH/ -name *.js -exec chmod 755 {} ;
chmod 664 $SUGARPATH/config.php
chmod 664 $SUGARPATH/config_override.php
chmod 664 $SUGARPATH/sugarcrm.log
find -P $SUGARPATH/cache -type d -exec chmod 775 {} ;
find -P $SUGARPATH/custom -type d -exec chmod 775 {} ;
find -P $SUGARPATH/data -type d -exec chmod 775 {} ;
find -P $SUGARPATH/modules -type d -exec chmod 775 {} ;
find -P $SUGARPATH/include -type d -exec chmod 775 {} ;
find -P $SUGARPATH/upload -type d -exec chmod 775 {} ;
find -P $SUGARPATH/cache -type f -exec chmod 664 {} ;
find -P $SUGARPATH/custom -type f -exec chmod 664 {} ;
find -P $SUGARPATH/data -type f -exec chmod 664 {} ;
find -P $SUGARPATH/modules -type f -exec chmod 664 {} ;
find -P $SUGARPATH/include -type f -exec chmod 664 {} ;
find -P $SUGARPATH/upload -type f -exec chmod 664 {} ;
chown -R $APACHEUSER $SUGARPATH
So why not share it George so we can all benefit from your wisdom???
Do you mind sharing your solution?
Hello,
Perhaps it is because he has not been logged in for a long time. ItÂŽs an old TopicâŠ
Not only config.php is responsible for permissions. Records that are written are defined by the configuration in the utils.php (include / utils.php)
The same configuration as in the config.php should be made here; otherwise, SuiteCRM permanently changes the permissions.
Iâve recently examined a system where the cron job was running under the user ârootâ instead of the regular web server user. It was basically a misconfiguration of crontab.
That was causing permissions problems since cron would create files and dirs as root, and then the regular SuiteCRM app running from the web server couldnât access them.
The interesting part of this case is that, for once, I actually got a rational, coherent explanation as to why and how these permissions problems were being generated. I suspect a LOT of people out there have exactly this problem.
YES! All of this happened when I got crontab working. How do you get it to run under the right user and not under root then? Please help.
You can access individual user crontabs with the â-uâ option, like this:
sudo crontab -e -u www-data
Notice that that works even for users who canât login to a shell (like is frequently the case the web server user).
Remember to remove from the ârootâ crontab", and add to the web server user crontab.
Alternatively, in Ubuntu 16.04 I see that
sudo nano /etc/crontab
⊠takes you to a âsystem-wide crontabâ which has an extra column to specify username.
To other people: if you also have cron running as root, please report back here, it would be useful to know. And make sure you fix it, itâs important! Thanks everyone.
I would love to get some feedback on this important issue.
Is anybody out there running cron.php as root? Does changing that solve ALL your permissions degradation problems? It solved mineâŠ
Hi,
I just checked my crontab and itâs running under a username, not under root. You are saying I should run it under a user correct? What about the group the user belongs to? Is that relevant?
Thanks,
Ryan
Hi.
The âscientificâ, precise, rule is:
[quote]Your cron jobs should run under a user such that any file created or modified by them does not create permissions problems when the main app, running under the web server user, tries to access them.
[/quote]
The practical, straightforward rule for most cases is:
[quote]Find out which user your web server runs under, and use that same userâs crontab to run the scheduler jobs.
[/quote]
If itâs the same user, it belongs to the same groups, so you donât have to worry about groups. If you take a more complicated route, with a different user, then the groups may be relevant.
And the always applicable, always true, often unknown rule is
Thank you very much for the reply. Yes, my cron is scheduled under the user, e.g. âbitnamiâ. Now, my app is also under user/group bitnami/bitnami, BUT when the cron runs, I see some directories and file permissions change to bitnami/daemon. This doesnât break anything except that when I try to upgrade suitecrm, the check on the file system, gives me an error, and I have to keep chancing file and directory permissions before performing an upgrade. Any ideas how I can keep the group the same?
Thanks in advance for your help.
Ryan