Linux File Permissions for Web Servers and WordPress

Directories 755, files 644. Directories need the execute bit so they can be entered; files only need to be read. The web server should never need write access to your application code, only to the specific directories that store uploads, cache and logs. Anything wider than that is a security cost with no benefit.

Every file carries three sets of three permissions: what the owner can do, what the owning group can do, and what everybody else can do. Each set has read, write and execute. Run ls -l and the first ten characters spell it out.

$ ls -l /var/www/example.com
-rw-r--r--  1 deploy www-data   405 Jul 29 09:14 index.php
drwxr-xr-x  4 deploy www-data  4096 Jul 29 09:14 wp-content

  -rw-r--r--
  |[-][-][-]
  | |  |  +-- everyone else: read only
  | |  +----- group (www-data): read only
  | +-------- owner (deploy): read and write
  +---------- file type: - is a file, d is a directory

The numeric form adds the bits together: read is 4, write is 2, execute is 1. So 6 is read plus write, 7 is all three, 5 is read plus execute. Three digits, one for each set.

Not the web server. This is the single most common mistake. On Debian and Ubuntu the web server runs as www-data; on AlmaLinux, Rocky and CentOS it runs as apache or nginx. If that account owns your files, then any code the web server executes can rewrite any file on the site, which is exactly what an attacker who lands a webshell wants.

The safer arrangement is a separate deploy user owning the files, with the web server user placed in the group. The web server then reads everything and writes only where you have explicitly granted group write.

# Find out which user your web server actually runs as
ps aux | grep -E '[a]pache2|[n]ginx|[p]hp-fpm' | awk '{print $1}' | sort -u

# Own the files as the deploy user, group them to the web server
sudo chown -R deploy:www-data /var/www/example.com

# Add the deploy user to the web server group so both can collaborate
sudo usermod -aG www-data deploy

WordPress follows the general rule with two exceptions: wp-config.php should be tighter than everything else because it holds your database password, and wp-content/uploads must be writable by the web server because that is where media lands.

Never run chmod -R 755 across a site: that sets the execute bit on every file, including images and PHP source. Use find to apply directory and file rules separately. Run the commands in this order and nothing will be left in a broken state.

cd /var/www/example.com

# 1. Ownership first: deploy user owns, web server group reads
sudo chown -R deploy:www-data .

# 2. Directories to 755
sudo find . -type d -exec chmod 755 {} \;

# 3. Files to 644
sudo find . -type f -exec chmod 644 {} \;

# 4. Lock down the config file
sudo chmod 640 wp-config.php

# 5. Give the web server group write access to uploads only
sudo chmod -R 775 wp-content/uploads
sudo chmod g+s wp-content/uploads

Before you run any of this on a live site, take a backup you have actually tested restoring. A permissions reset is low risk, but it is applied recursively and there is no undo. Our backup strategy guide covers what a usable backup looks like.

Work from the symptom. Three symptoms cover nearly everything, and each points at a different cause.

# Shows permissions at every level of the path
namei -l /var/www/example.com/wp-content/uploads/2026/07

# Test as the web server user itself, which is the definitive answer
sudo -u www-data test -r /var/www/example.com/index.php && echo 'can read' || echo 'cannot read'
sudo -u www-data test -w /var/www/example.com/wp-content/uploads && echo 'can write' || echo 'cannot write'

If the error log is where you need to look next, understanding Linux system logs covers where each service writes and how to follow it live.

Most permission drift comes from mixed access methods. You deploy over SSH as deploy, a colleague uploads over SFTP as webmaster, and a plugin writes as www-data. Three owners, three sets of permissions, and files the rest of the team cannot edit.

• Put every human in the same group and set that group on the document root, so anything anyone creates is editable by the rest of the team.
• Set the setgid bit on the document root with chmod g+s, so new files and directories inherit the group instead of taking the creator's default.
• Set a shared umask of 002 for the deploy accounts, which makes new files 664 and new directories 775 rather than 644 and 755.
• Pick one deployment method and stick to it. Mixing git pull, SFTP and the WordPress plugin installer on the same site is what produces the mess in the first place.

sudo groupadd webdev
sudo usermod -aG webdev deploy
sudo usermod -aG webdev webmaster

sudo chown -R deploy:webdev /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 2775 {} \;
sudo find /var/www/example.com -type f -exec chmod 664 {} \;