ThisCalculator

Everyday

Fix WordPress File & Folder Permissions on Ubuntu VPS

Updated · Standard formula, shown below

Fix WordPress File & Folder Permissions on Ubuntu VPS

To fix WordPress file and folder permissions on an Ubuntu VPS, you need to reset ownership to the web server user (usually www-data) and set directories to 755 while files are set to 644. This article explains the exact commands, why permissions matter, and how to avoid common pitfalls.

Why WordPress Permissions Break

WordPress runs on a LAMP or LEMP stack where the web server (Apache or Nginx) executes PHP scripts. If you upload files via SSH or FTP, they may be owned by your user account instead of the web server user. This causes issues like:

  • White screen of death (WSOD) when WordPress cannot read its core files.
  • Inability to upload media or install plugins/themes.
  • Error messages like “Unable to create directory wp-content/uploads� or “The uploaded file could not be moved to wp-content/uploads.�
  • Security warnings from your hosting panel or security plugin.

Permissions are a set of read (r), write (w), and execute (x) flags for three groups: owner, group, and others. On Ubuntu, the web server typically runs as www-data, so files must be readable and writable by that user.

How to Check Current Permissions

Before making changes, inspect your current setup. SSH into your VPS and navigate to your WordPress root (e.g., /var/www/html). Use:

ls -la

This shows the owner, group, and permission string for each item. For example, -rw-r--r-- means the owner can read/write, and group/others can only read. Directories will show drwxr-xr-x (owner can read/write/execute, others can read/execute).

You can also run stat -c '%a %U %G %n' file.php to see numeric permissions (like 644) and the owner/group.

The Correct Permission Commands

For a typical single-site WordPress installation, the recommended setup is:

  • All files: 644 (owner read/write, group and others read-only)
  • All directories: 755 (owner read/write/execute, group and others read/execute)
  • Owner: www-data (or your web server user)
  • Group: www-data

Run these commands from your WordPress root:

sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} 
sudo find /var/www/html -type f -exec chmod 644 {}

If you use a different web server user (e.g., nginx on some setups), replace www-data with that username. The -R flag applies ownership recursively, and the find commands set permissions only on directories or only on files.

Special Cases: wp-content and Uploads

Sometimes you need to allow WordPress to write to specific directories for plugins, themes, and uploads. The safest approach is to keep everything 755/644 and rely on FTP credentials for plugin updates. However, if you want WordPress to update plugins automatically over SSH (without FTP), you can give the web server write access to wp-content:

sudo chown -R www-data:www-data wp-content

This is often sufficient. For the uploads folder, the same ownership is fine. Avoid setting wp-content to 777—it is a security risk because any user on the system can modify files. If you must use 777 temporarily, revert it immediately after the task.

Common Mistakes and How to Fix Them

  • Using the wrong user: Check your web server config. For Apache on Ubuntu, it’s www-data. For Nginx, it’s often www-data too, but some setups use nginx. Run ps aux | grep nginx to see the user.
  • Setting everything to 777: This makes your site vulnerable to file injection. Never use 777 on a production server.
  • Forgetting to change ownership: Permissions alone won’t help if the owner is wrong. If files are owned by root, the web server can’t write to them even with 755.
  • Applying permissions to symlinks: If you use symlinks (e.g., for staging), chmod on the link may not affect the target. Use -L to follow links if needed.
  • Not clearing cache after changes: Some plugins or opcode caches (like OPcache) may store old file permissions. Restart PHP-FPM or Apache after making changes.

How to Verify the Fix

After running the commands, test your site:

  1. Load your homepage and a few posts.
  2. Go to Media → Add New and upload an image.
  3. Try installing a plugin from the dashboard.

If you still see errors, check the PHP error log (/var/log/php*.log or /var/log/apache2/error.log). Also verify that the wp-content/uploads directory exists and is writable:

sudo -u www-data touch /var/www/html/wp-content/uploads/test.txt

If that succeeds, the web server can write. Remove the test file afterward.

Security Considerations

Correct permissions are part of a secure WordPress setup. Here are additional best practices:

  • Keep core files read-only for the web server after installation. You can do this by setting files to 444 and directories to 555, but then updates require manual changes. Most admins keep 644/755 for simplicity.
  • Disable file editing in WordPress by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php.
  • Use a security plugin that scans for changed files, but do not rely on it to fix permissions.
  • Regularly update WordPress, themes, and plugins to avoid vulnerabilities.

If you use a managed hosting control panel (like Plesk or cPanel), it may manage permissions automatically—do not override those unless you know what you’re doing.

Frequently Asked Questions

What are the exact commands to fix WordPress permissions?

From your WordPress root, run: sudo chown -R www-data:www-data . then find . -type d -exec chmod 755 {}
find . -type f -exec chmod 644 {}
. This sets ownership to the web server user and standard file/directory permissions.

Why can’t I upload files even after setting 755/644?

Ownership is the most likely culprit. Ensure the web server user owns the wp-content and uploads directories. Also check that the directory exists and that SELinux (if enabled) is not blocking. On Ubuntu, SELinux is usually not installed, but AppArmor may interfere—check aa-status.

Is it safe to set wp-content to 777?

No. 777 allows any user on the system to read, write, and execute files, which is a severe security risk. Use 755 for directories and 644 for files, and only give write access to the web server user via ownership.

How do I find the web server user on Ubuntu?

Run ps aux | grep -E 'apache|nginx' and look at the first column. For Apache, it’s usually www-data. For Nginx, it may be www-data or nginx. Alternatively, check /etc/apache2/apache2.conf for User and Group directives.

What if I use a different user for SSH uploads?

You can add your SSH user to the www-data group: sudo usermod -a -G www-data youruser. Then set group permissions to allow write access, e.g., chmod 775 for directories and chmod 664 for files, but this is less common. The standard approach is to use www-data as owner.

Do I need to change permissions after every WordPress update?

Usually no. If you update via the dashboard, the web server (which owns the files) will handle it. If you update via SSH or Git, you may need to reapply ownership if the new files are owned by your user.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.