Setting up or Fixing File Permissions

Variant A: Using a Shared Group (Recommended)

Put both users in a dedicated group, give that group the ownership of var/ and make new files inherit it. Use the same script as above to determine your web server user:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx|[c]addy|[f]rankenphp' | grep -v root | head -1 | cut -d\  -f1)

# use a dedicated group instead of the personal group of your terminal user;
# otherwise, the web server user could read every file of that group
$ sudo groupadd symfony
$ sudo usermod -aG symfony "$HTTPDUSER"
$ sudo usermod -aG symfony $(whoami)

# only var/ is shared, the rest of the project is left untouched
$ sudo chgrp -R symfony var

# 2775 = setgid + rwx for the owner + rwx for the group + r-x for the others
# the setgid bit (2) makes new entries inherit the group of their parent
# directory, instead of the primary group of the user who created them
$ sudo find var -type d -exec chmod 2775 {} \;

# 664 = rw- for the owner + rw- for the group + r-- for the others
$ sudo find var -type f -exec chmod 664 {} \;

The group digit (7 and 6 above) is the one that solves the problem: it must allow the group to write. The usual 755 and 644 permissions only grant r-x and r-- to the group, which is why the two users can't write to each other's files.

The setgid bit replaces the inheritance provided by ACL. Without it, files created by the web server would get its own primary group, and your terminal user couldn't write to them. With it, permissions stay correct after each cache:clear.

The setgid bit only propagates the group, never the write permission, so you must also set a umask of 0002 on both sides.

For the terminal user, configure it at the session level rather than in ~/.bashrc or ~/.zshrc, which are not read by cron jobs and most non-interactive shells used by deployment scripts. On Debian/Ubuntu, add this line to /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive; on RHEL/Fedora, add it to /etc/pam.d/system-auth. It changes the umask of every user on the machine:

1

session optional pam_umask.so umask=0002

For PHP-FPM, set the UMask option in a systemd drop-in file created with sudo systemctl edit php8.5-fpm:

1
2

[Service]
UMask=0002

Group membership and umask are read when the process starts, so restart PHP-FPM to apply them. Your terminal user must also open a new session (log out and log back in) for its new group membership to take effect:

1

$ sudo systemctl restart php8.5-fpm

To check the result, load any page of your application so that PHP-FPM creates some cache files, and then run these commands as your terminal user:

1
2
3
4
5
6

# files created by the web server must belong to the "symfony" group
# and be group-writable (-rw-rw-r-- ... symfony)
$ ls -l var/cache/prod/

# must succeed without any "Permission denied" error
$ APP_ENV=prod php bin/console cache:clear

Variant B: World-Writable Files

If the two users can't share a group (e.g. on a shared host where you can't run usermod), the only remaining option is to make the files writable by everyone. Compared to the 0002 used above, a umask of 0000 also grants the write permission to the others, i.e. to every user and process of the machine, and not only to the members of the shared group.

Put the following lines at the beginning of the bin/console and public/index.php files:

1
2

// the last 0 (for the others) is what makes the files world-writable
umask(0000); // new directories: 0777, new files: 0666

The umask only applies to new files, so also make the existing contents of var/ world-writable once (e.g. with chmod -R a+rwX var).

Setting the umask from PHP also works for variant A, as an alternative to configuring it for each process:

1
2
3

// makes new files group-writable, so that the web server user and the
// terminal user can write to the files created by each other
umask(0002); // new directories: 0775, new files: 0664