Setting Proper WordPress Unix Permissions

One of the biggest black boxes of WordPress for newbies is file ownership/permissions. I’ve had numerous people ask me why they can’t use the default theme editor or install new plugins directly from wp-admin. The symptoms usually range from getting the FTP credentials screen to error messages that WordPress cannot create a specific directory, and more.

It took me a while to grasp the concept, so I hope the following explanation will help you. This, in no way, is a security tutorial. It is a simple tutorial on Unix users/groups and file permissions. You should also read Hardening WordPress. If you’re not sure about file permissions, read this article first.

Groups and Users

The first order of business is making sure you have the proper user/groups setup. I typically create one unix group per site that I host. This allows me to have granular control over who’s allowed to work in that site directory.

Add a new user

useradd newusername

Add the user to your site group

usermod -a -G domainnamegroup newusername

Find the Apache user
This is typically ‘apache’ or ‘www-data’. Note this for the next step.

ps aux | grep apache

File ownership

Now that we have a user in a group, we need to assign that group to our WordPress install. It’s critical at this point to decide whether these users can only operate in wp-content or the entire docroot. Let’s say we only want to give this group dev access to themes/plugins/uploads/etc… You will keep ownership of the core files (including wp-config.php and .htaccess) with your personal username.

Change all file ownership to your personal user and group
This is the basis for restricting users from working on core files.

cd /path/to/your/docroot
chown -R yourusername:yourusername

Change wp-content file ownership to the apache user and new domain group
This gives Apache and your dev group access to these files

cd /path/to/wp-content/
chown -R %APACHE_USERNAME%:domainnamegroup

Change file permissions

Go to your docroot

cd /path/to/your/docroot

Change all file permissions to 0664. This sets core files to read/write for your personal user and personal group and read only for the rest. This also sets user/group permissions for the wp-content directory as well.

find . -type f -exec chmod 0664 {} \;

Go to wp-content and change all directory permissions so dev users can add/delete/modify files within. This keeps WordPress from flashing the FTP credentials screen. For plugins like W3TC, you might need to add a 0755 permission temporarily to wp-content itself so the plugin can build out the file structure it needs.

cd path/to/wp-content
#Allow apache and your dev users to add/modify/delete files within wp-content directories
find . -type d -exec chmod 0755 {} \;

Automatic Core Upgrades

I’m not a big fan of allowing automatic core upgrades if there are other WP admins using the site. I prefer to keep control of this and not have unmitigated disasters (with older plugins and themes) because someone is trigger happy. The setup I described above will not all for automatic upgrades. I typically upgrade manually to keep file permissions static. However, if you want to allow for auto upgrades temporarily, you can do the following:

cd /path/to/docroot
#Allow all directories except wp-content to be modified
find . -type d \( -iname "*wp-*" ! -iname "wp-content*" \) -exec chmod 0755 {} \;

#Add the apache user group to all files
#This allows temporarily locks out your dev group while the upgrade takes place
chown -R yourusername:%APACHE_USERNAME%

#Run the upgrade
#Revert permissions back

#Make all directories except wp-content writeable
find . -type d \( -iname "*wp-*" ! -iname "wp-content*" \) -exec chmod 0644 {} \;

#All core files belong to you
chown -R yourusername:yourusername

#Give your dev group access to wp-content directories/files again
cd /path/to/wp-content/
chown -R %APACHE_USERNAME:newdomaingroup

Caveat

Not all systems are created equal. These settings might not work well on a shared environment. Contact your host if standard permissions don’t work. Command line gives you much power, use it wisely. I take no responsibility for your command line work.

Bash