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.