June 16, 2016

The problem

Magento 2 aimed to augment the security of its predecessor. One such improvement set the default permissions on certain static files to be stricter than normal. This had the unintended side effect of preventing default versions of Magento 2 from functioning on some systems, some of which we host.

Before v. 2.0.6, Magento 2 set permissions of some files to 640 and some directories to 750. These permissions restrict read-access and write-access to the owner of those files and directories, meaning other users have no access. While this successfully tightens permissions, it is incompatible with systems that rely on a web server’s ability to read and write to these files.

For example, many Magento sites use Apache or Nginx with PHP-FPM. In this setup, PHP-FPM runs as the file-owning user, and Apache or Nginx function as separate users and therefore had no file access. This prevented these systems from functioning properly with default Magento 2 installations running versions older than 2.0.6.

What we did about it

Despite the problems with the default version Magento 2, we couldn’t wait for the next version to offer it to our clients. After some investigation, we determined the vendor/magento/framework/Filesystem/DriverInterface.php file contained hard-coded permissions, and that updating these values could function as a temporary workaround.

This allowed Magento 2 to function, but this type of change is often reverted by patches, and, in some cases, it can prevent patches from being applied at all. Additionally we later discovered these permissions constants were set in other files. We submitted a pull request to Magento 2 to correct this. This pull request demonstrates the other locations that included hardcoded file permissions.

For these reasons editing the code was an unsatisfactory solution, and we developed two other workarounds:

  • Add the Apache user to the group of the user owning the web files. This sacrificed a bit of security for convenience. Any attacker that is able to run code as the Apache user would now be able to alter the site files as well.
  • Create a cron job to change the file permissions on files uploaded by Magento. This worked, but added about 1 minute to the time it took newly uploaded files to become viewable on the live site.

These solutions were successful, but not ideal, so we asked for help. Our own Miguel Balparda opened an issue on the Magento 2 GitHub explaining the problem. As of this time, this issue is the most commented issue in the entire software repository as many users reported their own struggles with file permissions in Magento 2 and provided their own workarounds and feedback on better methods.

A better way

After several months and input from the community, Magento has released Magento 2.0.6, which changes the way Magento 2 handles file permissions.

This version eliminates the permissions issue with two techniques:

  • It relaxes the default permissions for both files and directories. Files move from 640 to 644, and directories move from 750 to 775.
  • It allows the creation of a magento_umask file in the document root of the site, which causes Magento 2 to set stricter permissions. For example, a value of 022 in this file would assign permissions of 644 to files and 755 to directories. More information is available here.

Since this upgrade resolves the conflict between default Magento 2 installations and many server configurations, we recommend upgrading to Magento 2.0.6 or higher as soon as possible.


With almost a decade in systems experience, Chris is here to make clients happier with the services they use. If there’s a technical problem, chances are Chris is one of the team members working on it, having already made tens of thousands of sites run better with the infrastructure improvements he’s helped develop.

We use cookies to understand how you interact with our site, to personalize and streamline your experience, and to tailor advertising. By continuing to use our site, you accept our use of cookies and accept our Privacy Policy.