Ekto gammit

WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY!

permissions_noobie.pngWith issues arising from varying Shared Hosting Packages, versions of PHP, Apache, etc., file permission issues sometimes rear their ugly head. I’m hoping the following reference can provide some help or direction to those less experienced:

A “file not found” “404”, “Unable to create directory”, “cannot open” or “doesn’t exist” error stops things dead in their tracks. This is usually due to a program/script not finding a script or file where it expects to, or it isn’t ‘allowed’ to see it because of the permission settings on the file or it’s directory.

Let’s start with the path. Check your error carefully, it will usually list the path to file in question. I recommend using the FileZilla FTP program .FileZilla interface Open FileZilla and connect to your site. Navigate through the path listed in the error and try to find the file. If it’s missing, try uploading it again and test… If the path is different, verify if you have wordpress installed in the ‘top’ or root directory or if it’s in a sub-directory.

If you found it and the path is correct, check the permissions. 

File permissions image

For this example, I’ll number the permissions flags:


1     directory flag, ‘d’ if a directory, ‘-‘ if a normal file, occasionally ‘l’ for a link.
2,3,4     read, write, execute permission for User (Owner) of file
5,6,7     read, write, execute permission for Group
8,9,0     read, write, execute permission for Other (Sometimes called ‘everybody’).

–     in any position means that flag is not set
r     file is readable by owner, group or other
w     file is writeable. On a directory, write access means you can add or delete files
x     file is executable (only for programs and shell scripts – not useful for data files). Execute permission on a directory means you can list the files in that directory
s     in the place where ‘x’ would normally go is called the set-UID or set-groupID flag (On an executable program with set-UID or set-groupID, that program runs with the permissions of its owner/group. On a directory, the set-UID/set-groupID forces files and directories created inside to inherit the user/goup of the parent directory).

“Typical WordPress installs only need the wp-content/ directory to be 777 (temporarily)…”

For security, the permissions settings for WordPress should be 755 for directories and 644 for files. Most hosts, however, require all processes spawned by a user to have a unique identity to add another level of security. So if WordPress or a plugin creates a file or directory, it will have a unique owner (and often group), so the directory with 755 won’t let us create files in it and the file with 644 won’t let us save changes to it. So, a change has to happen.

This is where we hit the “Your Mileage May Vary” area. Typical WordPress installs only need the wp-content/ directory to be 777 (so that WordPress can create the wp-contents/uploads/ folder). If your wp-content/uploads/ already exists you can hop right over and make wp-content/ 755. If you enabled Organize my uploads into month- and year-based folders then the sub-directories need to be checked as well (wp-content/uploads/2012/06 for example), so you will need uploads/ to be 777, 2006/ to be 777 and 06/ to be 777.

This is one reason I suggest you turn off Organize my uploads into month- and year-based folders because you are going to have a problem with permissions every month when a new directory needs to be created. Just let them all go to /wp-content/uploads.

Some people use the editor in the admin to edit theme and plug-in files (I recommend against this unless you can maintain 644 on the files being edited there), discover they have permission issues (as the PHP process will have different credentials on most servers) and change their files to 666. I’m uncomfortable with this. And I have a crush on FileZilla. Yes, I need to get out more.

If I ftp to my site with FileZilla and double-click on a file, it opens in my favorite text editor ( Edit:Settings:File viewing / editing in FileZilla’s menu) and in a much more ‘comfortable’ environment I can make changes, save, and click OK to upload the changed file to the server. The other benefit to this is that the file is being read and written through ftp which maintains my user/group identity, giving me more security and control.

If you have any suggestions for this article, feel free to leave a comment…

Tagged with: , , , , , , ,
Posted in Computers, Things, WordPress
54 comments on “WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY!
  1. Flirt says:

    Very helpful. This has solved my problem, thank you Sam.

  2. term paper says:

    Thanks for this advice Sam! This is something that has bugged me for some time. It seems like standard practice on WordPress installs is to use CMOD 777 directories for file uploads. And it’s unbelievable dangerous!

  3. Sam says:

    If you find yourself having to chmod 777 the wp-content/uploads directory for your site to work, I recommend changing your web host.

  4. Muskelaufbau Shop says:

    Thank you very much for this!
    Its work for me very well.
    Best Regards from Germany

  5. Catering says:

    This is exactly what i was searching for, thank you.

  6. Marco says:

    I had never problems with WordPressand CHMOD

  7. Diabetes Reader says:

    Thanks for the most informative article. I had trouble troubleshooting wordpress blog.

  8. Sandra Lewis says:

    Nice information. In shared hosting folder permission should set to 755 and file permission should set to 644.

  9. muamat says:

    Thanks for this helpful discussion. It helped me to solve my wordpress directory permissions problems.

1 Pings/Trackbacks for "WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY!"
  1. […] WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY! | Sam Devol September 2, 2010 Leave a reply […]

Leave a Reply

Your email address will not be published.