You click "Update Now" on a plugin or theme, the progress bar spins for a few seconds, and then WordPress hits you with a wall of red text: "Update failed: Could not create directory." No plugin name in the error, no obvious cause, and the plugin list still shows the old version sitting there, half-updated. If you've hit this on a cPanel account or a VPS running your own WordPress, here's what's actually going on and how to clear it for good.
Symptom: What This Error Actually Looks Like
It shows up a few different ways depending on the plugin and your PHP setup:
Update failed: Could not create directory.with no further detailDownloading update from https://downloads.wordpress.org/... failed. Destination directory for file streaming does not exist or is not writable.- The update spinner finishes, but the plugin version number never changes
- A half-extracted plugin folder appears, sometimes named something like
plugin-name.tmpor with a trailing dash, next to the real one
It's almost always isolated to updates — the rest of the site keeps working normally, which is exactly why it's confusing. Nothing else is broken, so it doesn't feel like a permissions problem at first glance.
Cause: Why WordPress Can't Create That Folder
WordPress updates a plugin or theme in three steps: download the zip to a temp folder, extract it, then swap the old folder for the new one. "Could not create directory" means step two or three failed — the PHP process couldn't write a new folder inside wp-content/plugins, wp-content/upgrade, or wp-content/themes. That comes down to one of these:
| Cause | How to spot it |
|---|---|
| Wrong file ownership | Plugin folders owned by a different user/group than the one PHP runs as |
| Directory permissions too tight | wp-content/plugins or upgrade folder set to 644 or 750 instead of 755 |
| Disk quota or inode limit hit | cPanel account is at or near its quota — new folders can't be created even with correct permissions |
Missing wp-content/upgrade folder | Some managed environments or migrations drop this folder entirely |
| open_basedir or suPHP restriction | PHP handler blocks writes outside the account's home path |
| FTP credentials required | WordPress can't detect direct filesystem write access and falls back to asking for FTP details, then fails silently if those are wrong |
On shared cPanel hosting, the most common one by far is a mismatch between the PHP execution user and the file owner — usually left over from a migration, a restore from a backup taken on a different server, or a developer who uploaded files over FTP as a different account.
Fix: Step by Step
1. Check ownership and permissions via SSH
If you have SSH access (Web Hosting and VPS plans on SkyServer both support this), this is the fastest way to diagnose it:
cd ~/public_html/wp-content
ls -la
ls -la plugins/ | head -20
Every folder should be owned by your cPanel username, not nobody, root, or some other account. If you see a mismatch, fix it recursively:
chown -R yourusername:yourusername wp-content
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;
Replace yourusername with your actual cPanel account username — you can confirm it by running whoami in the same SSH session.
2. Make sure the upgrade folder exists and is writable
WordPress stages every update inside wp-content/upgrade before moving files into place. If that folder is missing or has the wrong owner, updates fail even when everything else looks fine:
mkdir -p wp-content/upgrade
chown yourusername:yourusername wp-content/upgrade
chmod 755 wp-content/upgrade
3. Rule out a disk quota or inode limit problem
Permissions can be perfect and updates will still fail if the account is out of space. Check your usage in cPanel under Home » Statistics, or from SSH:
df -h ~
quota -s
If you're near 100% on disk or inodes, clear space first — old backup zips in public_html, bloated log files, or leftover .tmp folders from previous failed updates are common culprits. An update can't create a new directory on a full filesystem no matter how correct the permissions are.
4. Force WordPress to use direct filesystem access
If WordPress is prompting for FTP credentials before it'll update anything, it means it couldn't confirm it has direct write access, even if it technically does. Add this line to wp-config.php, above the /* That's all, stop editing! */ line:
define('FS_METHOD', 'direct');This tells WordPress to skip the FTP handshake and write files directly as the PHP process. It only helps if ownership and permissions are already correct — it won't paper over a real ownership mismatch.
5. Clean up any half-extracted leftovers
Failed updates sometimes leave a partial folder behind, like akismet.tmp or a plugin folder with garbled contents. Delete these manually before retrying:
rm -rf wp-content/plugins/plugin-name.tmp
rm -rf wp-content/upgrade/*
Then retry the update from wp-admin. If it still fails at this point with permissions and ownership confirmed correct, check your PHP handler in WHM's MultiPHP Manager — suPHP or a misconfigured FastCGI setup can add write restrictions that DSO or PHP-FPM don't have.
No SSH access? Do it through cPanel File Manager
Log into cPanel, open File Manager, navigate to public_html/wp-content, and select the plugins folder. Use the Permissions option in the toolbar to confirm it's set to 755, and check the owner column. If File Manager itself throws 403 errors while you try this, that's usually the same underlying ownership issue — open a support ticket and ask for the ownership on wp-content to be reset to your account.
Prevention: Stop It From Coming Back
- Never upload plugin files as root or another account. If a developer needs FTP/SFTP access, create a dedicated FTP account tied to your cPanel user instead of sharing root SSH credentials.
- Set a disk usage alert. In cPanel, keep an eye on your quota from the dashboard, or ask us to enable a usage alert at 80% so you're not caught out mid-update.
- After any migration or restore, run the
chown -Rcommand above once as a matter of routine — ownership mismatches after a backup restore are extremely common and easy to miss until the next update. - Keep the auto-update setting on for security releases once ownership is fixed, so you're not manually triggering large batches of updates that are more likely to hit an edge case.
Frequently Asked Questions
Will this delete my plugin's settings or data?
No. Fixing ownership and permissions doesn't touch the plugin's database tables or settings, only the files on disk. Your configuration stays exactly as it was; you're just letting WordPress write the new version's files into the right place.
Why does this only happen with some plugins and not others?
It usually happens with every plugin once the underlying folder or quota issue exists, but you might only notice it on the ones you update most often, or the biggest ones that create more files during extraction and are more likely to hit an inode or quota ceiling.
I fixed the permissions but it's still asking for FTP credentials. Why?
WordPress falls back to asking for FTP details when it can't verify direct write access programmatically, even if the permissions are technically fine. Adding define('FS_METHOD', 'direct'); to wp-config.php usually resolves this once ownership is correct.
Can I just update via SSH and skip wp-admin entirely?
Yes, if WP-CLI is available on your account. Run wp plugin update --all from the site root. It uses the same filesystem, so it will hit the identical permission or quota issue if that's the underlying cause, but it gives you a clearer error message to work from.
Is this more common on shared hosting than on a VPS?
It's more common on shared cPanel hosting because file ownership is more tightly scoped to your account by design. On an unmanaged VPS, you control the whole filesystem, so the same problem usually traces back to a webserver user (like www-data) not matching the user that originally uploaded the files.
