1

I am trying to setup a new Magento 2.3 site. I keep seeing weird issues where some of the permissions have ownership set to root. It seems like some of the files are getting generated as root. I have a script that fixes the permissions, and things continue to work as expected for a while, but I'd like to understand why it is happening in the first place.

I extract the tarball as the site user. I start the install, but then I hit a writable problem in the file system. I can fix the permissions, and it will install, but why are those files owned by root?

File Permission Check
1 file permission not met. Hide detail

The best way to resolve this is to allow write permissions for files in the following Magento directories and subdirectories. The exact fix depends on your server, your host, and other system variables. 
For help, see our File Permission Help or call your hosting provider.

"/var/www/vhosts/steamspeed.com/httpdocs/app/etc" - Writable.
"/var/www/vhosts/steamspeed.com/httpdocs/var" - Not writable, change the permissions. Show details
"/var/www/vhosts/steamspeed.com/httpdocs/pub/media" - Writable.
"/var/www/vhosts/steamspeed.com/httpdocs/pub/static" - Writable.
"/var/www/vhosts/steamspeed.com/httpdocs/generated" - Writable.

The site user can't delete the files.

sw@ss:~/httpdocs$ rm -rf *
rm: cannot remove ‘generated/code/Composer/Console/ApplicationFactory.php’: Permission denied
rm: cannot remove ‘generated/code/Symfony/Component/Console/Input/ArrayInputFactory.php’: Permission denied
rm: cannot remove ‘generated/code/Symfony/Component/Console/Helper/TableFactory.php’: Permission denied
rm: cannot remove ‘generated/code/Symfony/Component/Console/Question/QuestionFactory.php’: Permission denied
rm: cannot remove ‘generated/code/Magento/Indexer/Model/Indexer/CollectionFactory.php’: Permission denied
rm: cannot remove ‘generated/code/Magento/Framework/Config/Composer/PackageFactory.php’: Permission denied
rm: cannot remove ‘generated/code/Magento/Framework/App/ResourceConnection/Config/Proxy.php’: Permission denied
rm: cannot remove ‘var/composer_home/cache/repo/https---repo.packagist.org’: Permission denied
rm: cannot remove ‘var/composer_home/cache/repo/https---repo.magento.com’: Permission denied
rm: cannot remove ‘var/composer_home/cache/.htaccess’: Permission denied
rm: cannot remove ‘var/composer_home/cache/files’: Permission denied
rm: cannot remove ‘var/composer_home/.htaccess’: Permission denied
sw@ss:~/httpdocs$ ll generated/code/Symfony/Component/Console/Helper/TableFactory.php
-rw-rw-r-- 1 root root 1114 Dec 24 02:54 generated/code/Symfony/Component/Console/Helper/TableFactory.php

When I watch what php processes are running, it looks like most of them run as php-fmp as the site user. I also see php processes running as root.

What is wrong with my php configuration?

  • 1
    I think I may have figured it out. I had the Magento cron job set in the root account. I removed it, and set it in the site user's crontab file. Hopefully that fixes it! – sam msft Dec 24 '18 at 22:05
  • # this is what Magento added to crontab * * * * * /opt/plesk/php/7.2/bin/php /var/www/vhosts/steamspeed.com/httpdocs/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/vhosts/steamspeed.com/httpdocs/var/log/magento.cron.log * * * * * /opt/plesk/php/7.2/bin/php /var/www/vhosts/steamspeed.com/httpdocs/update/cron.php >> /var/www/vhosts/steamspeed.com/httpdocs/var/log/update.cron.log * * * * * /opt/plesk/php/7.2/bin/php /var/www/vhosts/steamspeed.com/httpdocs/bin/magento setup:cron:run >> /var/www/vhosts/steamspeed.com/httpdocs/var/log/setup.cron.log – sam msft Dec 27 '18 at 22:17
1

Do take a look at setting permissions for magento 2.3

Looking at your screenshot, it seems the files that have root ownerships, come from actions that are commands related: php bin/magento index:reindex is for instance a command.

My observation is as follows: your crontab runs as root and triggers some commands. That is fine and you don't have to change this of course although you may want to read more about this going forward. (at least, it may give you an explanation where these changes of permissions come from). I tried on my local machine and the same applies if I clear my generated folder.

In the permissions settings recommended by Magento devdocs page (see pic below), you will notice the 3rd line has a "s" that stands for sticky bit and this "s" is supposed to apply recursively the same permissions. I am hopeful you are missing the sticky bit and if you ensure this is resolved, it will likely resolve your issue. In a nutshell, the group permissions is what we are after and as long as your webserver user is part of the group creating these files we will be ok

enter image description here

| improve this answer | |
  • I am not exactly sure what you mean. I think +t is for the sticky bit, and +s is for setuid. The main difference is that suid allows another user to run as an exe file's owner. Sticky bit is about not letting other users delete or rename files they don't own....I think. linuxconfig.org/… – sam msft Dec 28 '18 at 21:03
  • I am a web developer (not a sysadmin). The s in the above (3rd) command enables the folder created by the webserver or by root when a command-line runs to take the permissions from the generated folder, that is what I meant – Herve Tribouilloy Dec 28 '18 at 21:11
  • I found this article unix.stackexchange.com/questions/118853/… and setuid and sticky bit seem to be used interchangeably .. now, it may be better one way or another and I would not know – Herve Tribouilloy Dec 28 '18 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.