Reading This
WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY!
With 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 .
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.
For this example, I'll number the permissions flags:
drwxrwxrwx
1234567890
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).
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/2006/06 for example), so you will need uploads/ to be 777, 2006/ to be 777 and 06/ to be 777. If you are using the ImageManager plugin, you will need to check the permissions on wp-content/uploads/2006/06/.thumbs/ as well!
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…
17 Users Commented on " WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY! "
Roo says,Thanks, very helpful. I was looking for something similar to this.
My ex girlfreind set up this site, and I have always edited it, but suddenly the EDIT button on my screen site is GONE? I can’t access any edit opions? How can I get this back, as my ex is unavailable? I need to post new stuff ASAP? Can someone help me? Daryl
Until you figure out why the 'Edit' button disappeared, you can always try [yourdomainhere].com/fishing/wp-admin and that should force the WP login screen to come up.
I have a problem with downloading images to WP.. So if I got it right,then all of my wp-content permissions should be 644.
edgars: The following is from the paragraph that I think applies to you:
“Typical WordPress installs only need the wp-content/ directory to be 777 (so that WordPress can create the wp-contents/uploads folder). If you enabled Organize my uploads into month- and year-based folders then the subdirectories need to be checked as well (wp-content/uploads/2006/06 for example). ”
Any DIRECTORY WordPress is designated to use may need to be 777.
Changinging the mode of the wp-content/ directory to 777 which is largely regarded as insecure is a running theme throughout Wordpress. But that isn’t strictly true if you have shell access: The problem is that on a Linux box, php scripts run as nobody but the directory is owned by the user so nobody can’t write to it unless it’s chmod 777. A better solution is to change the ownership of the directory to nobody and then the upload directory can be chmod 755 and all directories created by Wordpress are also chmod 755.
In the shell cd to the Wordpress root directory and then type and enter:
chown nobody wp-content
If you don’t have shell access, ask your web host to do it for you.
But if your server is running with phpsuexec enabled, php scripts are run as the user which also has write access to directories owned by the user. So in that instance the upload directory can be chmod 755.
It’s unfortunate that shell access is getting more and more rare with regular hosting plans.
And 777 on a modern host is not as dangerous as it might sound, it still would take certain process/config failures for it to be exploited, and since we’re talking about /uploads/ I’m not too worried about someone hacking the image/zip-files I keep there.
There’s a fundamental security issue with setting a file like “wp-config.php” to 644 in a shared environment: it allows other users on that host to read your database settings contained in that file. They can then use your database settings and do whatever they like with your database data. See this thread on the WP forums for more:
http://wordpress.org/support/topic/83831
EDIT: What I neglected to say above is that security issue applies if the hosting provider allows SSH access to your account.
Pizdin: This simply isn’t true in most modern shared environments.
But I appreciate the link, people are welcome to come to their own conclusions ;’)
Hi, i’m concerned with the 777 issue of wp-plugin/uploads/
What if people put some scripts to that folder which when executed will delete other files in other folders (or do some nasty things)?
Hi Adi:
Your concerns are valid. Depending on the host it often becomes a balancing act between security and ease-of-use.
If I had to use 777 (or 666 on files) as soon as I was done making changes I would be sorely tempted to switch everything back to 755/644. And I have when I was hosted with Network Solutions (whom I do not recommend as a host).
The problem usually lies with how the host assigns an identity to the user who logs in through ftp/etc. and the identity given to processes spun from inside WP’s admin interface (the PHP process(s)). These are usually different, and that’s why you see differences in behavior when editing/deleting/uploading files with ftp/etc. and when doing it within the WP admin area…
My current host, site5.com, addresses the security issues differently, so I can keep directories at 755 and files at 644 yet not receive any permission errors when using the WP admin tools.
On the other hand, as Pizdin pointed out above (with some hosts), another user might be able to read my wp-config.php file in my current environment. This doesn’t concern me too much (I keep backups and most hackers won’t ‘poop in their own nest’ so to speak), but I did change wp-config.php to 600.
thirstan says,I am in the process of setting up another blog on a new host with my own domain name and having trouble with the permissions, your post seems to be exactly what I am looking for, I was wondering if the post is still timely for current WP?
Wow, that is one run-on sentence 
thanks,
thirstan
Thirstan: Yes, nothing hass really changed there.
The version of WP doesn’t really matter, although the host environment will. Example: At aplus.net (and Network Solutions) you will experience problems with WP not having ‘permission’ to create directories and files. However, hosts like site5.com handle it differently and you won’t notice any of the permission issues that arise with WordPress/PHP processes creating or editing files.
Sam thanks so much for this. I have been battling with 1and1 for the past week, because they couldn’t explain to me why all of a sudden my ecommerce plugin could no longer create thumbnails from the pictures we upload.
I think now I understand and might be able to get customer service to actually help me. I’ll read your post over and quote it in my email once I understand it fully.
Thanks again.
Best solution for this is to manually create your directory structure in advance. The only reason to require 777 is because wordpress needs to create these directories. However if the directories already exist a tighter set of permissions is possible. Therefore create the directories for the next couple of years (one folder for every month) then chmod directories to 755 and files to 644. Sometimes I have noticed that directories need 775 depending on your host.
Cheers!
hi, i tried to chmod wp-content from 755 to 644, but the result always becomes 764. any idea? thanks
