before the SuiteCRM Installation Pre-Requisites section there are 4 permission statements of which Line 1 poses a problem for me:
Line 1: sudo chown -R www-data:www-data .
I have cpanel access and filezilla - but no SSH/CLI access - and using shared hostingā¦
how do i change the ownership?
the system user is ānobodyā
i have put this problem to my hostingās support but no answer yetā¦
has anyone else run into this problem?
did you get it resolved? how?
how important is it to change the ownership to the system user?
pgr
19 September 2021 15:50
2
Ownership is crucial, because permissions (like 0755) donāt mean much without ownership settings, the two things reference each other.
However, on restrictive shared hostings there is a high chance that your filesā ownerships are already set the way they should.
So I would say the first step for you would be to determine (through Filezilla) if your ownerships are already set the correct user (which is the one given in the crontab command at the bottom of the screen in Admin /Schedulers).
my providerās tech support has got back to me about setting the ownership of the suitecrm directory and then they set it
however i donāt think the ownership is set correctly
iāve described in the following what they did and if somebody could check/comment itād be greatly appreciated
will be running suitecrm on a shared server
ok my providerās tech support got suitecrm directory created and set the ownership:
/home/my_account/suitecrm_directory
the suitecrm directories and files have not yet been uploaded to suitecrm_directory
the suitecrm directory ownership has been set to:
me_the_user:nobody
where nobody is the system user
iāve been told that when the suitecrm directories and files have been uploaded to suitecrm_directory their ownership will be set to:
me_the_user:me_the_user
which i believe is not what suitecrm wants
but am i looking for those files to have ownership set to:
me_the_user:nobody
or is it:
nobody:nobody
??
pgr
22 September 2021 14:00
4
Please refer to the last paragraph of my previous reply to see how to determine the correct user.
in Filezilla i do not see anything about Admin /Schedulers at the bottom of the screen - what screen?
iāve googled: filezilla admin schedulers without any luck thus far
when you say filezilla are you talking about the client the free version or the pro version or the server version?
@pgr 's suggestion is to first have a look at the scheduler page of Suite. There (ā¦index.php?module=Schedulers&action=index) you will find (at the bottom of the page) some instructions that explain how to execute the schedulers automatically by the OS:
In this example, the correct username is therefore apache
. pgr now would like you to compare this username with the name that you see as āownerā in filezilla while you are connected to your webserver.
1 Like
on the Downloading & Installing page
it says to run this on the suitecrm directory subdirs and files before running install.php:
sudo chown -R www-data:www-data .
when i use filezilla it shows the suitecrm directory having:
Owner/Group
2011 /99
?/nogroup
pgr
22 September 2021 21:15
9
Inside your SuiteCRM, go to menu Admin, then click Schedulers, and check what it says there, which username appears in the crontab command.
thatās after suitecrm is installed - iām given to understand from the downloadihg and installing page that the ownership be settled before running install.php or dire things will happen while installing and using suitecrm -
or that documentation isnāt worth the pixels itās written on?
the documentation shows an example, as āwww-dataā is simply not correct for each environment (which is stated on the install page):
So after installing, go to admin->schedulers and look if the username shown there matches the owner you see in filezilla.
And of course its also possible to determine the proper user name before installing Suite, but that would require ssh access.
pgr
23 September 2021 10:38
12
I made a Diagnostics PR looong ago that would help with all this. It includes all the needed information in one place, and it is callable both from within the app and from the command-line, which is obviously useful when the installation isnāt done yet, or when it is broken.
salesagility:hotfix-7.10.x
ā pgorod:diags
opened 02:05PM - 30 Apr 20 UTC
## Description
* improves the output of **Admin / Diagnostics** screen to actuaā¦ lly provide meaningful information that is regularly needed in support and troubleshooting
* adds a quick view of the full `phpinfo` directly from that page, without requiring the user to download a zip
* adds a `diagnostics:quick-report` Robo task to produce the same report from the command-line, useful for servers where you can't even get to the **Admin / Diagnostics** page (uninstalled, or broken installations).
* adds a generic mechanism to query the web server side of PHP from the CLI side. This is the first step to having (in the future) a more integrated management of settings, permissions management, etc., across the entire app.
## Motivation and Context
So many posts in the Forums are just to get users to provide basic information... this way it's all there, together in one place.
## How To Test This
1. Start with a QR&R to get the language LBL added.
1. Visit the Diagnostics screen.
1. In that screen, press the new "View phpinfo" **button**.
1. From the command-line: run the Robo `diagnostics:quick-report`
Interesting variations for the tests:
1. Windows / Linux
1. In `php.ini`, add `exec` to `disabled_functions`, common in many shared hostings
1. Using `port` number in `site_url` in `config.php`
## Suggested Future developments
If somebody wants to pick up on this work later, I suggest:
* check permissions and actual directory writeability, and report on that. Make it obvious to users when their installation is still not operational. I don't suggest a useless full check, like the one we have in the Upgrade Wizard, which is dumb (complains in many set ups where access _is_ working). I mean a practical check in a few crucial directories (write file, read it, delete it).
* Add also the reverse mechanism allowing to run CLI jobs from the web server side by persisting something that a custom scheduler will then pick up and execute. This is not that hard to achieve, and will allow us to bridge the two PHP worlds effectively.
* Make better use of the `setPhpIniSettings` function, [called](https://github.com/salesagility/SuiteCRM/blob/master/include/entryPoint.php#L103) in every entry-point,
so that users can select basic PHP settings from within our UI, and have them applied automatically by SuiteCRM, both in Web server and CLI. No more `php.ini` editing!
## Types of changes
- [X] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
### Final checklist
- [X] My code follows the code style of this project found [here](https://docs.suitecrm.com/community/contributing-code/coding-standards/).
- [X] My change requires a change to the documentation.
- [X] I have read the [**How to Contribute**](https://docs.suitecrm.com/community/contributing-code/) guidelines.
1 Like