WordPress File Permissions Best Practices: 755/644 and File Ownership

This article is a localized edition of the Japanese original. Read the Japanese original

The starting point for WordPress permissions is: directories 755, files 644, wp-config.php 640 or 600, and never 777. However, even if the numbers are right, problems like "cannot update" and "cannot write" occur when the file owner and the user PHP runs as do not fit together. This article explains, in order, what the numbers mean, how to choose owners for each server setup, commands to fix everything at once, and reinforcing things with constants in wp-config.php.

What the permission numbers mean

The three digits in 755 or 644 are, from the left, the permissions for the "owner," the "group" and "others." Each digit is the sum of read (4), write (2) and execute (1).

• 644: the owner can read and write; the group and others can only read
• 755: the owner can read, write and execute; the group and others can read and execute
• 640: the owner can read and write; the group can read; others have no permissions
• 600: only the owner can read and write; nobody else can access it at all

"Execute" on a directory means "can enter it and access the files inside." If you remove the execute permission from a directory, the files inside cannot be read even if they are 644. Conversely, PHP files do not need the execute permission, because PHP "reads" and interprets the file.

Recommended values and the reasons

Following the approach shown in the official WordPress documentation (the file permissions section of the Advanced Administration Handbook), these are the guidelines.

Whether you can set wp-config.php to 600 depends on which user PHP runs as. If PHP runs as the same user as the file's owner, 600 is fine. If the owner is a different user and the PHP user reads the file through the group, use 640. If, after the change, the site shows "Error establishing a database connection" or a blank white screen, PHP cannot read the file, so go back to 640 and check the owner and group.

777 means "anyone can write." On shared servers, processes of other users on the same server may be able to modify the files, which becomes an entry point for planting malicious files. "I set it to 777 because it could not write" only covers up with permissions a problem caused by ownership settings, so fix the owner side using the method in the next section.

What really matters is the “owner” and the “user PHP runs as”

Whether WordPress can write files when updating plugins or uploading images depends less on the permission numbers than on "which user PHP runs as, and whether that user is the file's owner." There are three main setups.

1. Shared rental server (suEXEC or per-user PHP-FPM pools): PHP runs as the contractor's username. Files uploaded over FTP get the same owner, so updates and uploads normally work with 755/644 as they are. Server companies often publish recommended values, so follow those first.
2. VPS with a PHP-FPM pool running as a site-specific user: for example, create a site user wpuser and set the user and group of the PHP-FPM pool to wpuser. If you also match the file owner to wpuser, WordPress itself can write with 755/644 as they are.
3. VPS where PHP runs as www-data (Debian/Ubuntu family) or apache/nginx (RHEL family): a commonly used method is to make a working user the file owner and the web server user the group. In this case, give the group write permission only to the places you want WordPress to write to (such as wp-content/uploads).

You can check the user PHP runs as with a small PHP file like the one below. Delete it right away once you have checked.

<?php
// whoami.php (delete immediately after checking)
echo function_exists( 'posix_geteuid' )
	? posix_getpwuid( posix_geteuid() )['name']
	: get_current_user(); // Note: in environments where it cannot be obtained, the owner name is returned

In the admin screen, the "Info" tab under "Tools" → "Site Health" (Tools > Site Health) also has an item that lists whether the filesystem is writable (the item name may differ by version). It is a handy starting point for finding out which directories cannot be written to.

Commands to check the current state

Move to the WordPress root directory over SSH and check the current state. The format specifiers of stat are those of GNU coreutils (common Linux).

# Show permissions and owners of the main files
stat -c '%a %U:%G %n' wp-config.php .htaccess wp-content wp-content/uploads

# Find directories and files that are 777
find . -perm -o+w -not -type l -print

# Find files whose owner is not what you expect (replace wpuser with your own environment's)
find . -not -user wpuser -print | head -50

If the second command finds anything, first find out why. It may be a directory created by a caching or backup plugin itself, or it may be a trace of someone setting 777 by hand in the past.

Steps to reset everything to the recommended values

Before the bulk change, take a backup of the files and the database. If you have a staging site, try it there first, check the four points of display, login, plugin updates and image uploads, and then apply it to production.

cd /var/www/example.com/public_html   # WordPress root (replace with your own environment's)

# Match the owner (example for setup 2; requires root privileges)
sudo chown -R wpuser:wpuser .

# 755 for directories, 644 for files
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# 640 for wp-config.php (600 is also fine if PHP runs as the same user as the owner)
chmod 640 wp-config.php

For setup 3 (the owner is a working user and the group is the web server), give the group write permission only to the places that need it.

sudo chown -R deploy:www-data .
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# Make only the upload destination writable by PHP (the www-data group)
find wp-content/uploads -type d -exec chmod 775 {} +
find wp-content/uploads -type f -exec chmod 664 {} +
chmod 640 wp-config.php

With this setup, updating plugins or core from the WordPress admin screen fails because they cannot be written, so updates are done by running WP-CLI as the deploy user. It adds work, but it has the advantage that even if PHP is hijacked, it is harder to modify core and plugin files.

If you cannot use SSH on a rental server, you can set the same values with the attribute-change feature of your FTP client. However, you cannot change the owner, so for problems caused by the owner, consult the server company's support.

Reinforce with constants in wp-config.php

wp-config.php has constants related to file operations. Write the constants above the line /* That's all, stop editing! */.

<?php
// Disable the theme and plugin file editors in the admin screen
define( 'DISALLOW_FILE_EDIT', true );

// Also stop installing and updating plugins and themes, and core updates, from the admin screen
// (only if you update with WP-CLI or deployments)
// define( 'DISALLOW_FILE_MODS', true );

// Permissions for files and directories that WordPress newly creates
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

DISALLOW_FILE_EDIT closes the route by which PHP code could be rewritten from the admin screen if an administrator account is hijacked, and on most sites there is no downside to enabling it. DISALLOW_FILE_MODS is a stronger restriction that also prevents updates from the admin screen. Automatic updates stop as well, so use it only if you have a system to handle updates by other means.

If you set FS_METHOD to 'direct', WordPress tries to write directly during updates without showing the screen that asks for FTP information. However, if you set only this without solving the ownership problem, you easily end up with writes failing or a state that only works if you make files 777, so decide after matching the owners first.

Common stumbling blocks and fixes

• "To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed." appears: this is a sign that WordPress has decided it cannot write directly. Check whether the user PHP runs as matches the file owner.
• "Unable to create directory" appears when uploading an image: check the owner and permissions of wp-content/uploads and its year and month directory. Also check whether the upload destination setting under "Settings" → "Media" (Settings > Media) still points to an old path.
• You get a 403 error: the execute permission of a directory may have been removed, or the web server may not be able to read .htaccess.
• You get a 500 error: on suEXEC-type shared servers, some servers are configured to refuse to run PHP files or directories that have group or other write permission, for safety. Setting 775 or 777 back to 755 may resolve it.
• A caching or backup plugin shows an error after the change: the plugin may no longer be able to write to its own directory. Match the owner of just that directory to the user PHP runs as.

Permissions are only one part of security and cannot prevent tampering on their own. Think of them together with updating core, themes and plugins, strong passwords and two-step authentication for administrator accounts, and regular backups. Server companies' recommended values and admin screen labels can change (as of October 2026), so check your server's guidance before you start.

Summary

• The basics are directories 755, files 644, and wp-config.php 640 or 600. Never use 777.
• Most "cannot write" problems are ownership problems, not number problems. Check the user PHP runs as and match the owners.
• Do bulk changes with find and chmod, take a backup before the work, and if possible try it on staging first.
• Widen permissions only where writing is needed, and keep everything else close to read-only.
• Disable the admin screen file editors with DISALLOW_FILE_EDIT, and consider FS_METHOD only after matching the owners.

• How to fix permission errors in the WordPress uploads directory
• How to control default file permissions with the Linux umask setting

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)