---
title: "How to Reset WordPress File and Directory Permissions"
description: "Fix failing WordPress uploads and updates by resetting directories to 755 and files to 644 over SSH, SFTP or File Manager, then lock down wp-config.php."
url: "https://docs.noiz.ie/wordpress/how-to-reset-wordpress-file-and-directory-permissions/"
section: "WordPress"
categories:
  - "Applications > WordPress > WordPress Troubleshooting"
last_reviewed: "27 July 2026, against the current WordPress release"
---

# 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 the current WordPress release. 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)](https://developer.wordpress.org/advanced-administration/server/file-permissions/): the reference values, the reasoning behind them, and the strong warning against ever using 777.
- [Hardening WordPress (WordPress Developer Resources)](https://developer.wordpress.org/advanced-administration/security/hardening/): 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.

![A terminal session showing the two find commands resetting WordPress directories to 755 and files to 644](/images/kb/327_ssh-find-chmod-reset-permissions.png)

## 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.

<!-- IMG: sftp-client-recursive-permissions-dialogue | alt: An SFTP client permissions dialogue set to numeric value 755 with recurse into subdirectories and apply to directories only selected -->

## 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, and the goal is the same as with the SFTP method: directories at `755` and files at `644`. Not every panel can separate files from directories in a recursive change, though, so check what yours does before you rely on it.

- On **Plesk** (Noiz South African hosting), **Files** > **Change Permissions** with **Change permissions recursively** ticked applies the same value to every file and subdirectory inside the folder, as described in the [Plesk File Manager permissions documentation](https://docs.plesk.com/en-US/obsidian/administrator-guide/website-management/websites-and-domains/website-content/changing-file-and-directory-access-permissions-in-file-manager.70738/). It cannot set directories to `755` and files to `644` in one recursive pass, so for a full WordPress reset use SSH (Method A) or SFTP (Method B), and keep the Plesk File Manager for single files and folders.
- On **DirectAdmin** (Noiz Ireland hosting), open the **File Manager**, select your items, and use **Set Permission** to change their mode. For a full WordPress reset, where every folder needs `755` and every file `644`, use SSH (Method A) or SFTP (Method B), and keep the DirectAdmin File Manager for single files and folders.
- 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: directories at `755`, files at `644`, and never a single blanket recursive pass that sets both to the same value.

![The Plesk File Manager Change Permissions dialogue with the Change permissions recursively option for a WordPress folder](/images/kb/109_plesk-file-manager-change-permissions.png)

## 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](/wordpress/how-to-log-in-to-the-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](/wordpress/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.

---
Source: https://docs.noiz.ie/wordpress/how-to-reset-wordpress-file-and-directory-permissions/