How to Reset WordPress File and Directory Permissions

This guide shows you how to reset the file and directory permissions of a WordPress site back to safe, working values when uploads, updates or plugin installs have started failing, or when a security scan has flagged files as too open. File permissions (sometimes called the file mode, or set with the chmod command, so you may see them written as "CHMOD 644") decide who is allowed to read, change or run each file and folder on the server. Get them wrong in one direction and WordPress cannot write to its own folders; get them wrong in the other and you hand an attacker an easy way in. This article explains what the correct values are, why the wrong ones break things, and how to put them right using an SFTP client, your hosting panel's File Manager, or a couple of find and chmod commands over SSH. It is written for Noiz clients who run WordPress, and the same values apply whether your site is on Plesk, DirectAdmin or ISPConfig.

Last reviewed: 27 July 2026, against WordPress 7.0.2 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress documentation linked below.

Official Documentation Reference

• Changing File Permissions (WordPress Developer Resources): the reference values, the reasoning behind them, and the strong warning against ever using 777.
• Hardening WordPress (WordPress Developer Resources): how ownership and permissions fit into securing a site, including the recommended lockdown for wp-config.php.

Prerequisites

• A way to reach your site's files: an SFTP client, your hosting panel's File Manager, or SSH access. Each method is covered below, so you only need one.
• The path to your WordPress installation, that is, the folder that holds wp-config.php, wp-admin, wp-content and wp-includes. On Noiz hosting this is your domain's document root, for example httpdocs on Plesk or public_html on DirectAdmin.
• A recent backup, or the confidence that you can take one. Resetting permissions is reversible and low-risk, but it is good practice to have a restore point before any bulk change.

If you are on a managed plan and would rather not do this yourself, skip to the end: the Noiz support team can reset permissions and ownership for you.

What File Permissions Actually Mean

Every file and folder on a Linux server carries a three-digit number such as 644 or 755. It looks cryptic, but it decodes very simply, and understanding it makes the rest of this guide obvious rather than something to memorise.

The three digits describe three groups of people, in this order:

• The owner of the file (your hosting account).
• The group the file belongs to (often the web server).
• Everyone else on the server.

Each digit is the sum of three possible permissions: read is worth 4, write is worth 2, and execute is worth 1. So a digit of 6 means read plus write (4+2), a digit of 5 means read plus execute (4+1), and a digit of 4 means read only. Reading 644 from left to right, then, means: the owner can read and write, while the group and everyone else can only read.

The one part that trips people up is execute on a folder. For a directory, the execute bit does not mean "run a program"; it means "you are allowed to enter this folder and list what is inside". That is why directories need a 5 (read plus execute) where files only need a 4 (read). A folder set to 644 cannot be entered by anyone, which quietly breaks everything below it. Keep that single fact in mind and the common mistakes below will make sense.

The Correct Permissions for WordPress

These are the values WordPress itself recommends and the values its automatic updater applies to your files. Setting everything to match is exactly what "resetting permissions" means.

• Directories: 755. The owner can read, write and enter the folder; everyone else can read and enter but not change it. Every folder in the install, including wp-content and wp-content/uploads, uses this value.
• Files: 644. The owner can read and change the file; everyone else can only read it. This covers almost every file in the install, including your theme files, plugin files and .htaccess.
• wp-config.php: 640 or 600. This one file holds your database name, username and password, so it deserves tighter treatment than an ordinary 644 file. Lock it down separately after the bulk reset, as described later.
• Never 777, on anything. A 777 file or folder is writable by every account on the server. WordPress is blunt about this: no directory should ever be 777, not even the uploads folder. It is one of the most common ways a shared-hosting site is compromised.

A useful sanity check: on a healthy WordPress install, if you look at the mode of any folder you should see 755, and any file should see 644. The only routine exception is wp-config.php. If you see 777, 666 or a mix of odd values, something has drifted and this reset will fix it.

A note on ownership, which is not the same thing

Permissions decide what each category of user may do; ownership decides who the "owner" actually is. On Noiz hosting your files should be owned by your own hosting account, and because the PHP process runs as that same account, the standard 755/644 values give WordPress everything it needs to write to its own folders. Problems appear when files end up owned by the wrong user, which can happen after a clumsy manual upload, an archive extracted as the web server, or a migration from another host. When ownership is wrong, no amount of chmod will fix upload or update failures, because the numbers are being applied to the wrong owner. Correcting ownership needs root-level access, so if you suspect this, that is a job for the Noiz support team rather than something you can set in a File Manager.

Why the Wrong Permissions Break Things

Permissions fail in two opposite directions, and the symptoms are different, so it helps to recognise both.

Too restrictive: WordPress cannot write to itself

WordPress needs to write into its own folders to do everyday work: saving an uploaded image, unpacking a plugin or theme, or installing a core update. If the folders are too locked down for the account that runs PHP to write to them, those actions fail. The tell-tale signs are:

• Media uploads fail with a message like "Unable to create directory wp-content/uploads/2026/07. Is its parent directory writable by the server?"
• Installing or updating a plugin, theme or WordPress core fails with "Installation failed: Could not create directory" or "Could not copy file".
• WordPress unexpectedly asks you for FTP or SSH connection details when you try to install or update something. That prompt is WordPress admitting it cannot write to the folder directly and looking for another way in.
• A folder accidentally set to 644 (missing the execute bit) produces a 403 Forbidden error or a blank white page for everything inside it, because the server is no longer allowed to enter that folder.

Too permissive: a security hole, and sometimes a 500 error

Loosening permissions to "make it work", usually by setting things to 777, is the wrong fix and creates two new problems. The first is security: a world-writable file or folder can be modified by any other account on the server, which is exactly the foothold attackers look for on shared hosting. The second is more surprising. Many modern hosting setups, including the way PHP runs on Noiz servers, deliberately refuse to execute a script that is writable by the group or by everyone, treating it as unsafe. So a file you set to 777 to fix an upload can instead give every visitor a 500 Internal Server Error, because the server now declines to run it. The correct values, 644 and 755, avoid both problems at once, which is the whole point of resetting rather than loosening.

Method A: Reset Permissions Over SSH (Most Precise)

If you have SSH access, this is the cleanest way to reset an entire install, because the find command can target files and directories separately and apply the right value to each in one pass. This is precisely what the two-pass warning in the GUI methods below is trying to work around by hand.

Change into your WordPress root first, then run the two resets:

cd /path/to/your/wordpress

# Set every directory to 755
find . -type d -exec chmod 755 {} \;

# Set every file to 644
find . -type f -exec chmod 644 {} \;

The -type d filter matches directories only and the -type f filter matches files only, so directories keep their essential execute bit and files never gain one. Replace /path/to/your/wordpress with your actual document root, for example the full path to your httpdocs or public_html folder. Once both commands finish, harden wp-config.php as described further down.

Method B: Reset Permissions With an SFTP Client

If you connect to your site with an SFTP client, you can reset permissions through its interface. The important thing to understand is that a graphical tool cannot tell files and folders apart the way find can, so you must do the job in two separate passes and use the client's "apply to" options carefully. Doing it in one careless pass is the single most common way people make the problem worse.

Connect to your site over SFTP and navigate to your WordPress root folder, then:

1. First pass, directories. Select the WordPress root folder, open its permissions or attributes dialogue (in most clients this is a right-click, then File permissions or Attributes), and enter the numeric value 755. Tick the option to recurse into subdirectories, and then choose the option to apply to directories only. Confirm. This sets every folder in the install to 755 without touching the files.
2. Second pass, files. Open the same dialogue again on the WordPress root folder, this time entering 644, ticking recurse into subdirectories, and choosing apply to files only. Confirm. This sets every file to 644 without touching the folders.

Why the two passes matter. If you instead recurse 644 onto everything, you strip the execute bit off every directory and the whole site goes down with 403 or blank-page errors, exactly the mistake described earlier. If you recurse 755 onto everything, your files become needlessly executable. Keeping directories and files separate is the entire trick, and the "apply to directories only" and "apply to files only" options are what make it possible in a GUI.

Method C: Reset Permissions in the Hosting Panel File Manager

Every Noiz hosting panel includes a File Manager that can change permissions without any separate software, which is handy if you do not have an SFTP client set up. The exact labels differ between panels, but the principle is identical to the SFTP method: reset directories and files in two separate recursive passes.

• On Plesk (Noiz South African hosting), open Files, select the WordPress folder, and use Change Permissions. Plesk lets you tick the group and owner permission boxes and apply the change recursively to subfolders and files, so set directories to 755 and files to 644 in turn.
• On DirectAdmin (Noiz Ireland hosting), open the File Manager, select your items, and use Set Permission with the recursive option to apply 755 to folders and 644 to files.
• On ISPConfig, the built-in file tools are more limited, and for a full recursive reset SFTP (Method B) or SSH (Method A) is usually the smoother route.

Whichever panel you use, apply the same discipline as with SFTP: one recursive pass for directories at 755, a second recursive pass for files at 644, and never a single blanket pass over both.

Lock Down wp-config.php Separately

After the bulk reset, wp-config.php will be sitting at 644 along with every other file, which means any other account on the server could read your database password. Because this file is uniquely sensitive, tighten it on its own:

chmod 640 /path/to/your/wordpress/wp-config.php

A value of 640 lets your account read and write the file and lets the web server's group read it, while everyone else is shut out. On the per-account PHP setup used across Noiz hosting, where PHP runs as your own user, you can go further to 600 (owner only) and WordPress will still read the file perfectly. The official WordPress hardening guide suggests the even tighter 440 or 400, which make the file read-only to everyone including you; those work too, with the small trade-off that you must temporarily relax the file back to 640 if you ever need to edit it. Any of 640, 600, 440 or 400 is a sound choice; 644 for this one file is not.

You can set the same value through your SFTP client or File Manager if you prefer: right-click wp-config.php, open its permissions dialogue, and enter 640 for that single file only.

Confirm the Reset Worked

Two quick checks confirm the site is healthy again:

• The site loads normally. Visit your home page and a couple of inner pages. If they load without 403 or blank-page errors, your directories have their execute bit back.
• WordPress can write again. Log in to your WordPress dashboard and upload a test image under Media > Add New. A successful upload proves wp-content/uploads is writable and that the earlier upload or update failures are resolved.

Troubleshooting

• Symptom: after a recursive change the whole site shows 403 Forbidden or a blank white page. You almost certainly applied 644 to directories as well as files, stripping the execute bit off every folder. Re-run the directory pass, setting all directories back to 755 (Method A does this cleanly with find . -type d -exec chmod 755 {} \;).
• Symptom: uploads or updates still fail after the reset, with "could not create directory" style messages. The permissions are now correct, so the likely cause is ownership: some files are owned by the wrong user and chmod cannot help. This needs root access to fix. Contact the Noiz support team, quoting the exact error and your domain.
• Symptom: a 500 Internal Server Error appeared after you set something to 777 or 666 to try to fix an upload. The server is refusing to run a file that is writable by group or others. Reset that file to 644 (or the folder to 755) and the error will clear; then solve the original write problem properly, not by loosening permissions.
• Symptom: WordPress keeps asking for FTP or SSH credentials whenever you install or update anything. WordPress cannot write to its folders directly. Run the reset above so directories are 755 and files 644; if it persists, ownership is the likely culprit and support can confirm.
• Symptom: a security scan reports wp-config.php as world-readable even after the reset. The bulk pass set it to 644; tighten it separately to 640 or 600 as shown above.

Correct file permissions are one layer of a well-secured site rather than the whole story. For the wider picture, including keeping WordPress, plugins and themes current and limiting where files can be written from, see the Noiz WordPress Security Checklist.

If you are on a managed Noiz plan, or you would simply rather not touch permissions by hand, open a support ticket and the Noiz support team will reset your file and directory permissions, correct any ownership problems, and lock down wp-config.php for you. Include your domain and, if you have one, the exact error message you are seeing, so the fix can be applied straight away.