Different files and directories in Linux-based file system use permissions to indicate who and what can read, write, modify and access them. WordPress file permissions matter because it might want access to write to files in your wp-content directory.
Permission Modes
| 7 | 5 | 5 |
| user | group | others |
| r+w+x | r+x | r+x |
4+2+1 4+0+1 4+0+1 = 755
WordPress file permissions modes are computed by adding up the following values for the user, the file group, and for everyone else. The diagram illustrates this.
- Read 4 – Allowed to read files
- Write 2 – Allowed to write/modify files
- eXecute 1 – Read/write/delete/modify/directory
| 7 | 4 | 4 |
| user | group | others |
| r+w+x | r | r |
4+2+1 4+0+0 4+0+0 = 744
Example Permission Modes
| Mode | Str Perms | Explanation |
| 0477 | -r–rwxrwx | owner has read only (4), other and group has rwx (7) |
| 0677 | -rw-rwxrwx | owner has rw only(6), other and group has rwx (7) |
| 0444 | -r–r–r– | all have read only (4) |
| 0666 | -rw-rw-rw- | all have rw only (6) |
| 0400 | -r——– | owner has read only(4), group and others have no permission(0) |
| 0600 | -rw——- | owner has rw only, group and others have no permission |
| 0470 | -r–rwx— | owner has read only, group has rwx, others have no permission |
| 0407 | -r—–rwx | owner has read only, other has rwx, group has no permission |
| 0670 | -rw-rwx— | owner has rw only, group has rwx, others have no permission |
| 0607 | -rw—-rwx | owner has rw only, group has no permission and others have rwx |
Permission Scheme for WordPress
WordPress file permissions will vary between hosts, so we can only outline general principles here and can’t cover all scenarios. This guide is relevant to servers that run a standard setup (note, for shared hosting using “suexec” methods, see below).
Usually, all files should be owned by your user (ftp) account on your web server and should be writable by that account. On shared hosts, files shouldn’t ever be owned by the webserver process itself (sometimes this is www, or apache, or nobody user).
A file that needs write access from WordPress should be owned or group-owned by the user account used by WordPress (which may be different from server account). For instance, you might have a user account that lets you send files to your server via FTP, but the server itself may run under a separate user, in a separate usergroup, like dhapache or nobody. If WordPress is running as the FTP account, that account must have write access, meaning it must be the owner of the files, or be in a group that has write access. If that’s the case, it would mean permissions are set more permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644).
The file and folder permissions for WordPress will probably be the same for most users, depending on how you installed it and the umask settings of your system environment at the time of installation.
You probably won’t need to be changing file permissions if someone with experience installed WordPress for you. It’s best not to alter his unless you’re having problems with permission errors, or you know what you’re doing. If you installed WordPress yourself, you probably WILL need to change WordPress file permissions permissions. Some files and directories should be “hardened” with more strict permissions, in particular, the wp-config.php file. To start with, this file is created with 644 permissions, but it isn’t safe to leave it like that.
In most instances, all essential WordPress files should only be writable by your user account (or the httpd account, if it’s different). ( Sometimes though, numerous ftp accounts may be used to manage an installation, and if all ftp users are known and trusted, meaning not shared hosts, it may be okay to assign group writable. Ask your server admin about this. ) However, if you make use of mod_rewrite Permalinks or other .htaccess features you should ensure that WordPress can also write to your /.htaccess file.
If you’re going to use the built-in theme editor, all files need to be group writable. It’s best to use it before you go changing file permissions. (This may hold true if different users uploaded the WordPress package and the Plugin or Theme. This wouldn’t be a problem for Plugin and Themes installed using the admin panel. When you upload files with different ftp users, group writable will be needed. On shared hosting, ensure the group is exclusive to users who you trust… an apache user shouldn’t be in the group and shouldn’t own files.)
Some plugins need the /wp-content/ folder to be made writeable, but in cases like this, you will be informed about it during installation. In some instances, you may need to assign 755 permissions. This is also true for /wp-content/cache/ and possibly /wp-content/uploads/ (if you’re using MultiSite setup you may also have to do this for /wp-content/blogs.dir/)
Additional directories under /wp-content/need to be documented by whichever plugin / theme requires them. Permissions will vary.
/
|- index.php
|- wp-admin
| `- wp-admin.css
|- wp-blog-header.php
|- wp-comments-post.php
|- wp-commentsrss2.php
|- wp-config.php
|- wp-content
| |- cache
| |- plugins
| |- themes
| `- uploads
|- wp-cron.php
|- wp-includes
`- xmlrpc.php
Shared Hosting with suexec
This may not apply to shared hosting systems that use the “suexec” approach for running PHP binaries. This is a popular approach which many web hosts use. With these systems, the php process runs as the owner of the php files themselves, which simplifies configuration and provides a more secure environment for shared hosting.
Do not use suexec methods on a single-site server configuration. They are only the most effective option for shared hosting.
With suexec configuration, the correct WordPress file permissions scheme is easy to understand.
- All files should be owned by the actual user’s account, not the user account used for the httpd process.
- Group ownership is not relevant unless there are particular group requirements for the web-server process permissions checking. This doesn’t usually happen.
- All directories should be 755 or 750.
- All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to stop other users on the server from reading it.
- Directories should never be given 777, not even upload directories. As the php process is running as the files’ owner, it gets the owners permissions and can even write to a 755 directory.
With this particular type of setup, WordPress detects that it can directly create files with the proper ownership, and so it will not need to request FTP credentials when it has to install or upgrade plugins.
sysadmins use these popular methods are set up:
- suPHP: runs through php-cgi, currently unmaintained since 2013.
- mod_ruid2: apache module, currently unmaintained since 2013.
- mpm_itk: apache module.
- mod_fcgid: an Apache module and FastCGI server with more extensive configuration.
PHP-FPM, an alternative FastCGI server with shared OPCode, for use with Apache and Nginx.
How to Use the Command Line
If you have shell/SSH access to your hosting account, you can use chmod for changing file permissions, which is the preferred method for experienced users. Before you start using chmod it’s recommended that you go through some tutorials to ensure you understand how it works. If you set the wrong WordPress file permissions you could end up taking your site off-line, so it’s best to be safe rather than sorry.
You can make all the files in your wp-content directory writable in two steps, but before you do, consider safer options like modifying just the directory first. Give each of these commands try first, and if they don’t work then go recursive. This will even make the image files of your themes writable. Replace DIR with the folder you want to write to
chmod -v 746 DIR
chmod -v 747 DIR
chmod -v 756 DIR
chmod -v 757 DIR
chmod -v 764 DIR
chmod -v 765 DIR
chmod -v 766 DIR
chmod -v 767 DIR
If those don’t let you write, try each of them again in order, only this time put-R instead of-v, which will recursively modify each file that’s in the folder. If that still doesn’t work then try 777.
About Chmod
chmod is a Unix command which means “change mode” on a file. The -R flag tells it to apply the change to every file and directory inside wp-content. 766 is the mode we are changing the directory to, and it makes the directory readable and writable by WordPress and any and all other users on your system. At last, we have the name of the directory we are going to modify, wp-content. If 766 doesn’t work, then try 777, which makes every file and folder readable, writable, and executable by all users, groups, and processes.
If you use Permalinks then remember to change WordPress file permissions of .htaccess to ensure that WordPress can update it when you change settings, like when you a new page, redirect, category, etc. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.
- Go to the main directory of WordPress
- Enter chmod -v 666 .htaccess
From a WordPress security point of view, even a little protection is better than a directory that’s wide open to anybody to rewrite. Start with low permissive settings like 744 and work your way up until your successful. Only use 777 if you have to, and hopefully then only for a short while.
The dangers of 777
The root cause of this permission situation is the manner of your server configuration. The username you use to FTP or SSH into your server is probably not the username that the server application itself uses to serve pages.
| 7 | 7 | 7 |
| user | group | others |
4+2+1 4+2+1 4+2+1 = 777
The Apache server is frequently ‘owned’ by the www-data, dhapache or nobody user accounts. These accounts have limited access to files on the server, and with good reason. If you set your personal files and folders owned by your user account to be World-Writable, that’s exactly what you are doing. It means that the www-data, dhapache and nobody users that run your server, serve pages, execute php interpreters, and so on, can get at all of your user account files, and they can do this using any process on the server.
That’s why it’s best to only change WordPress file permissions when you are forced to, and even then with great care. We’ve never come across a situation what warranted more than 767, so it’s hard to imagine why 777 would be required.
If you do use 777 permissions, what’s the worst that could happen? Well, a nefarious individual could upload a harmful file, or inject malicious code to gain total control of your blog, its database and password info.
You can easily get the enhanced features that WordPress plugins can provide without exposing yourself to risk. The Plugin author or your server support should be able to give you a workaround.
Finding Secure File Permissions
The .htaccess file is one that’s accessed by the owner of the process that runs the server. So, if your WordPress file permissions are set too low, your server will be denied access to the file and return an error. It shows you the way to find your best settings. Start with greater restriction and then relax it until it works.
The example below has a custom compiled php-cgi binary and a custom php.ini file located in the cgi-bin directory for executing php scripts. To stop a web browser directly accessing the interpreter and php.ini file they are protected by a .htaccess file.
Default Permissions (umask 022)
- 644 -rw-r–r– /home/user/wp-config.php
- 644 -rw-r–r– /home/user/cgi-bin/.htaccess
- 644 -rw-r–r– /home/user/cgi-bin/php.ini
- 755 -rwxr-xr-x /home/user/cgi-bin/php.cgi
- 755 -rwxr-xr-x /home/user/cgi-bin/php5.cgi
Secured Permissions
- 600 -rw——- /home/user/wp-config.php
- 604 -rw—-r– /home/user/cgi-bin/.htaccess
- 600 -rw——- /home/user/cgi-bin/php.ini
- 711 -rwx–x–x /home/user/cgi-bin/php.cgi
- 100 —x—— /home/user/cgi-bin/php5.cgi
.htaccess permissions
644 > 604 – The bit giving the group owner of the .htaccess file read permission was got rid of. 644 is normally recommended and needed for .htaccess files.
php.ini permissions
644 > 600 – Before, all groups and all users with access to the server could access the php.ini, even just by requesting it from the site. The difficulty is that because the php.ini file is only used by the php.cgi, we only needed to ensure the php.cgi process had access. The php.cgi runs as the same user which owns both files, so that single user is now the only user which can access this file.
php.cgi permissions
755 > 711 This file is a compiled php-cgi binary used in place of mod_php or the default vanilla php which the hosting company provides. The default permissions for this file are 755.
with
No comment yet, add your voice below!