I haven't see many mentions of using 700 and 600 but it is generally good advice. Unfortunately every server set up is different and needs to be weighed up against convenience (user access to update/edit files).
The underlying approach should be to only give away as little as possible and lock it down as much as you can (700/600 is good for this). In that respect the "official" advice on the wiki wants to apply to as many circumstances as possible and suggests read permissions for everyone (which means any compromised other service on the server will then for example be able to read app/etc/local.xml with your db configuration).
In your case it currently sounds like the files are owned by a different user than what your webserver/php process runs under. Changing the ownership of the files to the webserver should solve your original issue.
Please note that using 700 / 600 and assigning the files to the webserver means your normal user would not be able to edit the files.
The below I feel is a good compromise for convenience vs lock down. All files are owned by user:webservergroup
var and media 770 / 660
The server and your user is allowed to read and write from the var and media folders (session/cache/images).
the rest 750 / 640
Your user is able to edit/update the code.
The webserver is able to read the files for execution/display.
TLDR; version of why Magento gives those instructions: you want things to be writable during installation (700 directories and 600 files), then afterwards assign ownership to the web server running user and restrictive permissions (500 directories, 400 files) that allow read only except for media/ and var/ directories.
This will work on a server that has been set up specifically with security in mind. Web servers can have a lot of variation in their setup especially shared hosts.
Your system sounds like it needs group and/or global read permissions for the web server to read your login user owned files. Check to see who owns the var/cache/
sub folders and the files they contain, you probably will find it's different.
From the question, you didn't get to the next step. They then have the After Installation settings which are even more restrictive.
Running recommendation is:
500 for directories
400 for files
for media/ and var/
700 for directories
600 for files.
The key to understanding all this is the need to know the server user
On a dedicated server, in the instructions they tell you how to find the server user by checking the apache2.conf
or httpd.conf
file for the User
config line.
Typically, this will be something like nobody
, www-data
And so with this bit of information on a dedicated server you then assign all directories and files to be owned by the server user
chown -R {web-server-user-name-here} .
On a hosted system, if you're using Apache MPM-ITK or litespeed, the web server will run with your login name
as the server user.
Once the ownership is set properly then you change all the directories and files as follows:
find . -type f -exec chmod 400 {} \;
find . -type d -exec chmod 500 {} \;
find var/ -type f -exec chmod 600 {} \;
find media/ -type f -exec chmod 600 {} \;
find var/ -type d -exec chmod 700 {} \;
find media/ -type d -exec chmod 700 {} \;
chmod 700 includes
chmod 600 includes/config.php
Now comes the massive headache part. Any time you upload files you no longer have write permissions except where you have allowed them (var/
, media/
) so every time you want to do maintenance outside these folders, you must change everything back by:
find . -type d -exec chmod 700 {} \;
find . -type f -exec chmod 600 {} \;
And on the dedicated server, also probably change ownership to the login user name so you will have permission to write stuff.
Also, if you used Magento Connect (on dedicated server, leave ownership as the web server user), anything it installs will be given 777 permissions.
Because you have to remember to undo and redo the process every time you change something, or are running on a system where the web server needs group/global read permissions, the following permissions have probably become the defacto standard among lesser technically skilled website owners:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod o+w var app/etc
chmod 550 mage
chmod -R o+w media
Best Answer
I'm working on a solution that feels right, but this is by no means authoritative. I'd love to get feedback or questions. Here it is:
The setup involves two users:
deploy
user in thedeploy
group: the user who writes to the server during deployments via rsync/SSH.apache
user in theapache
group: the user that Apache runs Magento as.The general philosophy is to have the entire Magento directory chowned as
deploy:apache
and have the folders that require operational write access be group-writable. Step-by-step that should get you there:As
root
, create the virtual host's HTTP root, say,/var/www/html
and chown it asdeploy:apache
, setting the setgid sticky bit:Deploy the Magento code via rsync/SSH using the
deploy
user. All files and folders should now be owneddeploy:apache
.As the
deploy
user, set/var
and/media
to group-writable.Remove
umask(0)
in the Magento code to use the OS's default022
or set explicitly toumask(022)
.apache:apache
and be755
or644
.This approach is consistent with the Magento wiki article that recommends the group permissions and fleshes it out a bit. It also seems to be rather close to what this gist by svenvarkel I found does. I see its advantages over the approach to setting the files as owned by the Apache user in that that approach requires you to use the Apache user to deploy and depending on implementation, it either requires constant toggling of write permissions for deployments or leaves the core writable by the Apache user.
I'd love to receive comments or critiques on my proposed approach.