You click “Update” on a plugin and WordPress stops with “Could not create directory.” Or, instead of updating, it shows a form asking for an FTP hostname, username and password. Or a developer tells you a folder has been set to 777 “to make it work,” and you are not sure whether that is fine.
All three are file permission problems. Permissions decide who can read, change and run each file on your server. Too strict, and WordPress cannot do its own work. Too loose, and anything that gets onto the server can change your files. Here is how they work, what values are commonly used, and how to check yours.
Owner, group and others
Every file and folder on a Linux web server, which is what nearly all WordPress hosting runs on, belongs to one user account, the owner, and to one group. Everyone else is others.
Permissions are set separately for each of those three. A file can say: the owner may change me, the group may only read me, and everyone else may not touch me.
The user that matters most is the one that runs PHP, because that is the account WordPress acts as. When WordPress installs a plugin or saves an uploaded image, it is that PHP user doing the writing. Whether it is allowed depends on who owns the files and what the permissions say.
Read, write and execute
Each of the three gets some combination of three rights:
- Read: see the contents of a file, or list what is inside a folder.
- Write: change or delete a file, or create and remove files inside a folder.
- Execute: for a file, run it as a program. For a folder, it means being allowed to enter it and reach the files inside. A folder without execute is effectively closed.
These are usually written as numbers. Read is 4, write is 2 and execute is 1, and you add them up. So 7 is all three, 6 is read and write, 5 is read and execute, and 4 is read only.
A permission like 755 is three of those digits in a row: owner, then group, then others. You will also see it written as letters, such as rwxr-xr-x, which is 755 spelled out.
The values commonly recommended for WordPress
The usual starting point, and what WordPress’s own documentation and many hosts suggest, looks like this:
| What | Common value | What it means |
|---|---|---|
| Folders | 755 | Owner can do everything; group and others can enter and read |
| Files | 644 | Owner can read and change; group and others can only read |
| wp-config.php | Tighter, such as 640 or 600 | Readable by the owner (and sometimes the group), not by others |
Treat this as common guidance, not a rule for every server. The right value depends on how your host runs PHP. On many hosts, PHP runs as the same user that owns your files, and 755 and 644 work cleanly. On other setups, PHP runs as a separate user and relies on group access. There, setting wp-config.php to 600 can stop the site loading at all, because PHP can no longer read it. If your host publishes recommended permissions, follow theirs.
wp-config.php gets extra attention because it holds your database password. Protecting it properly involves more than permissions, which we cover in how to protect wp-config.php.
Why 777 is dangerous
777 means everyone can read, write and execute. It often gets set as a quick fix, because when an update fails, opening a folder to everyone makes the error go away.
The problem is what else it allows. Any other account or process on the server can now write into that folder. If an attacker gets a foothold through a weak plugin, a 777 folder is a ready place to drop a malicious file and have it run. Backdoor files in folders that should never have been writable are a familiar sight when cleaning up hacked sites. If you have already found strange files, see how to fix a hacked WordPress website.
If something only works at 777, the real problem is almost always ownership, not permissions. Fix the ownership and the normal values will work.
File ownership matters as much as the numbers
Permissions describe what the owner, group and others may do. Ownership decides who the owner actually is. You can have perfect 755 and 644 values and still have a broken site if the files belong to the wrong user.
This usually happens after a migration, a restore from backup, or a developer uploading files over SSH as a different account. The files end up owned by, say, the root user or the developer’s login, while PHP runs as the site’s user. WordPress then cannot write to its own folders, so updates fail.
WordPress checks this itself. Before an update, it tests whether it can write files directly. If it cannot, it falls back to asking for FTP details so it can do the work over an FTP connection instead. That is why the credentials screen appears: it is a symptom of ownership or permissions, not something you are meant to fill in.
Signs your permissions are wrong
- Plugin, theme or core updates fail with “Could not create directory,” “Could not remove the old plugin,” or a plain “Update failed.”
- WordPress asks for FTP or SFTP credentials when you install or update anything.
- Image uploads fail with a message that the file could not be moved, or that the uploads folder is not writable.
- A blank page or a 403 Forbidden error right after someone changed permissions, often because PHP can no longer read a file or folder.
If updates have been failing for a while, the site may also be running old plugin versions with known holes. Our guide to core, plugin and theme updates explains why skipping them builds up risk.
How to check and change permissions
Take a backup first. A bulk change on the wrong folder can take the site offline.
Through your hosting file manager
Most control panels, such as cPanel or Plesk, have a File Manager. Open your site’s folder and you will usually see a permissions column with values like 0755 or 0644. Select a file or folder and look for “Permissions” or “Change Permissions” to edit it.
Through FTP or SFTP
An FTP client such as FileZilla shows permissions for each file. Right-click and choose “File permissions” to change them. Some clients can apply a value to everything inside a folder, with an option for files only or folders only. That option matters: 755 on every file, or 644 on every folder, causes its own problems. Use SFTP rather than plain FTP where your host offers it, since plain FTP sends your password unencrypted.
Through SSH
With SSH access, the command ls -l shows permissions and owners for everything in a folder. From inside your WordPress folder, find . -type d -exec chmod 755 {} \; sets folders to 755, and find . -type f -exec chmod 644 {} \; sets files to 644.
Run them only from the correct folder, and only once you know your host’s setup suits these values. Ownership is changed with chown, but on shared hosting you usually cannot do that yourself. If files belong to the wrong user, ask your host to reset ownership for your account.
A sensible order to work in
- Back up the site.
- Find out which user PHP runs as and who owns the files. Your host can tell you.
- Fix ownership first if it is wrong.
- Set folders to 755 and files to 644, unless your host recommends otherwise.
- Tighten wp-config.php to what your host supports, then load the site to confirm it still works.
- Bring anything left at 777 back to normal values.
- Run a plugin update to confirm WordPress no longer asks for FTP details.
Permissions are one part of a wider set of habits. Our website security best practices cover the rest, from passwords to backups.
If you would rather not experiment on a live site, our website security audit and hardening starts from ₹1,999 onwards and looks at settings like these along with the rest of your site’s weak points. You get a clear list of what we found before anything is changed.
Next in this series: WordPress XML-RPC: What It Is and Whether to Disable It
