WordPress Directory Error EC2: Fixed for Good
Updating plugins in WordPress is usually simple — but if you're running your site on an AWS EC2 instance and see this frustrating error:
Update failed: Could not create directory...
You’re not alone.
In this post, I’ll walk you through how I fixed this error on multiple blog sites hosted on EC2 by applying the correct file permissions. This guide is especially helpful for developers and sysadmins managing WordPress on cloud servers like AWS.
🚫 The Problem
When trying to update a plugin, WordPress throws this error:
Update failed: Could not create directory. /var/www/your-site.com/wp-content/upgrade/plugin-folder
This means WordPress (actually, PHP) doesn’t have permission to create or write to the upgrade directory.
✅ The Root Cause
Most commonly, this happens when:
- The directory is owned by the wrong user
- Incorrect permissions prevent PHP from writing
- The directory doesn’t exist at all
Even if other sites on the same server work fine, this error can still occur on a specific site if the ownership or permissions are mismatched.
🔧 Step-by-Step Fix (Tested on EC2)
Here’s what I did to solve it for my blog sites:
1. Check Current Ownership and Permissions
ls -ld /var/www/*
ls -ld /var/www/*/wp-content
This will show which user owns each site’s files. I kept ownership as ec2-user for consistency.
2. Recreate the upgrade Directory
If the upgrade folder is missing or restricted, recreate it safely:
sudo rm -rf /var/www/your-site.com/wp-content/upgrade
sudo mkdir /var/www/your-site.com/wp-content/upgrade
sudo chown -R ec2-user:www /var/www/your-site.com/wp-content/upgrade
sudo chmod -R 775 /var/www/your-site.com/wp-content/upgrade
3. Fix File and Folder Permissions
Ensure proper access throughout the project:
sudo find /var/www/your-site.com -type d -exec chmod 775 {} \;
sudo find /var/www/your-site.com -type f -exec chmod 664 {} \;
4. Set Sticky Group Bit (Recommended)
This ensures all new folders inherit the correct group:
sudo chmod g+s /var/www/your-site.com/wp-content
5. Restart PHP and Web Server
sudo systemctl restart php-fpm
sudo systemctl restart nginx
✅ Result
After applying these changes, plugin updates now work smoothly across all sites — no more errors.:
🧠 Pro Tip for Multi-Site Management
If you manage multiple WordPress sites on a single EC2 server:
- Always use a consistent user (e.g.,
ec2-user) - Set group access to
wwwor similar - Use
chmod g+son critical folders likewp-contentto prevent future permission issues
📝 Conclusion
This error may look scary, but it’s easy to fix once you understand how permissions work in a Linux environment. By applying the correct ec2-user ownership and folder permissions, you’ll prevent WordPress plugin update failures and save hours of manual work.
Why This Error Really Happens
The "could not create directory" message is WordPress telling you that the PHP process — typically running as apache or www-data — lacks write permission somewhere under wp-content. It shows up after migrations, after restoring from backup as root, or after a well-meaning chown to your SSH user. The fix isn't ever chmod 777; it's aligning ownership with the process user, exactly as the steps above do. Understanding that one sentence turns this from a recurring mystery into a thirty-second fix you'll never need to Google again.
The Permission Model Worth Memorizing
Directories at 755, files at 644, everything under the web root owned by the web server user — with one deliberate exception: wp-config.php at 640. That combination lets WordPress update plugins, themes, and core without FTP credentials, while keeping other system users out. If you deploy code by SSH as a different user, add that user to the web server's group and grant group write on the specific paths deployments touch, rather than flipping ownership back and forth and breaking updates every release.
Balancing Convenience Against Hardening
Full write access for the web user is what makes one-click updates work, but it also means a compromised plugin can write anywhere WordPress can. On sites where security outranks convenience, tighten wp-content/plugins and themes to read-only between updates and open them deliberately during maintenance windows — or define DISALLOW_FILE_EDIT in wp-config.php at minimum, which removes the built-in file editor attackers love. Pick the trade-off consciously per site; the wrong answer is not knowing you made one.
Confirming the Fix Held
Verify like you mean it: update a small plugin from the dashboard, upload a media file, and switch themes once. All three exercise different write paths. Then re-run ls -la on wp-content and confirm nothing got re-owned by root along the way — the classic relapse is a cron job or deploy script quietly resetting ownership every night, recreating the error a week later and convincing everyone the fix "didn't stick."
The Five-Minute Audit Worth Running Quarterly
Permissions drift. Plugins ship files with odd modes, migrations copy things as the wrong user, and teammates make hotfixes as root. Once a quarter, run a find for anything not owned by the web user under the web root and anything world-writable anywhere — two commands, thirty seconds each. Fix what they surface immediately, then check the WordPress Site Health screen for filesystem warnings you may have normalized. The audit takes five minutes and catches the drift while it's still trivia rather than an incident.
One Sentence to Remember
Every WordPress file-permission problem reduces to one question: does the user running PHP own the path it's trying to write? Answer that with ps aux | grep php and ls -la, align the two, and the whole class of errors — updates, uploads, caches, translations — disappears at once. That mental model outlasts any specific fix, survives server migrations, and is the difference between resolving this in thirty seconds and re-Googling it every few months.
File permissions are the rare server topic where the correct answer never changes — learn it once here and it holds on every Linux host you'll ever touch.
The Permission Model That Prevents Repeats
The WordPress directory error EC2 fix sticks when ownership and process user match by design, not by chmod 777 — set it once correctly and updates never break again. My the disk usage rescue and server hardening go deeper.
If you want your WordPress server configured properly, that's something I do through Ramlit.
