Why Should Directories Be 755 and Files 644?

In the Linux file permission system, the execute bit carries different meanings for directories and for files. On a directory, the execute bit means the directory can be entered and its contents listed; on a file it means the owner and the group can run the file. For the web server (Apache, Nginx/PHP-FPM) to be able to read WordPress files and serve them to the browser, directories have to be enterable and files readable; without those two conditions the site does not open at all.

The 755 permission (drwxr-xr-x) gives a directory's owner read/write/enter rights, and the group and others only read and enter. The 644 permission (-rw-r--r--) gives a file's owner read/write, and the group and others only read. What both permissions have in common is that write access for others is deliberately kept closed: this way another user or process running on a shared server cannot modify or delete the files, or add malicious code to them, without permission.

This distinction matters especially in shared hosting environments, because dozens of different accounts and processes may be running on the same physical server. Write access being closed to everyone outside the file's owner and group is the fundamental layer that guarantees one account cannot write to another's files.

Why Is wp-config.php Kept Stricter?

The wp-config.php file is the most sensitive file in a WordPress installation, because the database username and password are stored in it as plain text. That is why the Codex, unlike for other files, recommends 440 or even 400 for this file rather than 644.

The 440 permission makes the file readable only by its owner and members of the group, closing read access to others entirely. The 400 permission goes one step further and makes the file readable only by its owner. This hardening reduces the risk of a leak — provided, of course, that the web server process is the file's owner or a member of the right group; otherwise WordPress cannot connect to the database and the site does not work.

This one-line command is the most concrete expression of the fact that this file has to be kept apart from the other 644 files: it must be run separately, specifically for this file, immediately after the bulk chmod command.

The 777 Danger and the "If It Doesn't Work, chmod 777" Advice

In a shared hosting environment this means another account on the same physical server — or any compromised process — can inject malicious code directly into your WordPress files. Once 777 is granted, file ownership no longer provides any protection; any user on the server can read, write and execute the file. When a file upload script or a theme file is left open this way, malicious code can be written straight over that file and can keep running for a long time without the site owner noticing.

Example: The Wrong and the Right Approach

An administrator who gets a "directory not writable" error during a plugin installation often sets that directory to 777 as the first fix and, because the error disappears, considers the problem "solved". Yet the same error may be caused by the directory's ownership not belonging to the web server user. The right approach is to keep the directory at 755 and match its ownership (owner/group) with the user the web server process runs as; that way the plugin can write and the directory stays closed to other users on the server.

The Right Fix: Correct Ownership, Not Looser Permissions

A "permission error" usually comes not from permissions being too strict but from file ownership (owner/group) not matching the web server user. The right fix is almost always not to loosen permissions to 777 but to match file ownership correctly with the user the web server process runs as (for example www-data or apache).

A typical example of this is the wp-content/uploads/ directory. This directory has to stay writable by WordPress for media uploads; but that is achieved safely with the standard 755 permission by making sure the directory's ownership (or group) belongs to the web server user, not by loosening the permission to 777. The same logic applies to other directories where plugins write cache or log files: the fix is not looser permissions but giving ownership to the right user.

  • Directories should always be 755 and files always 644.
  • For wp-config.php, 440 or 400 should be preferred.
  • No directory, including wp-content/uploads/, should be set to 777; writability should be achieved through ownership.
  • When you get a permission error, check file ownership (owner/group) first; loosening permissions should not be the fallback you reach for.

Applying these permissions to the right files in the right order is a matter of a few commands; but looking at a ready reference, rather than knowing by heart which file needs which permission, is safer — particularly for not skipping exceptions such as wp-config.php.