How do I set Magento 2 file and directory permissions safely without using 777?

Safe Magento 2 file permissions rely on group ownership. Put the SSH user that runs bin/magento and the user PHP-FPM or Apache runs as into one shared group. Give that group write access only where Magento writes at runtime, and make code read-only in production.

Why chmod 777 is unsafe for Magento 2

A typical Magento 2 permission error comes from the SSH user and web server user fighting over the same files. Setting 777 hides that conflict by letting every user and process on the server write to the path.

On a shared server, any other site’s PHP process can then drop a backdoor into pub/media. The ownership conflict also stays in place, so errors come back after the next deploy.

How to set Magento 2 permissions in developer or default mode

These steps apply to Magento Open Source and Adobe Commerce on your own server. They follow the two-user setup in Adobe’s file system permissions guide. Commands match that guide as of June 2026, and the paths assume Magento 2.2 or later.

Replace magento_user with your command-line user and www-data with your web server group. On RHEL-based servers that group is often apache or nginx.

1. Add the command-line user to the web server group

sudo usermod -a -G www-data magento_user

Log out and back in so the new group membership takes effect.

2. Give the shared group ownership of the install

cd /path/to/magento
sudo chown -R magento_user:www-data .

3. Make only the runtime directories group-writable

find var generated pub/static pub/media app/etc -type f -exec chmod g+w {} +
find var generated pub/static pub/media app/etc -type d -exec chmod g+ws {} +

The s in g+ws sets the setgid bit. New files inside these directories then inherit the shared group, so cache and generated files stay writable for both users.

In octal terms, these Magento 2 file permissions come out at 2775 for writable directories and 664 for their files. That assumes your other files sit at 644 and directories at 755, a common default.

Cache and media files created later follow Magento’s umask, so this setting decides whether permissions drift after you fix them. Keep the default of 002 on this two-user setup, which creates directories at 775 and files at 664. Changing it to 022 removes group write, so Adobe advises that only for single-user or shared hosting.

4. Make the CLI executable

chmod u+x bin/magento

How to lock down Magento 2 permissions in production mode

This table shows which paths stay writable for the web server group in each mode.

In production mode, the web server no longer needs to write compiled code or static assets. Adobe recommends removing group write from those paths and closing app/etc/env.php to other users, since that file holds your database credentials.

Run the mode change as the file system owner, then run the permission change as root:

bin/magento deploy:mode:set production
find app/code lib pub/static app/etc generated/code generated/metadata var/view_preprocessed \( -type d -or -type f \) -exec chmod g-w {} + && chmod o-rwx app/etc/env.php

Before installing a module or upgrading, restore group write on the locked directories with this command:

find app/code lib var generated vendor pub/static pub/media app/etc \( -type d -or -type f \) -exec chmod g+w {} +

Adobe’s version of this command also appends chmod o+rwx app/etc/env.php. Leave that part off to keep your database credentials private. Then run the lockdown again after the upgrade.

The practical takeaway

If you’re reaching for 777, check ownership first. Get the shared group and setgid right once, and keep cron and bin/magento off root. Then lock code down in production so the web server can’t modify it. If your server setup makes this harder than it should be, our Magento development team can review it with you.