Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

WordPress Permissions – How To Set Up Proper Filesystems And Ownerships

When people talk about WordPress security, file permissions and ownership are usually the last thing on their minds. Installing security plugins is a good practice and a must for every WordPress website. However, if your file-system permissions aren’t set up correctly, most of your security measures could be easily bypassed by intruders.

wordpress permissions

Permissions and ownership are quite important in WordPress installations. Setting these up properly on your Web server should be the first thing you do after installing WordPress. Having the wrong set of permissions could cause fatal errors that stop your website dead. Wrong permissions can also compromise your website and make it prone to attacks.

Further Reading on SmashingMag: Link

Aside from the security concerns, a number of other issues can stem from having the wrong set of permissions and ownership. Have you ever encountered a blank white screen when trying to load your website for the first time? Or have you ever received error messages when trying to upload images in the media uploader? Correcting permissions and ownership of your files and folders will often fix these types of problems.

In this article, we will teach you all about WordPress filesystem permissions and ownership: what they are, why they are important and how to set them up. You will learn a few basic principles that I follow to keep my file system intact. We will also cover the two most common WordPress server configurations. We’ll explain how they differ and, more importantly, how to set the proper permissions and ownership for each.

Terminal Vs. FTP Client Link

During the course of this article, we will be using the terminal to change permissions and ownership. Why not use an FTP client instead? The reason is that FTP is a bit limited for our needs. FTP can be used to transfer files and change file and folder permissions, but it cannot be used to change ownership settings.

To perform the commands listed in this article, you will have to be logged into your server using the SSH command. If you are not familiar with the terminal and SSH, you can learn about them in the article “Introduction to Linux Commands5.”

Users And Groups

Before anything else, we need to quickly talk about what users and groups are, because these go hand in hand when defining permissions.

To put it simply, a user is an account that has access to the computer, and a group just is an identifier for a certain set of users. This means that every time you transfer files using FTP, you are using a user account on your server. And depending on how your host has set up your account, you (the user) might belong to one or more groups. Users and groups are like users and roles in WordPress. Both are conceptually the same, except that the former is used on your server.

Users and groups are important because they help to identify privileges for all of our files and folders. Owners of a file normally would have full privileges on it; other users who belong to the same group would have fewer privileges on it; while everyone else might have no privileges on it. These privileges are what we call permissions.

What Are File Permissions? Link

Permissions dictate what users can do with a file. A permission is represented by a set of numbers, such as 644 or 777, referred to as a permission mode. If you have used plugins in WordPress before, then you’ve most likely been asked by some of them to change the permissions of a file or directory because the plugin can’t write to it. By changing the file’s permissions, you are allowing the Web server to gain access to that file or folder.

Think of a permission mode as a set of “who can do what” statements, in which each digit corresponds to the “who” part of the statement:

  • First digit
    What the user of the account that owns the file can do
  • Second digit
    What other user accounts in the owner’s group can do
  • Third digit
    What the user accounts of everyone else (including website visitors) can do

Next, the number corresponds to the “what” part of the statement and is a sum of a combination of any these digits:

  • 4
    Read a file, or read the names of the files in a folder
  • 2
    Write or modify a file, or modify the contents of a folder
  • 1
    Execute or run a file, or access the files in a folder

These digits are the privileges that are assigned to the “who” in the permission mode. Note in the list above that privileges mean something different for files and folders.

Using the correct permission mode is quite important. To better illustrate this, think again of users and roles in WordPress. On a WordPress website, contributors and administrators have different sets of capabilities. Contributors may create new blog posts, but they may not add plugins. Administrators, on the other hand, may add plugins and also create blog posts. Administrators may even change the look of the website if they want to. A clear line separates what users in different roles can do. This is the same with permission modes, except that instead of dealing with blog posts and theme options, we are dealing with files and folders on the server.

Changing Permission Modes

FTP clients usually provide an interface where you can conveniently change the permission mode of your files and folders. Here’s a screenshot of the interface in my FTP client:

Example of a permission mode interface.
Example of a permission mode interface.

If you have access to your server’s terminal, you can also use the chmod command to change the permission mode of a file or folder:

sudo chmod 644 <file>

To change the permission modes of all files or folders, use chmod in tandem with the find command. For example, you can use this to change all files to 644:

sudo find . -type f -exec chmod 644 {} +

Or use this to change all of your folders to 755:

sudo find . -type d -exec chmod 755 {} +

Refer to “Changing File Permissions in the WordPress Codex6” for a guide to changing permission modes.

The Difference Between 644 And 777 Link

Let’s look at some permission modes and how they affect our website.

What would a PHP script with a permission mode of 644 mean? Following the explanation above of how permission modes work, we can decipher what this mode allows users to do with our script:

  • The owner’s privileges are “read” (4) + “write” (2) = 6
  • The owner’s group privileges are “read” (4) = 4
  • Everyone else’s privileges are “read” (4) = 4

In plain language, this means that:

  • if we own the script, we may read and modify it;
  • everyone else may only read it.

As we can see, 644 is a good permission mode for our PHP script. We can make changes to it, and our Web server can read it.

Now let’s look at folders. What if we owned a folder that had a permission mode of 777? This permission mode can be broken down as follows:

  • The owner’s privileges are “read” (4) + “write” (2) + “execute” (1) = 7
  • The owner’s group privileges are “read” (4) + “write” (2) + “execute” (1) = 7
  • Everyone else’s privileges are “read” (4) + “write” (2) + “execute” (1) = 7

This means that

  • anyone may get a list of file names in our folder;
  • anyone may create, modify and delete any file in our folder;
  • anyone may access the files in our folder.

It is obvious that 777 is a bad permission mode for anything on our WordPress website because any visitor would be able to add files to our directory or even delete scripts. Worse, anyone would be able to put in malicious code and compromise our website.

WordPress Server Configurations Link

Now we know about permissions and how to read them. But before proceeding to change all of our permissions, we need to understand how our server is set up. Because permissions deal with user accounts and groups, we need to know how our WordPress website runs.

A lot of different server configurations are out there. Different configurations need different sets of permission modes for WordPress to work correctly and securely. We’ll talk about just the two most common configurations and the proper permissions for them:

  • Standard server configuration:
    • You have a user account.
    • Your Web server runs as another user account.
  • Shared server configuration or suEXEC configuration:
    • You have a user account.
    • Other people who use the server have user accounts and might share the same group with your user account.
    • Your Web server runs as the owner of your WordPress files.

The main difference between these two is in how the Web server runs.

Permissions For A Standard WordPress Server Configuration Link

Standard WordPress configurations require a bit more work than shared server configurations because the Web server has no relationship to our user account.

File and Folder Ownership for WordPress Link

First, we need to adjust the file and folder ownerships of our WordPress files. We’ll have to make sure of the following:

  • that your user account is the owner of all WordPress files and folders,
  • that your user account and the Web server’s user account belong to the same group.

To find out the groups that your user account belongs to, you can use this command in your server’s terminal:


Then, to find out the groups that your Web server belongs to, you can temporarily insert this PHP snippet in one of your WordPress scripts:

echo exec( 'groups' );

If your user and the Web server don’t belong to the same group, you can use the following command in the terminal to add your user to one of your Web server’s groups:

sudo usermod -a -G <a-common-group-name> myuser

Lastly, to ensure that everything in our WordPress folder belongs to our user account and has the shared group that we just added, perform this command in your WordPress folder:

sudo find . -exec chown myuser:a-common-group-name {} +

Permissions for WordPress Link

All of our files and folders should now have the correct ownership. Now it’s time to adjust the permission modes. To make things simpler, you’ll only need to remember the following:

  • All files should be 664.
  • All folders should be 775.
  • wp-config.php should be 660.

Here’s what we’re trying to achieve with this set of permission modes:

  • Our user account may read and modify our files.
  • WordPress (via our Web server) may read and modify our scripts.
  • WordPress may create, modify or delete files and folders.
  • Other people may not see our database credentials in wp-config.php.

You might be thinking that allowing WordPress full privileges with our folders is not secure. Don’t worry — we’re doing this because WordPress needs certain features to create and modify files. WordPress allows us to upload and remove themes and plugins and even edit scripts and styles from the administrative back end. Without this type of permission, we would have to manually upload themes and plugins every time using FTP.

You can use your FTP client to change the permission modes, or you can use the following commands in your WordPress directory to quickly adjust the permissions of all of your files and folders:

sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
sudo chmod 660 wp-config.php

Note that some Web servers are stricter than others. If yours is strict, then setting your wp-config.php to 660 might stop your website from working. In this case, just leave it as 664.

Permissions For A Shared Server Configuration Or SuEXEC Configuration Link

Permissions for shared server configurations are easier to implement. We won’t dwell on ownership because the Web server runs as the owner of our files and folders. Because our user account and the Web server share the same permissions (both are owners), we can dive right into modifying the permission modes:

  • All files should be 644.
  • All folders should be 755.
  • wp-config.php should be 600.

Similar to the previous set of permission modes, these break down as follows:

  • Our user account may read and modify our files.
  • WordPress (via our Web server and as the account owner) may read and modify our scripts.
  • WordPress may create, modify or delete files or folders.
  • Other people may not see our database credentials in wp-config.php.

Again, you can use an FTP client to change the permission modes, or you can use the following commands in your WordPress directory to quickly adjust the permissions of all of your files and folders:

sudo find . -type f -exec chmod 644 {} +
sudo find . -type d -exec chmod 755 {} +
sudo chmod 600 wp-config.php

Similar to the standard WordPress server configuration, your server might be stricter than others and might not allow wp-config.php to be 600. In this case, you can adjust it to a more lenient 640; if that still doesn’t work, then use 644.

Always follow these guidelines and your WordPress files should be kept safe from intruders.

Common Pitfalls Link

A common mistake people make is to set the uploads folder to 777. Some do this because they get an error when trying to upload an image to their website, and 777 quickly fixes this problem. But never give unlimited access to everyone, or else you’ll make the Web server vulnerable to attack. If you follow the guidelines covered in this article, then you should have no problems uploading files to your website.

At times, though, a plugin will request that you set a file to 777. On these occasions, you can temporarily set it to 777, but make sure to set it back to its original permission mode when you’re done.

Conclusion Link

We’ve learned now about the proper permissions and file ownership of a WordPress website. We’ve also learned to avoid a permission mode of 777 because of how it endangers the Web server.

Hopefully, you can implement these tips to keep your WordPress website safe and secure. If you have any additional tips regarding permissions and security, please share them in the comments below.

Excerpt image credit: Christopher Ross7

(al, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7

↑ Back to top Tweet itShare on Facebook

Benjamin is a designer and WordPress developer from the Philippines who loves creating WordPress themes for ThemeForest and tinkering around with jQuery plugins in GitHub. He is the creator of Titan Framework, and runs a small start up named Gambit which specializes in WordPress development.

  1. 1
  2. 2

    Brian Lang

    May 8, 2014 3:44 pm

    Useful article! Now, can you please do it again for Windows / IIS? Thanks!

    • 3

      Benjamin Intal

      May 8, 2014 4:22 pm

      The concepts are still the same for Windows / IIS, maybe you can use the `takeown` command in Windows

  3. 4

    I think the best way is to treat WordPress instance as a read-only box. And symlink the upload folder to somewhere else with right permission. Every time we deploy, just re-point the upload to it. That way, even if WordPress is compromised, attacker gain access to admin dashboard but still isn’t able to upload anything.

    • 5

      I don’t get your logic here. You might as well deploy a static site than mess around with WP.

      Moving the upload directory doesn’t really solve anything if your web server itself is compromised, it just complicates things. Everytime you make a request, now the web server has to work a bit harder to find the uploaded file. And ultimately you’re still serving uploads from somewhere.

      Ultimately you want to secure that folder to begin with—one example is by disallowing php to execute anything from it—than trying to move the uploads directory out of the document root. Basically that “taint” test has to be done somewhere if you allow file uploads on your server.

      Permissions are a good start but I still see people use vulnerable nginx configs that leave the door wide open regardless of you have the right permissions or not.

      • 6

        Benjamin Intal

        May 9, 2014 11:13 am

        Good points. You’ll really need proper server configurations, or else your site will still be compromised.. but that’s another topic :)

  4. 7

    Thanks for your article, it’s great to have a proper explanation of what these permissions mean and how best to set them.

  5. 8

    Great article. Thanks :)

  6. 9

    Cheers Great Article :)

  7. 10

    1) set wp-config to chmod files and folders for you

    define( ‘FS_CHMOD_DIR’, ( 0755 & ~ umask() ) );
    define( ‘FS_CHMOD_FILE’, ( 0644 & ~ umask() ) );

    2) Move wp-config above the public_html accessable folder

    3) Get a robots.txt file corectly configured and a WP security plugin

    4) Use .htpasswd to block access to wp-admin and wp-login.php

  8. 12

    Ian Bradbury

    May 9, 2014 5:21 am

    Brilliant and perfect timing. Thanks for putting this together.

  9. 13

    Thanks for your article and tips

  10. 14

    Surely apache module ‘suphp’ (mod_suphp) did away with this issue some time ago on unix type boxes. I have yet come across a host these days not using it. It negates the need to have to leave any permissions open yet still give apache the ability to write to files overcoming the ‘nobody’ ownership of files created by apache.

    I have not worried about this issue for ages with my own CMS.


    • 15

      Benjamin Intal

      May 10, 2014 11:49 am

      If you’re on a managed WP host, then most likely they have already have everything set up the way they should. I for one previously had a non-managed server :)

  11. 16

    Ultimately, it would be awful nice if WordPress secured itself after installation was complete. People shouldn’t need to take all kinds of steps to make sure the top blogging platform in the world is secure when they install it.

  12. 17

    I’m not sure how one tells if they are on a “Standard WordPress Server Configuration” or a “A Shared Server Configuration.” Aren’t most people, unless they’ve got a vps or managed hosting on Shared hosting?

  13. 18

    @Benjamin Intal, your article could not have been published at a better time. I have read of file permissions a million times but mostly scattered information which I often forget. This could now serve as a reference.

    I am trying to setup a VPS on DigitalOcean using a script which makes creating new WP sites lot easier. However it adds 644 permission to files and 755 to folders which makes editing these files over FTP difficult and I always have to first change the rules from terminal and after modification change the permission back again. Now I guess with your article I could try one more time and make it work this time.

    • 19

      set wp-config to chmod files and folders for you
      define( ‘FS_CHMOD_DIR’, ( 0755 & ~ umask() ) );
      define( ‘FS_CHMOD_FILE’, ( 0644 & ~ umask() ) );

      I have a VPS on DigitalOcean as well, why not simply install an FTP app and then use something like FileZilla to do the chmod?

      Or you could use SSH to chmod files/folders

      Or you could use WinSCP that like FileZilla but runs using SSH

  14. 20

    I use Wordfence plugin. Has some nice security features.

  15. 21

    Ik heb geen naam

    May 9, 2014 10:51 pm

    Standard server

    Files: 660
    Folders: 770

    Shared server

    Files: 600
    Folders: 700

    Why even give any kind of permission to others?

    • 22

      Benjamin Intal

      May 10, 2014 11:58 am

      I don’t think that would work with, for example, the uploads folder. Since if you set 0 to a folder to everyone, your images be prevented from being loaded in browsers because the folder contents wouldn’t be readable.

      • 23

        You’re incorrect in assuming that a website visitor is a “user” in the system. The “user” that is accessing the files to send to a visitor is or should be the apache/httpd/www-data user (or a special user created on the system). Images will definitely still load on a properly configured server with 0 in the global range.

    • 24

      same for wp-includes folder and any images/css files the wp-content/plugins or wp-content/themes folders

      try using the itheme security plugin it has an option that stops scripts running in the uploads folder

  16. 25

    Jabran Rafique

    May 10, 2014 5:27 am

    Great article. I think this one completes the original article of WordPress about permissions by covering the ownership issue.

  17. 26

    I tend to be a little more stringent when it comes to the file permissions.

    The owner of the files in the web root should be apache (or whatever httpd user) 7 for folders, 6 for files. The group should be apache group, but if the owner is proper then the user should be serving properly. 5 (read and transverse) for folders 4 (read only) for files. Global access to the www root shouldn’t exist. 0 for folders and 0 for files. Anybody needing to read needs to be approved by the apache group, anybody needing to write needs to be apache user.

    I also go a step further and set wp-config.php to read only, because (in theory) it should never be changed once it’s configured: 440

    tl;dr: 750/640 folder/files and 440 wp-config.php

  18. 27

    Excellent information is provided by you. Thanks a lot for sharing such a great article.

  19. 28

    Sasha Baksht

    June 12, 2014 10:15 pm

    Had terrible experience with security plugins – things just went out of control! It is always better to manage permissions yourself.

  20. 29


    I’ve followed these instructions to a T, yet I continue to be asked for FTP credentials when attempting to install a plugin. Any advice?


    • 30

      You can add your ftp user and password to wp-config.php:

      define( ‘FTP_BASE’, ‘/path/to/wordpress/’ );
      define( ‘FTP_CONTENT_DIR’, ‘/path/to/wordpress/wp-content/’ );
      define( ‘FTP_PLUGIN_DIR ‘, ‘/path/to/wordpress/wp-content/plugins/’ );
      define( ‘FTP_USER’, ‘username’ );
      define( ‘FTP_PASS’, ‘password’ );
      define( ‘FTP_HOST’, ‘’ );

      That way it has all the info it needs. Just make sure you chmod 660 or 600 your wp-config.php so that nobody else can read your password

  21. 32

    I followed this step by step for the “Standard Configuration”. Doing this “sudo find . -exec chown myuser:a-common-group-name {} +” makes it so you can’t install plugins automatically (Without FTP). I know you can set up FTP and store your credentials in wp-config.php, but I don’t want to use FTP at all. The only way I have found to get this working is using: “sudo find . -exec chown apache:apache {} +”. Any thoughts on this?

    Thanks for the article!

    • 33

      Also, I just realized that adding the user account to the web server group (apache) does nothing in this case. Because the permissions are 775,664, and 660. The owner (user) and group are the same (77,66, and 66), so adding the user to the web server group is redundant. Something doesn’t seem to add up here…

      • 34

        I think you need to add Apache to your user’s group, not the user to Apache group.

        That way, you can use your user account to access / create files, and when you leave the permissions as 664/775, Apache would be able to read and edit them as well.

      • 35

        I also don’t understand this same-group-thing. Makes no sense.
        And does not work. I still can’t upload plugins.

        If I add the apache to my user group, the apache runs with all the user privileges? Sounds risky.

  22. 36

    For someone not super familiar with how servers work, this article was nice and easy to understand. Appreciated, especially after having to read the Codex article more than a good few times for that to sink in :)

  23. 37

    Great article! There are so many posts out there about this topic, this is the best I’ve found. Simple, to-the-point. Thank you for sharing!

  24. 38

    Thanks a ton. I followed your standard configuration steps and works good. I created user ‘wp-user’ and added to the apache user group ‘www’. Directories are set to 775 and files to 664. Now, I could update from theme editor.

    I downloaded and tried to edit through filezilla with wp-user credentials. But it responds with 550 permission error on update. I run vsftpd. Any pointers ?

  25. 39

    Hi, Thanks. I had to set write enable (write_enable=YES) in vsftpd.conf. Now able to upload.

  26. 40

    Thank you so so much for covering the two different setups – between 664/775 vs 644/755.

    Been on shared hosting all the while and with my recent move to a VPS, I was concerned about how the permission issues, since I didn’t want to use suPHP.

    Appreciate it!

  27. 41

    TY for this great article, it gives a clear overall insight without a lot of tchnical details.


  28. 42

    you know, instead of invoking php to see what groups are available, one can use “id www-data” or httpd, whatever user your webserver is using. the command shows groups

  29. 43

    This function will not work directly.To making this workable we need to include a file.

    if ( ! function_exists( ‘wp_handle_upload’ ) ) require_once( ABSPATH . ‘wp-admin/includes/file.php’ );

    $uploadedfile = $_FILES[‘myfile’];

    $upload_overrides = array( ‘test_form’ => false );

    $movefile = wp_handle_upload( $uploadedfile, $upload_overrides );

    if ( $movefile ) {

    //file is uploaded successfully. do next steps here.

    The file is now uploaded to uploads folder. But it won’t appear in Media
    Library as the details are not present in wp-posts table. This
    information is added using wp_insert_attachment() function.

    if ( $movefile ) {

    $wp_filetype = $movefile[‘type’];

    $filename = $movefile[‘file’];

    $wp_upload_dir = wp_upload_dir();

    $attachment = array(

    ‘guid’ => $wp_upload_dir[‘url’] . ‘/’ . basename( $filename ),

    ‘post_mime_type’ => $wp_filetype,

    ‘post_title’ => preg_replace(‘/.[^.]+$/’, ”, basename($filename)),

    ‘post_content’ => ”,

    ‘post_status’ => ‘inherit’


    $attach_id = wp_insert_attachment( $attachment, $filename);


    Here they are setting up few mandatory fields which has to be supplied
    to to wp_insert_attachment(). The function returns the post id which can
    later again be used to update any post meta information information.If
    above script does not work try below code that will definitely work.

    if you need any help visit here. PHP SCRIPTS

  30. 44

    Raul Escamila

    April 25, 2015 2:39 am

    How to set right file permission to wordpress files and folders in poweshell console of microsoft azure?

  31. 45

    Henry Wright

    May 1, 2015 12:27 am

    I’ve not seen a clearer explanation of permissions on the web. Thanks for sharing these tips; they’ve been very useful.


↑ Back to top