WordPress file permissions: what the numbers mean and what to set

WordPress's own guidance is short: folders at 755, files at 644, and wp-config.php at 440 or 400. Every file belongs to your own hosting account, and nothing is ever 777.

The numbers are half of it. The other half is who owns the files and which user on the server PHP runs as. That decides whether WordPress can save an upload or update a plugin, and it is where to look when 755 and 644 are in place and something still fails.

How to read a permission

A permission is three digits. The first is for the file's owner, the second for the file's group, the third for everyone else. Each digit is a sum: 4 to read, 2 to write, 1 to execute.

So 755 lets the owner do everything, and lets the group and everyone else read and open but not change. 644 lets the owner read and write, and everyone else only read.

The same thing is often shown as letters: rwxr-xr-x is 755 and rw-r--r-- is 644, and a d in front marks a folder. In a four-digit mode such as 0755, the leading zero changes nothing.

Why a folder needs execute

On a file, execute means the file can be run as a program. On a folder the three permissions mean something else:

• Read lets you list what is in the folder.
• Write lets you create and remove files in it.
• Execute lets you reach the files in it.

A folder at 644 can be listed, but nothing inside it can be opened. That is why folders get 755 and files get 644, and why one number for both is wrong for one of them.

Ownership is the other half

The digits are read against a file's owner and group, so the same 755 means different things to WordPress depending on which user PHP runs as. WordPress's documentation describes two setups.

• PHP runs as your own account. The documentation calls this the suexec approach and says many shared hosts use it. WordPress acts as the owner, so the first digit applies to it. It can write to a 755 folder, and uploads and updates work with nothing looser.
• PHP runs as a separate user. The web server has a user of its own, often www-data or nobody. Apache sets it with its User directive, and PHP-FPM with the user setting of each pool. WordPress then counts as "group" or "everyone else". At 755 and 644 it can read everything and change nothing.

In both, the documentation says the same about shared hosting: the files belong to your account, never to the web server's own user.

Why WordPress asks for FTP details

Before it installs or updates anything, WordPress writes a small temporary file to the site and compares that file's owner with the owner of WordPress's own files. If they match, it writes directly. If they differ, or it could not write the file at all, it falls back to FTP or SSH and shows a form headed "Connection Information", which begins "To perform the requested action, WordPress needs to access your web server."

The form is not a fault. It says that PHP is not the owner of the files. The comparison is about owners, not modes, so 777 does not make it go away. What to do depends on the hosting:

• On shared or managed hosting, ask the host whether the site's files all belong to your account and whether PHP runs as it. Changing who owns a file is a job for the host.
• On a server you administer, correct the ownership as the administrator with chown -R, giving the owner and group your setup expects.

Do not set FS_METHOD to direct in wp-config.php to silence the form. WordPress's documentation says the direct method is chosen automatically when it is appropriate, and that forcing it opens security issues on poorly configured hosts.

The modes WordPress recommends

The tighter value in each pair takes away everyone else's access. It works only where the web server reaches the files as their owner or through their group: Apache has to read every file it serves and enter every folder on the way to it. If pages, images or stylesheets return 403 after you tighten, go back to 755 and 644.

The documentation allows one looser case. Where WordPress runs as a different user that shares a group with the owner, what WordPress has to write can be group-writable: 775 for folders, 664 for files. That is for a server whose users you know. On shared hosting, it says the web server's user should neither own the files nor be in that group.

How to see the current modes

• In the dashboard. Go to Tools, then Site Health, then the Info tab, and open "Filesystem Permissions". It lists the main WordPress directory and the wp-content, uploads, plugins and themes directories, each as "Writable" or "Not writable". It shows whether WordPress can write, not whether the modes are safe: a site at 777 is writable everywhere.
• In an SFTP program or the host's file manager. The file list has a permissions column. WordPress's documentation shows it in FileZilla: right-click a file, select "File Permissions", and the number is under "Numeric value". Files whose names begin with a dot, such as .htaccess, stay hidden until you turn on the option to show hidden files.
• Over SSH. Run these from the site's main folder.

ls -la lists every entry, dot files included, with its mode as letters, then its owner and group. stat in this form, which is the GNU one found on Linux servers, prints the mode as digits, then the owner, the group and the name.

To learn which setup you are on, upload an image in the dashboard and compare the owner of the new file under wp-content/uploads with the owner of index.php. If they are the same, PHP runs as the files' owner.

Correct them in bulk over SSH

Without a shell

An SFTP program or the host's file manager can apply a mode to folders only or to files only. The permissions fix in how to fix the 403 Forbidden error has those steps.

On managed hosting where you have neither, ask the host to reset the site's permissions and ownership. Some control panels have a tool for it. If yours has none, ask support for folders at 755, files at 644, and every file owned by the account.

Files and folders that need their own setting

wp-config.php

This file holds the database name, user and password. WordPress creates it at 644, and its documentation calls leaving it that way a hazard: on a shared server, 644 lets everyone else read it. The guidance is that only you and the web server can read it, which generally means 440 or 400.

400 lets the owner alone read it, which is enough where PHP runs as your account. 440 adds the group. At either value nobody can write to the file: to edit it, set it to 600, make the change, and set it back.

.htaccess

WordPress's documentation says 644 is normally required and recommended for this file. The web server has to read it, and a mode that shuts the server out causes an error.

WordPress writes to .htaccess when you save your permalink settings. If it cannot, the Permalinks screen says "You should update your .htaccess file now." and shows the rules for you to paste into the file by hand. Pasting them is a complete answer. The file never needs to be writable by everyone.

The uploads folder

wp-content/uploads is the folder WordPress writes to day to day. When it cannot create a folder there, the upload fails with a message that starts "Unable to create directory", names the path, and asks "Is its parent directory writable by the server?"

Where PHP runs as your account, the folder needs to be 755 and owned by that account. Where PHP runs as a separate user, the folder has to be writable by that user through its group, which is the 775 case above. On shared hosting set up that way, ask the host before you loosen anything. WordPress's documentation is plain about the limit: no folder is ever given 777, "even upload directories."

The modes WordPress gives the files it writes

When WordPress runs an update, it sets the modes itself: 755 for folders and 644 for files. Two constants in wp-config.php change that. WordPress's documentation says they exist for hosts that refuse to access files the group or everyone else can use.

The values are octal: they start with a 0 and are not put in quotes. They apply to what WordPress writes from then on, not to files already in place.

What wrong permissions look like

• A 403 on every page, or on images and stylesheets. The web server cannot read a file or enter a folder. How to fix the 403 Forbidden error covers this cause and the others.
• A 500 error. Apache's suEXEC will not run a program that anyone but its owner can write to, or one in a folder like that. On a host that runs PHP through it, 777 causes an error and cures none. How to fix the 500 internal server error shows how to find the line in the server's log.
• Uploads fail with "Unable to create directory". See the uploads folder above.
• Updates fail. WordPress says "Could not create directory." or "The update cannot be installed because some files could not be copied. This is usually due to inconsistent file permissions." Check ownership first. If the site is left broken, use the failed WordPress update runbook.
• WordPress asks for FTP details. PHP is not the owner of the files.

Why 777 and 666 are never the answer

777 lets the owner, the group and everyone else read, write and execute. 666 does the same for reading and writing. "Everyone else" is not the public on the web. It is every other account and every process on the same server, which on shared hosting includes other customers' accounts.

WordPress's documentation spells out the danger. Making your files writable by everyone gives the web server's own user, and anything that can hijack a process on the server, full access to them. The worst case it describes is someone uploading a file or changing one of yours to run their own code, which gives them control of the site, the database password included. And because write permission on a folder covers creating and removing files in it, a folder at 777 is open even when the files inside are 644.

It is also not needed. Where PHP runs as your account, WordPress can write to a 755 folder. Where it does not, the cure is ownership or a shared group.

The same page, where it covers the command line, still mentions 777 as a last and temporary resort. Its stricter advice is the one to follow.

When to get help

• Ask the host when chmod refuses a file or files belong to the wrong user.
• If folders were at 777 and you find PHP files you do not recognize, see how to remove malware from a hacked WordPress site.
• Hand it over if the modes and the ownership are right and the fault remains. A one-time fix from WP Ministry covers one issue on one site and starts with a free diagnosis, which gives you a written cause and a fixed quote.

Permissions are one layer. WordPress security: what to do, in order of what matters most puts them beside updates, backups and the rest.