Wrong file permissions break WordPress uploads, lock you out of the admin, and open doors for attackers. I've seen sites where a single chmod 777 command turned a minor plugin bug into a full compromise. Getting permissions right from the start saves you from late-night panic and support tickets.
This guide walks you through the exact steps to configure secure WordPress file and directory permissions on a Linux server, whether you're using shared cPanel hosting or a VPS. You'll set correct ownership, apply the right numeric modes, and verify everything works.
Step 1: Connect to your server via SSH
You need command-line access. On shared hosting, log into cPanel and open Terminal. On a VPS, use your SSH client:
ssh [email protected]
Navigate to your WordPress root directory. Typically it's /home/username/public_html on cPanel or /var/www/html on a standard VPS:
cd /home/username/public_html
Confirm you're in the right place by checking for wp-config.php:
ls -la wp-config.php
If the file exists, you're good.
Step 2: Identify the web server user
WordPress writes files through PHP, and PHP runs as a specific system user. You need to know that user's name.
On Apache with mod_php or suPHP on cPanel, PHP usually runs as your account user. Check with:
whoami
On Apache with php-fpm or Nginx with php-fpm, PHP runs as www-data, nginx, or apache. Check the running PHP process:
ps aux | grep php-fpm | head -1
Look at the first column for the username. On many modern setups it's www-data.
Write down that username. You'll use it in the next step.
Step 3: Set the correct file owner and group
All WordPress files should be owned by your account user, and the group should match the web server user so PHP can write when needed.
If you're on cPanel shared hosting and your account user is exampleuser, set ownership like this:
sudo chown -R exampleuser:exampleuser /home/exampleuser/public_html
If you're on a VPS where your account is deploy and the web server runs as www-data, use:
sudo chown -R deploy:www-data /var/www/html
The -R flag applies the change recursively to all files and subdirectories.
If you don't have sudo access on shared hosting, contact your host's support to set ownership correctly.
Step 4: Set directory permissions to 755
Directories need execute permission so the web server can traverse them and list contents. The safe standard is 755:
- Owner can read, write, execute (7)
- Group can read and execute (5)
- Others can read and execute (5)
Apply it to all directories:
find /home/exampleuser/public_html -type d -exec chmod 755 {} \;
Replace the path with your actual WordPress root. The find command locates every directory (-type d) and runs chmod 755 on each.
This gives WordPress and plugins the ability to create subdirectories when needed, while keeping write access restricted to the owner.
Step 5: Set file permissions to 644
Regular files—PHP scripts, images, CSS—should be readable by everyone but writable only by the owner. That's 644:
- Owner can read and write (6)
- Group can read (4)
- Others can read (4)
Apply it:
find /home/exampleuser/public_html -type f -exec chmod 644 {} \;
This prevents the web server from modifying core WordPress files, themes, or most plugins. If an attacker finds a vulnerability, they can't easily inject code into existing PHP files.
Step 6: Adjust wp-config.php to 640 or 600
wp-config.php holds your database credentials and secret keys. Lock it down tighter than other files.
Set it to 640 if the web server needs to read it (most setups):
chmod 640 /home/exampleuser/public_html/wp-config.php
Or 600 if you want only the owner to read it:
chmod 600 /home/exampleuser/public_html/wp-config.php
With 600, PHP running under your account user can still read the file, but group and world permissions are zero. Use 640 if you're unsure; it's the safer default for most hosting environments.
Step 7: Make wp-content/uploads writable by the web server
WordPress uploads media files into wp-content/uploads. The web server user must be able to write here.
If you set the group correctly in Step 3, the directory is already writable by the group. Verify:
ls -ld wp-content/uploads
You should see drwxr-xr-x or drwxrwxr-x if group write is enabled. If uploads fail, add group write permission:
chmod 775 wp-content/uploads
find wp-content/uploads -type d -exec chmod 775 {} \;
Files inside uploads can stay 644 because PHP creates them with the right ownership automatically.
Never use 777 on uploads. I've seen shared hosting accounts where one compromised script in a 777 directory let attackers write to every other file on the server.
What if plugin installs and updates fail?
WordPress tries to write to wp-content/plugins and wp-content/themes when you install or update from the admin. If those directories are 755 and owned by your account user, but PHP runs as www-data, writes will fail.
You have two options.
Option A: Enable group write on those directories:
chmod 775 wp-content/plugins
chmod 775 wp-content/themes
This works if the group is set to the web server user. It's convenient but slightly less secure because any process running as the web server group can write there.
Option B: Use FTP credentials in wp-config.php:
Add these lines above the "stop editing" comment:
define('FS_METHOD', 'ftpext');
define('FTP_HOST', 'localhost');
define('FTP_USER', 'your_ftp_username');
define('FTP_PASS', 'your_ftp_password');
WordPress will use FTP to write files, so the web server user doesn't need direct write access. This keeps directories at 755 and files at 644. The downside is storing an FTP password in wp-config.php.
For managed WordPress hosting or VPS setups, Option A with careful group ownership is cleaner.
Step 8: Restrict .htaccess to 644
If you're running Apache, WordPress uses .htaccess for permalinks and other rewrites. An attacker who can write to .htaccess can redirect traffic or execute code.
Set it to 644:
chmod 644 .htaccess
WordPress can still update permalink rules if the file is writable by the owner, but the web server can't modify it unless you temporarily change permissions.
If you need to regenerate permalinks from the WordPress admin, temporarily set .htaccess to 664, save permalinks, then change it back to 644.
Step 9: Verify with a test upload
Log into your WordPress admin and go to Media > Add New. Upload an image.
If the upload succeeds and the image appears in your media library, permissions are working. If you get a permissions error, check:
- Is
wp-content/uploadswritable by the group? - Did you set the group to the web server user in Step 3?
- Are parent directories (
wp-content) executable by the web server?
Run this to double-check ownership and permissions:
ls -ld wp-content wp-content/uploads
You should see your account user as owner and the web server user as group, with drwxr-xr-x (755) or drwxrwxr-x (775).
Step 10: Document your setup and monitor logs
Write down the owner, group, and permission scheme you applied. Store it in a notes file or internal wiki.
Something like:
- Owner: exampleuser
- Group: www-data
- Directories: 755 (775 for uploads, plugins, themes if needed)
- Files: 644 (640 for wp-config.php)
Set a reminder to review permissions after major WordPress updates or when installing new themes. Some plugins try to change permissions during activation.
Check your server's error log regularly:
tail -f /var/log/apache2/error.log
Or on cPanel, view logs through the cPanel interface under Metrics > Errors.
Permission errors show up as "Permission denied" or "Failed to write" messages. Catching them early prevents confused support tickets later.
Start with safe defaults
Correct WordPress file permissions aren't complicated once you understand owner, group, and the numeric modes. Start with 755 for directories and 644 for files, set ownership so the web server group can write only where needed, and you'll avoid most permission headaches.
If you run into errors after following these steps, check your error logs first. They'll tell you exactly which file or directory has the wrong permission. Fix that one path, verify the upload or update works, then move on. Trying to debug permissions by guessing wastes time.