WordPress file permissions explained

WordPress file permissions determine which users and processes on the server are allowed to read, modify or execute the files and directories that make up your website.

When permissions are configured correctly, WordPress can perform the operations it needs while limiting unnecessary write access to sensitive files.

When they are configured incorrectly, you can encounter problems such as:

• failed plugin or theme installations;
• WordPress asking for FTP credentials;
• media uploads failing;
• automatic updates failing;
• plugins being unable to create cache or backup files;
• files becoming writable by users or processes that should never be able to change them;
• unexpected 403 or permission-denied errors.

The familiar recommendations:

Directories: 755
Files:       644

are useful starting points for many Linux-based WordPress installations, but they are not universal laws.

Correct WordPress permissions depend on the relationship between:

• the file owner;
• the file’s group;
• the account running PHP;
• the web server;
• your hosting architecture;
• the specific directory WordPress needs to modify.

The official WordPress file permissions documentation explicitly warns that the right scheme depends on how the server is configured.

This guide explains how Linux permissions work, what values such as 644 and 755 actually mean, why ownership matters, which parts of WordPress need write access, why 777 is dangerous, how WordPress chooses a filesystem method and how to diagnose permission problems without simply making the entire installation writable.

What are WordPress file permissions?

WordPress itself does not invent a separate permission system for the files on your server.

On a typical Linux hosting environment, it relies on the operating system’s filesystem permissions.

Those permissions answer questions such as:

• Can this user read the file?
• Can this process modify the file?
• Can this user enter this directory?
• Can PHP create another file inside this folder?
• Can another account on the server access it?

Three basic permissions exist

The traditional Unix permission model uses three primary permissions:

• Read, represented by r;
• Write, represented by w;
• Execute, represented by x.

They mean different things depending on whether the target is a file or a directory.

Read permission on a file

Read permission allows the contents of a file to be read.

For example, PHP needs to be able to read WordPress PHP files before it can execute the application.

Write permission on a file

Write permission allows the contents of a file to be changed.

For example, updating a plugin requires replacing or modifying files inside its plugin directory.

Execute permission on a file

Execute permission allows the operating system to execute a file directly as a program.

Ordinary WordPress PHP files generally do not need their Unix execute bit set merely because PHP executes their code through the PHP interpreter.

This is one reason normal WordPress files commonly use:

644

rather than:

755

Execute permission means something different on directories

For a directory, execute permission controls whether a user or process can traverse or enter that directory.

A directory may therefore need:

x

even though nobody is “executing” the folder as a program.

This distinction explains why directories commonly have values such as 755 while ordinary files commonly have values such as 644.

Owner, group and everyone else

Linux permissions are normally divided into three classes:

• owner;
• group;
• others.

You may see a permission string like:

rwxr-xr-x

It can be separated into:

rwx | r-x | r-x

owner | group | others

The owner

Every file has an owner.

This is usually a Unix user account.

Depending on the server architecture, WordPress files might be owned by:

• your hosting account;
• a deployment user;
• the PHP-FPM user;
• another account created by the hosting provider.

The group

Files also belong to a group.

Groups make it possible to give several accounts a shared level of access.

For example, your deployment account and the PHP process might belong to a common group that is permitted to modify wp-content.

Others

The third permission set applies to accounts that are neither the owner nor members of the relevant group.

Giving write access to this category is usually something you should avoid unless the environment has a very specific reason for it.

What do 644, 755 and 775 actually mean?

The numeric values used for Unix permissions come from an octal representation.

Each permission has a value:

read    = 4
write   = 2
execute = 1

The values are added together for each permission class.

Common combinations

7 = 4 + 2 + 1 = read + write + execute
6 = 4 + 2     = read + write
5 = 4 + 1     = read + execute
4 = 4         = read only

What 644 means

Consider:

644

This means:

6 | 4 | 4

owner  = read + write
group  = read
others = read

Symbolically:

rw-r--r--

This is a common permission for ordinary WordPress files.

What 755 means

Consider:

755

This means:

7 | 5 | 5

owner  = read + write + execute
group  = read + execute
others = read + execute

Symbolically:

rwxr-xr-x

This is a common directory permission because other processes can traverse the directory without being allowed to modify it.

What 775 means

Another common value is:

775

which means:

owner  = read + write + execute
group  = read + write + execute
others = read + execute

Group write access can be appropriate on systems where the deployment user and web-server/PHP process intentionally share a group.

The official WordPress Changing File Permissions guide notes that some installations may require 775 for directories and 664 for files rather than the more familiar 755 and 644.

Why ownership matters as much as chmod

Permissions alone do not tell you whether WordPress can modify a file.

Consider two installations where a plugin file is:

644

In installation A, the PHP process effectively operates as the owner.

In installation B, PHP is neither the owner nor a member of a group with write access.

The numeric permission is identical.

The result is not.

A 644 file is writable only by its owner

Because 644 means:

owner:  rw-
group:  r--
others: r--

only the owner receives write permission.

If PHP needs to replace that file but runs under another account, direct modification can fail.

This is why blindly changing chmod can miss the problem

If WordPress cannot update plugins, users often immediately run:

chmod -R 777 ...

That can make the symptom disappear because almost everyone now receives write access.

But the underlying problem may have been incorrect ownership.

The better question is:

Which account owns these files,
which account is PHP using,
and which one should be allowed to write?

Inspect ownership from the command line

On Linux, you can inspect files with:

ls -la

A simplified result might look like:

-rw-r--r-- 1 deploy www-data 4200 wp-config.php

This shows:

• the permissions;
• the owner;
• the group;
• the file name.

Changing permissions without inspecting ownership gives you only half the picture.

Typical WordPress file and directory permissions

The official WordPress Hardening guide provides a commonly recommended architecture for WordPress files.

A typical starting point is:

Directories: 755
Files:       644

WordPress itself documents shell commands similar to:

find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

These commands intentionally treat directories and files differently.

Do not run chmod -R 755 on the entire installation

A command such as:

chmod -R 755 /path/to/wordpress

gives the execute bit to ordinary files as well as directories.

That is usually unnecessary.

Similarly:

chmod -R 644 /path/to/wordpress

removes directory execute permissions, which can make directories impossible to traverse.

Use separate rules for files and directories.

755 and 644 are defaults, not commandments

Secure hosting environments can use stricter values such as:

Directories: 750
Files:       640

provided the web server and PHP process still have the required access.

The correct configuration depends on ownership and group membership.

Which WordPress directories need write access?

Not every part of WordPress needs to be writable all the time.

The official WordPress Hardening documentation recommends keeping write access as restricted as practical.

The WordPress root directory

The root contains files such as:

index.php
wp-load.php
wp-settings.php
wp-blog-header.php
wp-config.php

WordPress’s security guidance recommends that these files generally be writable only by the appropriate owner.

wp-admin

wp-admin contains administrative application code.

In ordinary operation, PHP mainly needs to read these files.

WordPress’s hardening guide recommends that files here be writable only by the appropriate user account rather than casually writable by the web-server process.

wp-includes

wp-includes contains most of WordPress Core’s application logic.

Again, normal page execution requires reading these files, not continuously editing them.

wp-content

wp-content is different because it contains user and application-generated content.

Depending on the site, WordPress may need to write to:

• wp-content/uploads/;
• cache directories;
• backup directories;
• language directories;
• temporary plugin directories;
• plugin-defined storage directories.

This is why permissions inside wp-content often require more consideration than WordPress Core directories.

wp-content/uploads

The uploads directory needs to be writable by whatever process handles WordPress media uploads.

If it is not, you may see errors when uploading:

• images;
• documents;
• audio;
• video;
• other permitted file types.

Do not solve an uploads problem by automatically setting the directory to 777.

First verify:

• directory owner;
• group;
• PHP user;
• existing mode;
• parent-directory permissions.

Why 777 permissions are dangerous

Permission:

777

means:

owner  = read + write + execute
group  = read + write + execute
others = read + write + execute

Symbolically:

rwxrwxrwx

This grants every permission class write access.

The official WordPress documentation explicitly warns against using 777 as a routine solution and notes that directories should not simply be made world-writable to fix WordPress write problems.

777 treats the symptom rather than the architecture

Suppose WordPress cannot create:

wp-content/uploads/2026/09/

Changing uploads to 777 may make it work.

But it does not explain why PHP lacked the correct access in the first place.

Possible root causes include:

• wrong owner;
• wrong group;
• incorrect PHP-FPM pool user;
• deployment scripts assigning incorrect ownership;
• parent directories blocking traversal;
• special filesystem ACLs;
• SELinux policy;
• container volume ownership mismatches.

World-writable files increase the damage another compromise can cause

File permissions are not a substitute for preventing vulnerabilities, but restrictive permissions can reduce what a compromised process or account is able to modify.

If everything is writable by everything else, filesystem isolation has little opportunity to help.

The objective is therefore:

minimum write access required for the site to function

not:

maximum write access so errors disappear

How wp-config.php should be protected

wp-config.php is one of the most sensitive files in a WordPress installation.

It commonly contains:

• database credentials;
• authentication salts and keys;
• table-prefix configuration;
• environment-specific constants;
• filesystem settings;
• debug settings.

WordPress’s Hardening WordPress documentation recommends ensuring that only the necessary user and web-server process can read the file.

It notes that permission values such as:

400
440

can be appropriate in compatible environments.

Do not blindly set wp-config.php to 400

A permission of 400 means:

owner = read
group = none
others = none

If the PHP process is not operating as that owner, WordPress may become unable to read its own configuration.

A theoretically stricter number that breaks the site is not a successful security configuration.

Again, ownership and server architecture determine what is appropriate.

wp-config.php can be placed one directory above WordPress

WordPress supports locating wp-config.php one directory above the main installation in appropriate setups.

The official hardening documentation discusses this option, while also noting that its practical security benefit is debated and depends on deployment details.

It should not be treated as a substitute for correct server configuration and file permissions.

Why WordPress sometimes asks for FTP credentials

If WordPress cannot safely modify files directly, it may use its Filesystem API rather than immediately writing through PHP.

The official WordPress Filesystem API documentation describes this abstraction.

WordPress can work through several filesystem methods, including:

• direct filesystem access;
• SSH2;
• the PHP FTP extension;
• FTP sockets.

WordPress detects the filesystem method

Core uses:

get_filesystem_method()

to determine an appropriate transport.

The official get_filesystem_method() reference documents the possible methods as:

direct
ssh2
ftpext
ftpsockets

Direct access involves ownership checks

WordPress does not simply ask:

is this directory writable?

and then conclude that direct access is automatically safe.

The filesystem method detection includes checks intended to determine whether files created directly by PHP have ownership compatible with the WordPress installation.

This is one reason making a directory group- or world-writable does not necessarily mean WordPress should treat direct modification as the correct filesystem method.

FTP prompts often point to server configuration

If WordPress suddenly asks for FTP credentials when installing a plugin, the problem may be related to:

• file ownership;
• PHP process ownership;
• permissions;
• the hosting provider’s security model.

Do not immediately force:

define( 'FS_METHOD', 'direct' );

without understanding why WordPress did not choose direct access automatically.

Should you force FS_METHOD to direct?

The FS_METHOD constant can override WordPress’s automatic filesystem-method selection.

For example:

define( 'FS_METHOD', 'direct' );

But the official wp-config.php documentation recommends changing FS_METHOD only when you are actually troubleshooting filesystem or update problems.

Core’s documentation warns that forcing direct filesystem I/O can create security problems on poorly configured hosts.

Fix ownership before forcing direct writes

If the underlying situation is:

WordPress files owned by wrong account
+
PHP process cannot safely modify them

forcing direct access does not repair the ownership model.

Correct the server configuration first.

Managed hosting may intentionally use a different architecture

Some hosting providers use:

• custom deployment systems;
• read-only application filesystems;
• container images;
• special update workers;
• filesystem proxies.

In those environments, generic advice copied from a shared-hosting tutorial may be completely inappropriate.

WordPress permissions during plugin, theme and Core updates

Installing or updating WordPress software requires temporary write access to application files.

The WordPress upgrader uses the Filesystem API to:

• write temporary files;
• extract packages;
• replace existing files;
• remove old files;
• set appropriate permissions.

The WP_Upgrader documentation shows that WordPress checks whether destination files are writable and can attempt to apply filesystem permissions before replacing them.

Failed updates can be a permission symptom

Errors such as:

• could not create directory;
• destination folder already exists;
• files not writable;
• failed to remove old plugin;

can sometimes involve filesystem ownership or permissions.

But do not assume every update failure is a chmod problem.

Other causes include:

• disk space exhaustion;
• filesystem quotas;
• read-only mounts;
• security software;
• broken archives;
• temporary-directory problems;
• network failures.

FS_CHMOD_FILE and FS_CHMOD_DIR

WordPress defines permission constants for files and directories when using the Filesystem API.

They are:

FS_CHMOD_FILE
FS_CHMOD_DIR

The official WordPress configuration documentation allows these values to be overridden when a hosting environment requires a special permission model.

For example:

define( 'FS_CHMOD_DIR',  ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

Do not define them unless necessary

These constants exist for unusual hosting and filesystem situations.

They are not settings every WordPress installation needs in wp-config.php.

Core normally derives suitable defaults from the existing installation.

The leading zero matters in PHP

In PHP:

0755

is an octal literal.

Permission values passed to filesystem functions should be expressed correctly as octal numbers rather than arbitrary strings or decimal values.

Permissions, WordPress security and file editing

A file being writable by PHP has security implications because application code may then be modified through WordPress itself if another feature exposes that capability.

The built-in theme and plugin editors

WordPress can allow privileged administrators to edit theme and plugin files from the Dashboard.

The official Editing Files documentation notes that the target file must be writable for the built-in editor to modify it.

On production sites where file changes happen through deployments, Git or another controlled process, many administrators disable Dashboard file editing with:

define( 'DISALLOW_FILE_EDIT', true );

DISALLOW_FILE_EDIT does not make files read-only

This constant removes WordPress’s built-in file editing capability.

It does not change the underlying Unix filesystem permissions.

A writable file remains writable by processes that already have operating-system permission to modify it.

DISALLOW_FILE_MODS is broader

WordPress also supports:

define( 'DISALLOW_FILE_MODS', true );

The WordPress file modification API uses this constant when determining whether file modifications are allowed.

It can disable operations such as installing or updating themes and plugins from WordPress.

This is useful in deployment-managed environments, but you need another reliable update process if you disable WordPress-managed modifications.

Permissions and special server security layers

Traditional owner/group/mode permissions are not always the only filesystem security mechanism involved.

Access Control Lists

Linux ACLs can grant additional permissions beyond the basic owner/group/others model.

That means:

ls -l

may not always tell the entire access story.

SELinux

On SELinux-enabled systems, filesystem permissions can appear correct while SELinux policy still blocks PHP or the web server from writing.

The official WordPress file permissions guide specifically includes troubleshooting guidance for SELinux environments.

Changing 755 to 777 will not necessarily override an SELinux policy denial.

Containers and mounted volumes

Docker and other containerized deployments can introduce UID and GID mismatches between:

• the host;
• the PHP container;
• mounted WordPress volumes.

A directory can appear perfectly normal on the host while the user inside the container sees it as owned by another numeric UID.

Again, chmod alone may not be the real answer.

How to diagnose a WordPress permission problem

Do not begin by recursively changing permissions across the entire installation.

First identify the exact operation that fails.

1. Identify the target path

Determine whether WordPress is trying to modify:

• wp-content/uploads;
• a plugin directory;
• a theme directory;
• wp-content/languages;
• a cache folder;
• a backup folder;
• the WordPress root.

2. Inspect permissions

Use:

ls -ld /path/to/directory
ls -l /path/to/file

or inspect the permissions through your hosting control panel or file manager.

3. Inspect owner and group

Do not stop after reading:

755

or:

644

Check which user and group own the resource.

4. Determine which account PHP runs as

Depending on the environment, PHP may run as:

• your hosting account;
• www-data;
• apache;
• nginx;
• a dedicated PHP-FPM pool user;
• a container-specific UID.

5. Check parent directories

A process needs appropriate traversal permissions on the path leading to the target.

A correctly writable child directory can still be inaccessible because a parent directory blocks traversal.

6. Check storage and filesystem state

Verify:

• available disk space;
• inode availability;
• disk quotas;
• read-only mounts;
• security policy.

7. Make the narrowest necessary change

If only:

wp-content/uploads/

needs a corrected group owner, do not recursively loosen permissions on:

wp-admin/
wp-includes/
wp-config.php

Change only what is necessary.

Useful chmod and ownership commands

If you have SSH access and understand the server’s ownership model, common diagnostic or corrective commands include the following.

Set directories to 755

find /path/to/wordpress -type d -exec chmod 755 {} \;

Set files to 644

find /path/to/wordpress -type f -exec chmod 644 {} \;

Inspect ownership

ls -la /path/to/wordpress

Change owner

A typical Linux command has the form:

chown -R username:groupname /path/to/wordpress

Do not copy a username or group from a random tutorial.

The correct owner depends entirely on your server.

Do not recursively chown production files blindly

A managed host, deployment platform or container may intentionally use different owners for different paths.

Changing everything recursively can break:

• deployment workflows;
• shared group access;
• server-managed files;
• container volume mappings.

If the server architecture is unfamiliar, check the hosting documentation before changing ownership.

Permissions are not the same as WordPress capabilities

There are two different permission systems that WordPress administrators often confuse.

WordPress capabilities

Application-level capabilities answer questions such as:

• Can this user install plugins?
• Can this user upload media?
• Can this user edit themes?
• Can this user manage options?

These are WordPress authorization decisions.

Filesystem permissions

Operating-system permissions answer questions such as:

• Can the PHP process write this file?
• Can this Unix account read this directory?
• Can this process replace a plugin file?

A WordPress Administrator can have:

install_plugins capability

while the server filesystem still refuses to write the plugin directory.

Both layers must permit the operation.

For the application side of permissions, see WordPress User Roles and Capabilities Explained.

How file permissions relate to other WordPress security problems

Correct filesystem permissions are one layer of a broader security model.

They do not replace secure file validation or safe application code.

Path traversal is a separate problem

A plugin that accepts arbitrary filesystem paths still needs to verify that those paths remain inside the permitted directory.

Even correctly permissioned files can be exposed by insecure path handling.

See Path Traversal: What It Is and How Plugins Prevent It.

Upload validation is separate too

A writable uploads directory is necessary for media uploads.

But write access says nothing about whether an uploaded file is safe.

File extension, MIME type, file content and execution policy still matter.

See Why Double-Extension Uploads Are Dangerous for a related example.

How TheOneWP can help with file management

TheOneWP includes tools for inspecting and managing WordPress files without pretending that filesystem security can be reduced to one chmod button.

File Manager

File Manager provides a WordPress interface for working with site files while exposing information such as file permissions alongside the file and directory structure.

The module also includes protections for filesystem operations, including path-resolution checks designed to keep managed paths inside their permitted roots.

This can make values such as:

0644
0755

easier to inspect in context rather than treating them as mysterious numbers supplied by a hosting support ticket.

Backup Manager

Before making large filesystem changes, Backup Manager provides a recovery layer for site files and data.

Changing permissions, ownership or deployment configuration is exactly the sort of operation where a current backup earns its keep.

WordPress file permissions checklist

• Understand the difference between read, write and execute.
• Remember that directory execute permission means traversal.
• Check owner, group and mode together.
• Use 755 for directories and 644 for files only as common starting points.
• Use stricter values when your server architecture supports them.
• Do not assume every WordPress installation needs identical permissions.
• Avoid 777 as a generic fix.
• Do not recursively apply 755 to ordinary files.
• Do not recursively apply 644 to directories.
• Protect wp-config.php more strictly when the server allows it.
• Verify that PHP can still read wp-config.php before using 400 or 440.
• Keep WordPress Core files writable only by the accounts that genuinely need to modify them.
• Give wp-content/uploads the write access required for media uploads.
• Inspect parent-directory permissions when a child path appears correct.
• Check PHP-FPM or web-server user identity.
• Check filesystem ownership before changing chmod.
• Do not force FS_METHOD to direct without understanding the hosting environment.
• Use FS_CHMOD_FILE and FS_CHMOD_DIR only when the environment genuinely requires overrides.
• Remember that WordPress capabilities and Unix permissions are separate systems.
• Check SELinux, ACLs, containers and read-only mounts when traditional permissions look correct.
• Back up the site before large recursive ownership or permission changes.
• Make the smallest permission change that solves the actual requirement.

Related guides

• Path Traversal: What It Is and How Plugins Prevent It
• Why Double-Extension Uploads Are Dangerous
• WordPress Staging Site Best Practices
• Why WordPress Blocks SVG Uploads by Default
• WordPress User Roles and Capabilities Explained
• A WordPress Login Hardening Checklist
• WordPress Maintenance Mode Best Practices
• Hiding vs. Restricting Access to WordPress Media

Final thoughts

WordPress file permissions are easier to understand once you stop treating values such as 644 and 755 as magic WordPress codes.

They are Unix filesystem permissions.

The basic model is:

owner
group
others

×

read
write
execute

WordPress then operates inside that model through whichever user PHP and the web server actually use.

For many installations:

files       → 644
directories → 755

is a sensible baseline.

But a secure configuration is not defined by those numbers alone.

A file’s owner matters.

Its group matters.

The PHP-FPM user matters.

The hosting architecture matters.

The purpose of the directory matters.

wp-content/uploads needs write access because WordPress creates media files there. Most WordPress Core files do not need to be continuously writable by the web process simply to serve pages.

Likewise, making everything 777 can make permission errors disappear while simultaneously removing one of the filesystem’s most basic security boundaries.

The correct approach is therefore not:

WordPress cannot write
↓
increase permissions until it works

It is:

identify the operation
↓
identify the target path
↓
inspect owner and group
↓
identify the PHP/web-server account
↓
inspect current permissions
↓
check additional filesystem restrictions
↓
grant only the access actually required

Once permissions and ownership are aligned with the server architecture, WordPress can upload files, install updates and manage content without making the entire application unnecessarily writable.