Magento file permission: securing Magento 2 files & directories

Key takeaways

• Magento 2 needs different permissions for files and directories, and setting them correctly protects both stability and security.
• Single-user shared hosting and two-user private servers each call for a different approach to ownership and permissions.
• A least-privilege model that avoids 777 keeps sensitive files like app/etc/env.php locked down while the storefront keeps running.
• The way your server runs PHP, as the web server user or as your local user, changes which permission strategy is safest.

Most software packages install with the most lenient file and directory permissions and ownership. Developers normally do this for their own convenience, since their software must install on a range of diverse systems with varying configurations. The trade-off is that a fresh install rarely ships with the security your store needs. This article gives you an overview of how to set up your Magento 2 installation with the strictest permissions for overall security’s sake.

When your site matters, confidence matters. Getting these permissions right is one of the first steps toward a store you can trust.

The importance of Magento file permissions

Magento file system permissions define what actions users can perform with your files and directories. They cover the reading (r), writing (w), and execution (x) rights of the owner, group, and other users. Set them too loosely and you invite trouble. Set them too tightly and parts of your store stop working.

Permissions affect your store in two big ways. 

1. The first is stability. Incorrect file and directory permissions break functionality and interrupt processes. Missing permissions can stall static content deploys, composer updates, and cache operations. Correct permissions keep development and deployment running without surprises.
   
2. The second is security. Permissions decide who can read, change, or execute your files. Tight permissions block unauthorized access and code injection that can damage your system. They also protect sensitive files, like the ones storing your database credentials, from anyone outside your system users.

How your server runs PHP shapes the real risk. On Linux you will find two main environments:

• PHP scripts that run via mod_php or equivalent execute as the web server user. When your script runs, it can read, and sometimes write, with the same privilege level as the web server. This allows cross-account snooping in shared hosting setups and is not ideal in a shared environment, especially for ecommerce.
  
• PHP scripts that run as the user who owns the files, through an intermediate construct such as suPHP, PHP suEXEC, or PHP-FPM. Here your scripts run as you, which is a more secure overall configuration on a shared server.

Knowing which model your host uses tells you which of the two methods below fits your store.

Understanding Magento 2 permission types

Magento uses octal values to define a combination of actions for different users. The table below breaks down the common ones.

For a standard Magento 2 setup, the common recommendation is 770 for directories and 660 for files. These are the most secure options that close your system to third-party users. If your system does not support them, 775 and 644 are safe alternatives that still avoid handing out full access.

If you want to go further, you can run a tighter baseline of 644 for files and 711 for directories, then open up only the specific directories that need it. This least-privilege approach is the foundation of the two methods below.

The two server environments you’ll encounter

Permissions can be set for one or multiple users, and your environment decides which applies.

A single-user setup is most common on shared hosting, where one account manages all resources. That same user logs in, transfers files, and runs the web server.

A two-user setup is typical on a self-hosted environment or a dedicated server. One user manages file transfers and command-line operations (the file system owner), and a separate user runs the web server. To let the web server write files while the file system owner keeps ownership, both users need to share a group.

Method 1: Running as the web server user (single user)

By default, many shared and dedicated hosting companies run your scripts as the web server user. It is the operating system default on most Linux systems. In a shared environment it is not the most secure, but you can partly remedy that by limiting access with stricter file permissions. 

In dedicated hosting environments this method is desirable, mainly for performance reasons, and none of the shared hosting caveats apply when the server serves a single client.

Here are the steps in plain English, followed by the commands.

1. Set ownership of all files to your local user. If you have root access, set the user and group ownership of everything in the Magento directory to your local user. This may already be done, and it flushes out any web server owned files for good measure.

bash

2. Set a readable baseline for all files. This gives the web server read access so it can execute scripts and serve static content like images, CSS, and JavaScript.

bash

3. Set directory permissions. Directories become listable, editable, and navigable for the owner, and simply navigable for everyone else.

bash

4. Give special handling to media and var. The web server itself must read and create files here. This is where most instructions give away the farm and go straight for world-editable permissions. Take a least-privileged approach instead, adding group permissions so anyone in the group can list, edit, and navigate.

bash

5. Set file permissions in media and var. Allow the owner and group read and write, and everyone else read only.

bash

6. Set ownership for media and var. This step needs root access or a flexible hosting company. Set ownership to the web server with group ownership to your local user. It looks backwards, but for technical reasons involving how disk space usage is calculated, this is how it works best.

bash

7. Make future files inherit these settings. This is the least understood step. Steps 4 through 6 set up specific access on existing files and directories. To make new files and directories follow the same rules, use the SUID and SGID bits. When set, they tell Linux to inherit the ownership of the directory. As Magento creates files in media and var, their ownership mirrors what you set in step 6.

bash

8. Lock down the core configuration files. For added protection against snoopers, make the configuration files readable and writable by the owner and readable by the group only.

bash

That is all there is to it. Doing the above gives you some of the tightest permissions available on a Magento install.

Method 2: Running as your local user (two users)

In shared environments this method is preferred for the extra security Linux provides when permissions are configured correctly. It gives you user-based permission isolation, so you can use stricter ownership and file permissions.

1. Set ownership of all files to your local user. As before, if you have root access, set user and group ownership of everything to your local user.

bash

2. Set a readable baseline for all files. The web server still needs read access to serve static content. You will tighten script permissions in step 4.

bash

3. Set directory permissions. Listable, editable, and navigable for the owner, navigable for everyone else.

bash

4. Wrench down permissions on all PHP scripts. Only your user should need to read the contents of scripts, so restrict them to your user alone.

bash

5. Disable access to your configuration files for everyone but you. This is the nicest part of this method. Since PHP scripts are the only thing that needs to read these files, and PHP runs as you, you can shut out all other users.

bash

Developer mode vs. production mode

The directories you keep writable depend on the mode you run.

In developer mode, these directories must be writable: vendor, app/etc, pub/static, var, generated/code, generated/metadata, var/view_preprocessed, and any other static resources.

In production mode, you tighten things up. Remove write access from vendor, app/code, app/etc, pub/static, generated/code, generated/metadata, var/view_preprocessed, and other static resources. Make these directories writable again only when you update components or upgrade your Magento software.

To remove write permissions for a single-user production setup:

bash

To make directories writable again when you need to update:

bash

Verifying your permissions

After setting permissions, confirm they applied correctly.

To check that your file system owner belongs to the web server group:

bash

A sample result shows the user’s primary and secondary groups:

bash

To inspect ownership and permissions on a file or directory, use ls -l for a listing or stat for a single item:

bash

A quick check here saves you from chasing a permissions bug after the fact.

Magento file permission best practices

Start by identifying the sensitive files that hold your system details, like app/etc/env.php with its database credentials and encryption keys. Make sure those files are never publicly accessible, and that only your system users can read, write, and execute them. Granting public access to sensitive files can breach the security of your whole system.

I’ve seen many instructions for web-based software claim that files must have 777 permissions, which grants read, write, and execute to everyone. This may be necessary for some directories, but it is rarely right for files. Permissions of 666 are adequate in those cases when you cannot set stricter ones. 777 also sets the execute bit on files, which most web servers do not and should not require. 666 simply says “read and write for all users,” which is not great either, but is more correct. If you do use 777 as a quick fix, revert it once the issue is resolved, and never run it on production.

Monitor your permissions over time. It is easy for a stray change to open a hole, and reviewing them regularly keeps slip-ups from turning into incidents.

Finally, check the Magento and Adobe Commerce version your commands target. The directory structure and recommended settings have shifted across versions, so confirm the guidance matches your install.

Troubleshooting common permission errors

A few permission problems come up again and again.

bin/magento permission denied. This happens when the file lacks execute permissions. Add them:

bash

Web Setup Wizard file permission check failures. When directories are not writable by the web server user, the wizard throws errors. From your Magento root, make the working directories writable:

bash

Cache or media write errors. When Magento cannot write to cache or upload media, open up group write access on the relevant directories:

bash

Magento file permission FAQs

Getting started with Magento file permissions

Securing your Magento file and directory permissions comes down to a simple principle: give each user the least access they need, and no more. Whether you run as the web server user or as your local user, tight permissions protect your store’s stability and shut out the snooping and code injection that loose defaults invite.

Start by choosing the method that matches how your server runs PHP, run through its steps on a staging copy first, then verify the result with ls -l and stat before applying it to production.

Tired of babysitting your servers? Your store depends on this, and it has to work. Liquid Web’s Managed Magento Hosting handles ownership, the shared group, and flexible permission changes for you, on infrastructure built for businesses that can’t afford downtime. 

Our agency customers run 50 or more sites on it, and one WooCommerce customer is doing over $50M in sales. Move your site without the headache: our team handles the migration.