WordPress File Permissions and Ownership, Explained Simply

If you have ever searched for a WordPress upload error or a “failed to write file” message, you have probably landed on a forum post telling you to run chmod 777 on everything. It often “fixes” the symptom. It also opens your site to anyone who can reach the server, because 777 means any user, on any process, can read, write, and execute that file. This guide explains what permissions and ownership actually control, what the correct numbers are for each part of WordPress, and how to reset a tangled permission tree with a couple of commands.

Permissions vs. ownership: two different questions

Every file and directory on a Linux server answers two separate questions:

• Ownership: which user and group control the file. Shown as user:group, for example www-data:www-data.
• Permissions: what the owner, the group, and everyone else are allowed to do with it (read, write, execute).

Permissions are usually written as a three-digit number like 755 or 644. Each digit is a sum: read = 4, write = 2, execute = 1. So 7 means read+write+execute, 6 means read+write, 5 means read+execute, and 4 means read-only. The three digits apply, in order, to the owner, the group, and everyone else.

777 means owner, group, and everyone else can read, write, and execute. On a shared or multi-tenant server, or on any box facing the public internet, that is a standing invitation for a compromised script, a bad plugin, or another account on the same machine to modify your files.

The correct numbers for a WordPress install

WordPress core has published recommendations that have held up well over the years. The rule of thumb:

• Directories: 755. Owner can read, write, and execute (enter the directory and list/create files); group and everyone else can read and execute (enter and list, but not write).
• Files: 644. Owner can read and write; group and everyone else can only read.
• wp-config.php: 640 or even 600. This file holds your database credentials and secret keys. There is no reason for anyone outside the owner (and possibly the group, if your setup needs it) to read it at all.

Some specific spots worth calling out:

• wp-content/uploads: needs to stay writable by the PHP process (usually the web server user) so WordPress can save media, generate thumbnails, and let plugins write cached files. 755 on directories and 644 on files is normally enough, because the write permission that matters is the owner’s, not the world’s.
• wp-content/themes and wp-content/plugins: same 755/644 pattern. PHP needs to read these files to execute them, and it needs write access only when you are updating plugins/themes through the WordPress dashboard, which it does as the same user that owns the files (on a well configured host).
• .htaccess: typically 644. It needs to be readable by the web server but does not need to be executable.

Why 777 keeps showing up in bad advice

777 usually gets suggested when someone hits a permissions error, an upload that silently fails, or an update that can’t write to disk, and doesn’t know which of the two axes, ownership or permission, is actually broken. Cranking permissions to 777 often does make the error go away, because now literally anyone can write to the directory, including the correct owner. But it fixes the wrong problem. In the overwhelming majority of cases, the real issue is that the files are not owned by the user the web server runs as, so PHP can’t write to them no matter how generous the permission bits are set. The fix is to correct ownership, not to throw permissions wide open.

A second reason 777 persists: some shared hosting setups run PHP as a different user than the one that owns the files by default (a legacy CGI-wrapper style setup), and loosening permissions is a workaround for a badly configured environment rather than a WordPress requirement. On modern managed stacks, PHP runs as the same user that owns the site’s files, so this workaround should not be necessary at all.

Finding out who should own your files

Run this to see the user your PHP process (and therefore your web server) is running as:

ps aux | grep php

Or check your server’s pool configuration (for example, a PHP-FPM pool file) for the user and group directives. Whatever that user is, that is who should own your WordPress files.

Fixing a mangled permission tree

If permissions have been set inconsistently, perhaps by a bad migration, a careless plugin, or an old 777 fix that never got reverted, you can reset the whole tree from the command line. Run these from your WordPress root directory, replacing youruser:yourgroup with the actual owner and group your server uses:

chown -R youruser:yourgroup .

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

chmod 640 wp-config.php

Walking through what each line does:

• chown -R recursively sets ownership on every file and directory to the correct user and group.
• The first find sets every directory to 755.
• The second find sets every regular file to 644.
• The final line tightens wp-config.php specifically, since it deserves stricter treatment than the rest of the tree.

If you manage WordPress with wp-cli, you can sanity check core file integrity afterward with:

wp core verify-checksums

This confirms that WordPress core files match what’s expected, which is a useful step after any bulk ownership or permission change, since a typo in a find command can otherwise go unnoticed for a while.

A note on multisite and caching plugins

If you run WordPress Multisite, or a caching plugin like LiteSpeed Cache that writes its own cache files to disk, the same 755/644 pattern still applies. The plugin’s cache directories need to be writable by the owning user, not by the world. If a caching or optimization plugin ever instructs you to chmod 777 a directory as a troubleshooting step, treat that as a strong signal to check ownership first; loosening permissions should be a last resort, not a first move.

Takeaway

Permissions and ownership solve two different problems: what a file is allowed to do, and who is allowed to do it. WordPress needs directories at 755, files at 644, and a locked-down 640 (or 600) on wp-config.php, all owned by the same user your web server runs as. If you find yourself reaching for 777, stop and check ownership instead; the one-line chown -R and two find commands above will fix nearly every permission headache without leaving your site writable by anyone who happens to be passing through.