Permissions are a nightmare!

[Darren Grant]

Something really has to be done about the permissions nightmare.

After failing miserably at my last attempt at installing Magento 2 due to the numerous bugs in both Magento and PHP, I decided to have another go now that 2.0.1/2 and PHP 7.0.3 are now available. A promising start as it actually installed this time round but I have taken to hammering nails through my eyes as a bit of a relief from the complete pain in the backside Magento 2 is causing me.

After many, many hours of fighting with this monster pain I have discovered that a majority of my problems and probably 9 out of 10 of other peoples problems on here are down to permissions.

A typical linux system has a web server running as a user without a shell, in my case on CentOS the user is called apache. Then typically a regular user with a shell is used to administer the system.

While Magento 2 is being interacted with via the web browser it is creating new files and directories as the web server user. So in my case a number of files and directories being created with ownership of apache:aapche. While the cron script has to run as a user that has shell access. The cron job creates files and directories with the ownership user:user. Now there is a mismatch of ownership. CRON can not alter the files crated by the apache user, and apache can't modify the files created by the regular user.

I have followed the documentation guide to permissions and set all files to owner user:apache and given user and group full control of the files. This helps but quickly things go pear shaped again as more files are created with wrong permissions. Particularly when a directory is created and then no files or subdirectories can be created in it.

This is all a big mess forcing me to give up again. Is there a solution?

[Alextimmer]

I find it strange that there are no responses in this thread, because what you say seems to be true; most issues people have are rights-related, and it's a big pain in the ass for everyone. Though there is yet to be a constructive solution for this.

I figured out a way around it, or well, my hoster did. He made a shell script to fix the permissions in a directory. So whatever we do or whatever happens on the server; we can run the fixperm script via ssh, and it sets all the permissions straight again. It's still a headache, but this way it's workable. 

But I would love to hear if someone has a permanent fix for this, or if the Magento dev team is adressing the issue.

[treestonemedia]

This is a real issue and you were persuaded to give it another try  - a lot of developers will be quicker to raise their hands up and say "I give up - this is not for me".

I'm on  a Nexcess server (they're a Magento partner) and I'ms till not seeing the light at the end of the tunnel.

@ every turn and bend I need to email their support staff.

The bottom line is that to run Magento 2 you will need some sys admin knowledge and using a hosting service is not going to be an option, you will need your own server with AWS or rackspace...

[SindreM]

In Magento 2.0.6 this became a lot easier. They finally moved away from explicitly setting the file permissions and instead leave it to the Operating System to set the default umask like it should have from the start. That means for most Linux servers 644 permissions for files and 755 for directories. This simplifies things A LOT for users on cPanel servers or shared hosting where the file system is owned by the account user and not the user the web server is running as.

If you use some form of SuExec where PHP executes as the file system owner this should now work out of the box also when Magento generates files on its own.

If PHP executes under a _different_ user than the file system owner you will have issues because those files/folders will need to be world-writable for the server to be able to access them. This is a major security concern, especially if the server is shared, and needs to be addressed at the server level - not in Magento.