New installation issues

JeroenNLL · 10 May 2021 11:01

Hello Everyone,

I’m trying to test suite CRM to see if it fits our needs.

Installation itself went pretty easy except for the permission part where suiteCRM says;

Set the correct permissions on the SuiteCRM directory (Linux):

  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

That www-data needs to be replaced by the actual system user that your web server runs under. This varies depending on your operating system. Common web server users are as follows:

www-data (Ubuntu Linux/Apache)
apache (Linux/Apache)
nobody (Linux/Apache)
IUSR_computerName (Windows/IIS) The commands/steps taken to setting permissions differ depending on your operating system. If you are experiencing issues with setting permissions on your SuiteCRM instance, visit our support forums.

I’m using CentOS Webpanel for this setup and the only user i found that showed the interface was;
the user account/group that was made while creating a new user inside CentOS Webpanel.
let’s say i had to use
chown -R test12345:test12345 /home/test12345/public_html/* (account name is not real, but for the idea).

After this i can login and go threw settings etc.

The first 2 things i run into that show issues are;

when trying to import accounts i get 403 forbidden on ./index.php (permissions have been set according to the above)
setting up outgoing mail works flawless, connecting to a mailbox seem to timeout.

When running diagnostics i get the below

Sun May 9 11:23:38 2021 [1410028][-none-][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Sun May 9 11:23:44 2021 [1410028][-none-][FATAL] User update error: Temp User is not retrieved at ID 1, boolean given
Sun May 9 11:23:44 2021 [1410028][-none-][FATAL] Email address save error
Sun May 9 11:23:45 2021 [1410028][1][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Sun May 9 11:23:46 2021 [1410028][1][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Sun May 9 11:23:46 2021 [1410028][1][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Sun May 9 11:23:47 2021 [1410028][1][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Sun May 9 12:35:30 2021 [1415336][1][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Sun May 9 12:37:03 2021 [1415434][1][FATAL] log call at: modules/EmailMan/tpls/config.tpl:465 - styleChecked is not set
Mon May 10 09:59:09 2021 [1483743][1][FATAL] log call at: modules/EmailMan/tpls/config.tpl:465 - styleChecked is not set
Mon May 10 10:36:24 2021 [1486437][1][FATAL] SugarBean::populateDefaultValues $field_defs should be an array
Mon May 10 10:36:42 2021 [1486457][1][FATAL] Mysqli_query failed.
Mon May 10 10:36:42 2021 [1486457][1][FATAL] Query Failed: DESCRIBE versions: MySQL error 1146: Table ‘test12345_wrfaerf.versions’ doesn’t exist
Mon May 10 10:36:42 2021 [1486457][1][FATAL] Mysqli_query failed.
Mon May 10 10:36:42 2021 [1486457][1][FATAL] Query Failed: SHOW INDEX FROM versions: MySQL error 1146: Table ‘test12345_wrfaerf.versions’ doesn’t exist
Mon May 10 10:36:42 2021 [1486457][1][FATAL] Mysqli_query failed.
Mon May 10 10:36:42 2021 [1486457][1][FATAL] Query Failed: select * from versions: MySQL error 1146: Table ‘test12345_wrfaerf.versions’ doesn’t exist

pgr · 10 May 2021 11:57

If you can see the SuiteCRM UI and log in, the best way to get the exact user name you should be using for ownerships is by going in Admin / Schedulers and seeing the crontab instructions at the bottom. That is the username under which your web server is running.

It is important that the ownerships and permissions are correct before running the installer, so that it can do a proper install.

JeroenNLL · 10 May 2021 13:56

First of all thanks for your reply!

According to Admin / Schedulers i’m using the right username.
The ownerships and permissions are like required.

I tried a complete reinstall again and when u set permissions and ownership before the install i had todo it again after install otherwise it only shows text.

After setting ownership and permissions again after the install (install showed everything OK).
images and layout look correct.

As soon as i try to import i get

Forbidden

You don’t have permission to access /index.php on this server.

The import file does show up in the upload folder.
Permission of the file is 0644 after the try
Changing that file with permissions according to above doesn’t change anything.

Any ideas?

pgr · 10 May 2021 14:10

That sounds like web-server configuration issues.

Check selinux (if you have it), .htaccess file, and http vs https issues…

JeroenNLL · 10 May 2021 16:27

Webserver is
Nginx -> Apache
SELINUX=disabled

Since Nginx doesn’t use .htaccess could that be the problem?

I also prefer turning off http and redirect all http traffic to https

pgr · 10 May 2021 16:47

Can you get an error from the web server log when that import fails?

JeroenNLL · 10 May 2021 20:45

I changed server / domain main parts.

Modsecurity seems to have issues, is there any preferred way on i think this false positive?
And is the permission for the .htaccess file related to that since that file does not exist?

Thanks in advance

2021/05/10 15:49:27 [crit] 1458585#0: *7936 openat() "/home/test123/public_html/cache/jsLanguage/Import/en_us.js" failed (13: Permission denied), client: 212.187.70.244, server: test,example.com, request: "GET /cache/jsLanguage/Import/en_us.js HTTP/2.0", host: "test,example.com", referrer: "https://test,example.com/index.php"
2021/05/10 15:49:27 [crit] 1458585#0: *7936 openat() "/home/test123/public_html/cache/jsLanguage/Import/en_us.js" failed (13: Permission denied), client: 212.187.70.244, server:/test,example.com, request: "GET /cache/jsLanguage/Import/en_us.js HTTP/2.0", host: "test,example.com", referrer: "https://test.example.com/index.php"
[Mon May 10 15:49:27.453211 2021] [core:crit] [pid 1486180:tid 140509049714432] (13)Permission denied: [client 212.187.70.244:35848] AH00529: /home/test123/public_html/cache/jsLanguage/Import/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/test123/public_html/cache/jsLanguage/Import/' is executable, referer: https://test,example.com/index.php
[Mon May 10 15:49:35.336132 2021] [:error] [pid 1486180:tid 140509066499840] [client 212.187.70.244:35858] [client 212.187.70.244] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(?i:[\\"\\\\'][ ]*(([^a-z0-9~_:\\\\' ])|(in)).+?\\\\(.*?\\\\))" at ARGS:firstrow. [file "/usr/local/apache/modsecurity-owasp-old/base_rules/modsecurity_crs_41_xss_attacks.conf"] [line "506"] [id "973335"] [rev "2"] [msg "IE XSS Filters - Attack Detected."] [data "Matched Data: \\x22,\\x22Organization Status\\x22,\\x22Website\\x22,\\x22Primary Email\\x22,\\x22Primary Phone\\x22,\\x22Industry\\x22,\\x22Organization Number\\x22,\\x22Renting from\\x22,\\x22Modified Time\\x22,\\x22Type\\x22,\\x22Created By\\x22,\\x22Assigned To\\x22,\\x22Source\\x22,\\x22Created Time\\x22,\\x22Last Contacted Via\\x22,\\x22Is Converted From Lead\\x22,\\x22Billing Country\\x22,\\x22Email Opt Out\\x22,\\x22SMS opt-in\\x22,\\x22Email Opt-in\\x22,\\x22Last Contacted On\\x22,\\x22Last Modified By\\x22,\\x22Request count\\x22,\\x22Email..."] [ver "OWASP_CRS/2.2.9"] [maturity "8"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A2"] [tag "OWASP_AppSensor/IE1"] [tag "PCI/6.5.1 [hostname "test,example.com"] [uri "/index.php"] [unique_id "YJk570S@MuGs@iVfNbBfpgAAARI"], referer: https://test,example.com/index.php

pgr · 10 May 2021 21:03

I’ve never seen those errors, it’s something specific to your set up.

There’s an aspect of permissions that might be playing a role here. Depending on several settings, sometimes you can get permissions set correctly but then they degrade. This would be consistent with finding troubles in the cache directory like you’re seeing, because the cache isn’t there initially, it only gets created later.

You can check this by looking at the permissions on those files mentioned in your errors.

Possible causes:

if you’ve set up the Scheduler jobs (cron), they could be running as the wrong user and messing up ownerships
Check this array in your config.php:

'default_permissions' =>
     array (
    'dir_mode' => 1528,
    'file_mode' => 493,
    'user' => 'www-data',
    'group' => 'www-data',
  ),

Check the SetOID and SetGID bits on your directory permissions. They influence which rights are attributed to newly created directories.

JeroenNLL · 11 May 2021 14:40

The cron user is 100% correct since the beginning.

Looking at that array in config.php it was like below and now i added the correct username/group in there.

array (
‘dir_mode’ => 1528,
‘file_mode’ => 493,
‘user’ => ‘’,
‘group’ => ‘’,
),

I was able to find the rules for modsecurity that needs to be disabled for SuiteCRM to work.

If anyone else find modsecurity blocking SuiteCRM functions add the rules below to the domain/user config files of modsecurity.

Rules for SuiteCRM

########################################

SecRuleEngine On
SecRuleRemoveById 973335
SecRuleRemoveById 973334

Pages get loaded correctly now but i still see the complaints about .htacces file not found in nested cache dirs.

Do these files normally get created by the package, should i redo the install or can i just copy the needed files somewhere?

pgr · 11 May 2021 15:39

I’m not sure what to say to this. I don’t have experience with ModSecurity, I always use Ubuntu which is more straight-forward to use with SuiteCRM then CentOS.

Any CentOS fans out there can shed some more light on this?

cherub-chum · 11 May 2021 18:56

Core .htaccess should be created after installation. You can also generate that via Admin -> Repair and then Rebuild .htaccess file.

What are the details of error that are logged.

JeroenNLL · 11 May 2021 19:29

Ill try that rebuild and see if it works, the error about the .htacces file is as below and inside the apache logs;

[Tue May 11 21:24:19.452200 2021] [core:crit] [pid 1620720:tid 140542788687616] (13)Permission denied: [client 123.123.123.123:49314] AH00529: /public_html/cache/jsLanguage/Accounts/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that ‘/public_html/cache/jsLanguage/Accounts/’ is executable, referer: /index.php?action=ajaxui

JeroenNLL · 11 May 2021 19:59

That rebuild function says to complete but /public_html/cache/jsLanguage/Accounts/.htaccess is not recreated or similar when using other functions same errors about .htacces files in several nested directories.

I also run into another weird issue.

When i make 1 account, i export that account to (default) accounts.csv then i try to import that csv file and it errors out on wrong email, below is what i find in suitecrm.log at that time, in apache log mostly complains about missing .htaccess files in several subdirectories.

Tue May 11 19:49:08 2021 [1665966][1][FATAL] Caught error: stat(): stat failed for upload/import/error_1.csv
Tue May 11 19:49:08 2021 [1665966][1][FATAL] Caught error: touch(): UploadStream::stream_metadata is not implemented!
Tue May 11 19:49:08 2021 [1665966][1][FATAL] Caught error: stat(): stat failed for upload/import/status_1.csv
Tue May 11 19:49:08 2021 [1665966][1][FATAL] Caught error: touch(): UploadStream::stream_metadata is not implemented!
Tue May 11 19:50:23 2021 [1666187][1][FATAL] Caught error: stat(): stat failed for upload/import/error_1.csv
Tue May 11 19:50:23 2021 [1666187][1][FATAL] Caught error: touch(): UploadStream::stream_metadata is not implemented!
Tue May 11 19:50:23 2021 [1666187][1][FATAL] Caught error: stat(): stat failed for upload/import/status_1.csv
Tue May 11 19:50:23 2021 [1666187][1][FATAL] Caught error: touch(): UploadStream::stream_metadata is not implemented!

pgr · 12 May 2021 10:07

Maybe you’re missing some PHP module. These are the ones I normally install on Ubuntu for PHP 7.3 (don’t use PHP 7.4, it’s not compatible):

apt install zip unzip php-mbstring php7.3-mbstring php-gettext php7.3-xml php7.3-zip php7.3-imap php7.3-gd php7.3-curl php7.3-intl php7.3-mysql php-gd phpmyadmin

JeroenNLL · 12 May 2021 10:50

i’m using PHP version: 7.4.16

Loaded modules
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
pspell
Reflection
session
SimpleXML
soap
sockets
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib

So i need to downgrade i guess, let me check that today and ill get back about it

JeroenNLL · 12 May 2021 12:14

Ok, new resume!

Downgraded to You are running PHP version: 7.3.27

Loaded PHP Modules:

[PHP Modules] bcmath bz2 calendar Core ctype curl date dom exif fileinfo filter ftp gd gettext gmp hash iconv imap intl json libxml mbstring mysqli mysqlnd openssl pcntl pcre PDO pdo_mysql pdo_sqlite Phar posix pspell Reflection session SimpleXML soap sockets SPL sqlite3 standard sysvmsg sysvsem sysvshm tidy tokenizer wddx xml xmlreader xmlrpc xmlwriter xsl zip zlib [Zend Modules]

Complete new installation

setting permissions before install using:

[root@server public_html]# chmod -R 755 ./
[root@server public_html]# chmod -R 775 cache custom modules themes data upload
[root@server public_html]# chmod 775 config_override.php 2>/dev/null
[root@server public_html]# chown -R username:group ./*

after install css and images are not loaded.
have todo [root@server public_html]# chmod -R 755 ./ again to make everything show up as intended.

/server_path/public_html/cache/jsLanguage/Administration has 2770 rights on folder
the .htaccess file that should be copied into that directory is not there…

When trying to import 1 account that has been manually created and then exported i get 2 issues for sure.

complaints about the id being to long field…
complaints about the Error Invalid Email address field

Both of these are exported from the same install

Any ideas on where to investigate further?

pgr · 12 May 2021 14:55

What do you have in config.php, default_permissions now?

If you have any scheduler jobs set up, under which user are they running?

(You can check by running both crontab -l -u root and crontab -l -u username)

The only other thing that comes to mind is aggressively setting the bits on the directories with something like:

find <you suitecrmroot path> -type d -exec chmod 2750 {} +

The point of this would be ensuring that new directories get as much permissions as their parents. But this command isn’t usually needed and I am not sure what makes your set up different.

If eventually you decide to change to Ubuntu you can expect a much more hassle-free installation. Although there is no acceptable reason why it is turning out to be so hard in CentOS…

JeroenNLL · 12 May 2021 16:58

  array (
    'dir_mode' => 1528,
    'file_mode' => 493,
    'user' => '',
    'group' => '',
  ),

This is what i end up with in config.php

And below what SuiteCRM is saying itself in scheduler and how i set it up.

In order to run SuiteCRM Schedulers, edit your web server user’s crontab file with this command:
sudo crontab -e -u test123
… and add the following line to the crontab file:
* * * * * cd /home/test123/public_html; php -f cron.php > /dev/null 2>&1

You suggest the aggressive way for chmod before install?

Changing OS isn’t rlly something i would go for at this stage but never say never…

JeroenNLL · 12 May 2021 16:59

Now i see the cronjob again shouldn’t it have trailing slash at the end?

pgr · 12 May 2021 17:48

Try adding your specific user and group in the config.php array…

And you can try the 2750 for the directories now, even after it is installed, and then just run a few repairs from Admin / Repairs.

As long as it stabilizes in a way that works, you should be ok…