WordPress File Permissions: Setting 755/644 and Checking Ownership

This article is a localized edition of the Japanese original. Read the Japanese original

When image uploads fail in WordPress, a plugin update shows the "Connection Information" screen (the FTP login form), or you get a 403 error, the cause is often the combination of file permissions and file ownership. This article walks through how to check and set them, based on the recommendations in the official WordPress documentation (the "File Permissions" page of Advanced Administration). The information is current as of October 2026.

Before you start, back up your files and your database.

What the permission numbers mean

A permission value lists, for the owner, the group and everyone else, the sum of read (r=4), write (w=2) and execute (x=1). For a folder, "execute" means permission to enter it (to open the files inside).

For suEXEC-style shared hosting, the official documentation recommends 755 or 750 for folders and 644 or 640 for files.

Whether WordPress can write depends on the owner

A common misconception is that "anything below 755 breaks uploads." In fact, only the owner can write to a 755 folder. So the result depends on the setup:

• If PHP runs as the same user that owns the folder: WordPress can write with 755
• If PHP runs as a different user (such as www-data or apache) and the folder is owned by your FTP user: WordPress cannot write with 755

So when uploads or plugin updates fail, before raising the numbers, check whether the folder owner and the user running PHP are the same.

During plugin and theme updates, WordPress checks whether a file created by PHP has the same owner as the WordPress files. If they differ, it does not write directly and instead asks for FTP details on the "Connection Information" screen. If you see that screen, the owners do not match.

Which user PHP runs as

If WordPress still cannot write on shared hosting after setting 755/644, check in your host's control panel or with their support whether some files are owned by a different user (for example, because work was once done as root).

Step 1: Check the current state

Connect over SSH, go to your WordPress folder and check. Replace /var/www/html with your own WordPress folder.

cd /var/www/html

# Show permissions, owner and group
ls -la
ls -la wp-content/
ls -la wp-content/uploads/

On the left, drwxr-xr-x corresponds to 755 and -rw-r--r-- to 644. The next two columns to the right are the owner and the group.

You can check which user runs PHP with these commands.

# Which user the PHP-FPM workers run as
ps -eo user,comm | grep -E 'php-fpm|php[0-9.]*-fpm' | sort | uniq -c

# For Apache
ps -eo user,comm | grep -E 'apache2|httpd' | sort | uniq -c

The root line is the master process. The user on the other lines is the one actually running PHP.

In an FTP client such as FileZilla, right-click a file and open its file attributes (permissions) to see the number. FileZilla can also show an owner column.

Step 2: Set folders and files in bulk over SSH

Run this in your WordPress folder. -type d selects folders and -type f selects files.

cd /var/www/html

# Set folders to 755
find . -type d -exec chmod 755 {} +

# Set files to 644
find . -type f -exec chmod 644 {} +

If you give folders and files the same value, as with chmod -R 755, every file gets the execute bit, so set them separately as above.

Step 3: Align the owner

On shared hosting (PHP runs as your account user)

If the files are owned by your account user, nothing else is needed. If some files were created by root or another user, contact your host (on most shared hosting, customers cannot change file ownership).

On a VPS where PHP runs as www-data or similar

There are two approaches.

The first is to make the PHP user own the entire WordPress install. Updates and uploads from the admin screen work as is, but if PHP is compromised, the WordPress core files can be rewritten as well.

# Debian/Ubuntu example (PHP runs as www-data)
sudo chown -R www-data:www-data /var/www/html

The second is to keep the files owned by a working user (for example deploy) and give group write access only to the folders that need it. The official documentation also notes that when WordPress writes through group permissions, folders may need 775 and files 664.

# Owner deploy, group www-data
sudo chown -R deploy:www-data /var/www/html

# Allow group write only on the uploads folder
sudo find /var/www/html/wp-content/uploads -type d -exec chmod 775 {} +
sudo find /var/www/html/wp-content/uploads -type f -exec chmod 664 {} +

With this approach, plugin, theme and core updates from the admin screen will not work (or the "Connection Information" screen appears), so run updates as the deploy user with WP-CLI or similar. Choose between the two based on what matters more to you: easy updates from the admin screen, or limiting the damage if the site is compromised.

Step 4: Lock down wp-config.php

wp-config.php contains your database password, so keep other users from reading it. However, if PHP cannot read it, the site stops loading.

# When PHP runs as the file owner
chmod 600 /var/www/html/wp-config.php

# When running with owner deploy and group www-data
chmod 640 /var/www/html/wp-config.php

After changing it, make sure the front page and the admin screen still load. If they do not, set it back to 644 and review the owner and group.

Step 5: Set permissions individually over FTP

If you cannot use SSH, use an FTP client. This example uses FileZilla.

1. Connect to the server and open the WordPress folder
2. Right-click the folder and choose the item for changing file attributes (permissions)
3. Enter 755 as the numeric value, check the option to apply to subdirectories (labeled "Recurse into subdirectories" in English), set it to apply to directories only, and click "OK"
4. Open the same dialog for the folder again, enter 644, apply to subdirectories, set it to apply to files only, and click "OK"

FTP cannot change the owner. If ownership is the cause, fix it through your host's control panel or support.

What to check for each symptom

Why not to use 777

777 means every user and process on the server can write to the file. The official documentation also advises against it, because files can be rewritten if, for example, another web server process is compromised. If a plugin's instructions ask for 777, ask the author or your host whether there is another way. Once ownership is aligned, 755/644 normally works.

Summary

• The baseline is 755 for folders and 644 for files. Use find to set folders and files separately
• Whether WordPress can write depends not only on the numbers but on whether the owner matches the PHP user
• On a VPS where PHP runs as www-data or similar, either align the owner or add group write (775/664) only to the folders that need it
• Restrict wp-config.php to 600, 640 or similar, but confirm PHP can still read it
• Do not use 777

Related articles:

• WordPress file permission best practices: what 755/644 mean and how to choose the owner
• How to fix permission errors on the WordPress uploads folder
• How to fix 403 errors caused by file permissions
• How to place and configure wp-config.php securely

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)