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. Roo says:

    Thanks, very helpful. I was looking for something similar to this.

  2. Sam says:

    You’re welcome!

  3. Sam says:

    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.

  4. Daryl Oberacker says:

    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

  5. edgars says:

    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.

  6. Sam says:

    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.

  7. Anthony says:

    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.

  8. Sam says:

    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.

  9. Pizdin Dim says:

    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:


    EDIT: What I neglected to say above is that security issue applies if the hosting provider allows SSH access to your account.

  10. Sam says:

    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 ;’)

  11. Adi Yesaya says:

    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)?

  12. Sam says:

    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 web-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.

  13. 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 🙂


  14. Sam says:

    Thirstan: Yes, nothing has 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.

  15. namnum says:

    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.

  16. Grump says:

    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.


  17. hi, i tried to chmod wp-content from 755 to 644, but the result always becomes 764. any idea? thanks

  18. tuning blog says:

    great article, now everything is working fine, thx.

  19. wafwot says:

    Three words: PHP safe mode.

    I was chasing this problem for a customer for about an hour. The uploads directory is owned by the apache user, but any year or month directories WordPress tried to create in uploads failed until I turned off PHP safe mode. Now it works like a chizzamp!

  20. Matt says:

    Cheers Sam. Just bumped into this problem whilst migrating a WordPress.com to .org blog on a new host. This is the first time I’ve had to change file permissions.



  21. woow great post, this will be very helpful for me. Thanks for this great piece of work.

  22. I had tried changing permission, to changing paths but nothing worked.

    Until Bard ‘s comment .

    I changed the path by removing the front slash before wp-content/uploads… and it worked:)

  23. rj.techie says:

    Hello, there is no use of giving permission inside the server for this. Just log into the WP using the admin credentials and then go to settings –> miscellaneous –> and then copy and paste the default path shown there. This will fix the issue and I had fixed it just now…:-) It is so simple. Don’t bang too much for a simple issue.

    Systems Engineer

  24. Sam says:

    Thanks RJ, but it’s a bit more complicated with some web hosts.

  25. Alia says:


    I have problems with permissions on my WordPress platform and noone seems to know how to solve them. Please help!
    When I try to change the permissions on some files, like index.php (which is pretty crucial file, I’m sure you would agree)to 666, I get this line: 500 ‘SITE CHMOD 666 index.php’: command not understood

    Same thing happens when I try to write the command manually.

    I don’t know what else to do. My hosting does not provide acces to cPanel and they use Windows and they say that that they would have “read only” mark on the files if they were only readable, but they don’t have them, so I should be able to change permissions. But I am not. They also say I maybe could change the server settings inside of wordpress but I haven’t find where I can do that yet.

    Is there anything else I can do?Please help!

  26. Sam says:

    @Alia: Windows is a totally different animal when it comes to permissions. I suggest you ask your host to move you to a linux server, and if they can’t, find another host… Permissions is only one of the problems you may experience running WordPress on a Windows server ;’)

    And, regarding index.php; It should not be 666, that would mean others could write to it. Make it 644.

  27. Alia says:

    I’ve already tried 644, too, but nothing works.
    I don’t think they can move me to Linux, either.

    I’ve already been told that it’s better to find another hosting, it seems I’ll really have to.:)
    Thanks anyways!

  28. Alia says:

    It’s me again. My hosting has after all managed to move me to Linux platform, but the problem persists. In Filezilla the permission is “644”, but I cannot write in the file in the WordPress- it still says that I have to change the permission before I can write. (??)

    Furthermore, now even thos permissions I had are gone.

    Any ideas?

  29. Sam says:

    @Alia: It sounds like we are getting to the last 2 paragraphs of the article; Your host is mapping PHP processes to another ‘user’ (not another person, but another ‘id’), which is one form of ‘security’ that used to be popular. I suggest you use an FTP program in those environments (not the internal editor).

    Don’t regret the switch to a linux server, there’s several more issues that could (would?) have popped up using a M$ server…

  30. Alia says:

    I tried that and it worked. Thank you so very much! After app. 10 informaticians I asked didn’t know how to solve this problem (including hosting support), you’re a real life saver! 🙂

  31. I bookmarking this page.
    I use wordpress, this article will helps me someday.

  32. Kreuzfahrten says:

    Great article, I really like it. Thanks

  33. Kreuzfahrten says:

    thanks for that great post.

  34. Ali R. Khan says:

    indeed File permission is very ticks..Thanks for helping out.

  35. tadasjazokas says:

    Thank you very much! 🙂

  36. azzaam says:

    thanks you, its work for me 😀

  37. Jason says:

    my hosts shut down 8 of my sites (5 wordpress) due to ‘unusual activity’ and I checked every file using CPanel. I found the dodgy files on a zen-cart install and folders were chmod 777 and files 666.

    While doing that, I noticed my wp-content/uploads were all 7’s & 6’s so thanks for your detailed explanation on how to resolve the problem. I’ve changed them to 755/644 but if WP can’t write at the end of the month, I know why…


  38. NH says:

    I need help. 755 and 644 do not allow me to access pages and posts… what to do? I’m going nuts.

  39. Sam says:

    @NH: Pages and posts aren’t files… Can you give me more information?

  40. photocurio says:

    I don’t get where you enter three digit file permission codes. the 755 and 644 codes. i’m looking at my site with Plesk, to check the permissions on my server and all i see are hte long codes such as rwx r-x r-x.

    I get a “Forbidden.. You don’t have permission to access /wordpress/wp-admin/upload.php on this server.” when i try to post. changing permissions on the referenced file has no effect.

  41. Sam says:

    >>I don’t get where you enter three digit file permission codes. the 755 and 644 codes.

    See my recommendation above about Filezilla/FTP…

  42. or you can just set the permission to 751 to the directory you dont want to make public

  43. thecoolcat11 says:

    Thanks for this.. i was looking for set of permission in my website… i hope it’ll work, I’m gonna try this….

  44. Wardell says:

    I wonder if many of theses permission issues can be tracked back to the way WordPress is installed, ie using quick install packages now provided by many web host. I’ve never encountered any of these permission issues with a fresh manual installation of WordPress. Only with preexisting installations or setups being moved from one server to another.

  45. Sam says:

    That’s often the case…

5 Pings/Trackbacks for "WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY!"
  1. Pimp my Politics » Blog Archive » WP permissions says:

    […] uploads to 775 and turned off Organize my uploads into month- and year in my word press settings. Read this post if you want to read it from the dude I read it […]

  2. WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY! » Sam Devol says:

    […] the rest here: WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY! » Sam Devol Tags: file – security – upload Comments0 Leave a Reply Click here to cancel […]

  3. […] gönderdikten sonra uploads klasörüne yüklemek yapmak için klasörün yazım kurallarını CHMOD 777 yapmanız […]

  4. Choice picks for February 26th from 09:45 to 18:21 « Inverse Design says:

    […] WordPress Troubleshooting: Permissions, CHMOD and paths, OH MY! | Sam Devol – With issues arising from varying Shared Hosting Packages, versions of PHP, Apache, etc., file permission issues sometimes rear their ugly head. I'm hoping […]

  5. How to Optimize Your Chiropractic Website’s WordPress Settings — Chiropractic Business Network says:

    […] permissions for the uploads/ directory to 755 instead of 777 as would otherwise be required. (See this blog post for more information on WordPress […]

Leave a Reply

Your email address will not be published.