Table of Contents
Symfony generates certain files in the
var/ directory of your project when
running the application. In the
public/index.php files use
umask() to make sure
that the directory is writable. This means that you don't need to configure
permissions when developing the application in your local machine.
umask() is not considered safe in production. That's why you
often need to configure some permissions explicitly in your production servers
as explained in this article.
These are the permissions required to run Symfony applications:
var/log/directory must exist and must be writable by both your web server user and the terminal user;
var/cache/directory must be writable by the terminal user (the user running
var/cache/directory must be writable by the web server user if you use a filesystem-based cache.
On Linux and macOS systems, if your web server user is different from your command line user, you need to configure permissions properly to avoid issues. There are several ways to achieve that:
Using Access Control Lists (ACL) permissions is the most safe and
recommended method to make the
var/ directory writable. You may need to
setfacl and enable ACL support on your disk partition before
using this method. Then, use the following script to determine your web
server user and grant the needed permissions:
1 2 3 4 5 6 7
$ HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1) # if this doesn't work, try adding `-n` option # set permissions for future files and folders $ sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var # set permissions on the existing files and folders $ sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var
Both of these commands assign permissions for the system user (the one running these commands) and the web server user.
setfacl isn't available on NFS mount points. However, storing cache and
logs over NFS is strongly discouraged for performance reasons.
Edit your web server configuration (commonly
for Apache) and set its user to be the same as your CLI user (e.g. for Apache,
If this solution is used in a production server, be sure this user only has limited privileges (no access to private data or servers, execution of unsafe binaries, etc.) as a compromised server would give to the hacker those privileges.
If none of the previous methods work for you, change the
umask so that the
cache and log directories are group-writable or world-writable (depending
if the web server user and the command line user are in the same group or not).
To achieve this, put the following line at the beginning of the
1 2 3 4 5
umask(0002); // This will let the permissions be 0775 // or umask(0000); // This will let the permissions be 0777
umask is not thread-safe, so the ACL methods are recommended
when they are available.