How to Fix “Could Not Create Directory” in WordPress

Short answer: “Could not create directory” means WordPress isn’t allowed to write inside wp-content. Either the folder belongs to a different user than the one PHP runs as, its permissions don’t allow writing, or the account is out of disk space or files (inodes). Open Tools → Site Health → Info → Filesystem Permissions to see which folder is the problem, set folders to 755 and files to 644 owned by your hosting user, free some space, and try again. If your dashboard also says “An automated WordPress update has failed to complete”, delete the .maintenance file in your site’s main folder and run the update again.

Written November 2026 for WordPress 7.1. The checks below are the same on any version since 6.3.

Why I ran into it

When I brought this site back to life, every plugin install on the old host failed with Installation failed: Could not create directory. The odd part: Site Health said every folder was writable. That rules out plain permissions and points to the other causes below, a full disk or file quota, or a leftover folder in wp-content/upgrade. Checking either takes two minutes in the hosting control panel, but that host’s cPanel kept sending me back to a password-change screen, so I couldn’t look. I ended up moving the whole site with nothing but wp-admin, which I wrote up in how to migrate WordPress without cPanel. On the new host, the same plugins installed on the first try. That is the typical pattern: this error is almost never a bug in WordPress or in the plugin, it’s the server saying no.

Which message do you see?

The wording tells you what WordPress was trying to write, which tells you where to look.

Message	When	Folder WordPress needs to write to
Installation failed: Could not create directory.	Installing a plugin or theme	wp-content/upgrade, then wp-content/plugins or themes
Update failed: Could not create directory.	Updating a plugin or theme	Same as above
Could not create the upgrade-temp-backup directory.	Any plugin or theme update (WordPress 6.3+)	wp-content/upgrade-temp-backup, where WordPress keeps the old version so it can roll back
Could not create directory.	Updating WordPress itself	wp-content/upgrade and the main WordPress folder
Unable to create directory wp-content/uploads/2026/11. Is its parent directory writable by the server?	Uploading media	wp-content/uploads
Download failed. Destination directory for file streaming does not exist or is not writable.	Any install or update	The temporary folder (PHP’s temp directory or WP_TEMP_DIR)

If WordPress shows a Connection Information form asking for FTP details instead of installing, that’s the same problem in disguise. WordPress creates a test file, and when the test file’s owner doesn’t match the owner of WordPress’s own files, it falls back to asking for FTP.

Step 1: Find the folder in Site Health

Go to Tools → Site Health → Info and open Filesystem Permissions at the bottom. WordPress checks each folder from the inside, as the user PHP runs as, which is exactly what matters. This is what it shows on this site today:

Folder	danialtv.com
The main WordPress directory	Writable
The wp-content directory	Writable
The uploads directory	Writable
The plugins directory	Writable
The themes directory	Writable
The fonts directory	Does not exist

Any Not writable line points to the folder to fix. Does not exist for fonts is normal: WordPress creates it the first time you install a font from the Font Library. Also look at the Status tab: since WordPress 6.3 it warns when the upgrade-temp-backup folder isn’t writable or when there’s too little disk space for updates.

If every folder says Writable and installs still fail, skip to steps 3 and 4: the problem is space or a leftover folder, not permissions.

Step 2: Fix permissions and ownership

The WordPress handbook recommends 755 for folders and 644 for files. Just as important is who owns them. Permissions say what the owner may do; if the owner is someone else, PHP is treated as a stranger. This happens after a migration, when files were uploaded as root or by a different FTP user, or when a backup was restored by the host.

In cPanel

1. Open File Manager and go to your site’s folder (public_html, or the folder of an addon domain).
2. Right-click wp-content → Change Permissions → tick Read, Write and Execute for User, and Read and Execute for Group and World. That is 755.
3. Do the same for wp-content/plugins, themes, uploads and upgrade if it exists.
4. Check the Owner column if your File Manager shows it. Everything should belong to your cPanel username. If you see root or nobody, you can’t change it yourself; send your host a ticket asking them to “reset ownership of my WordPress files to my account user”.

With SSH (VPS or dedicated server)

Run these from the WordPress folder. Replace www-data with the user PHP runs as on your server (often www-data on Ubuntu with Nginx or Apache, nginx or apache on other systems, or your own user with PHP-FPM pools).

sudo chown -R www-data:www-data wp-content
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

Don’t use 777. It makes every folder writable by every account on the server, and on hosts that run PHP through suPHP it doesn’t even work: the server refuses to run scripts from world-writable folders and returns error 500. If 777 “fixed” it for you, the real problem is ownership.

Step 3: Check disk space and file count

A full account gives the same error, because creating a folder needs both a little space and a free inode (every file and folder uses one). Shared plans often limit inodes to a few hundred thousand, and old backups, cache folders and image thumbnails eat them fast.

• cPanel: the sidebar on the home page shows Disk Usage and File Usage. Anything near 100% is your answer.
• SSH: df -h for space, df -i for inodes, and du -sh wp-content/* to see what’s big.
• Usual suspects: backup plugin folders inside wp-content, old cache folders, and error_log files that grew to gigabytes.

Step 4: Clear leftover upgrade folders

An interrupted update can leave a half-written folder behind in wp-content/upgrade or wp-content/upgrade-temp-backup, sometimes with the wrong owner, and the next update can’t replace it. When no update is running, the contents of both folders are safe to delete. Keep the folders themselves, or delete them too and WordPress recreates them.

Step 5: Temp folder, FS_METHOD and other settings

• Temp folder. If you get the “file streaming” message, PHP’s temporary folder isn’t writable. Give WordPress its own by adding this to wp-config.php, above the line that says “That’s all, stop editing”, and creating the folder: define( 'WP_TEMP_DIR', __DIR__ . '/wp-content/temp/' );
• FS_METHOD. Many guides tell you to add define( 'FS_METHOD', 'direct' );. It only removes the FTP form; it doesn’t give PHP permission to write. Use it only after ownership is right, or you’ll swap the FTP form for “Could not create directory”.
• Install buttons missing completely? That’s a different cause: DISALLOW_FILE_MODS is set to true in wp-config.php, by you, your host or a security plugin.
• Still failing with everything writable? Some hosts restrict PHP with open_basedir or a security module. That needs the host: send them the exact message and the folder from the table above.

“An automated WordPress update has failed to complete”

This yellow notice at the top of the dashboard often comes right after the error above: WordPress tried to update itself in the background, couldn’t write the files, and stopped halfway. Reading the code that shows the notice, it appears in exactly two situations:

1. A .maintenance file is still in the main WordPress folder. WordPress creates it at the start of every update and deletes it at the end. If the update dies in between, it stays. For the first 10 minutes visitors see “Briefly unavailable for scheduled maintenance”; after 10 minutes WordPress ignores the file and the site works again, but the dashboard keeps showing the notice for as long as the file exists. That’s why so many people see the notice on a site that looks fine.
2. The failure was recorded. WordPress saves failed background updates in the auto_core_update_failed option and keeps nagging while you’re on an older version than the one it tried to install, or on the same version if the failure happened while files were being copied. A successful update clears it.

How to fix it

1. Delete .maintenance. In cPanel File Manager, open Settings (top right) and tick Show Hidden Files, otherwise you won’t see it. It sits next to wp-config.php. Over FTP, enable hidden files in your client.
2. Fix the cause. Run through steps 1 to 4 above. If WordPress still can’t write, the next update will fail the same way.
3. Run the update again from Dashboard → Updates. If you’re already on the latest version, use Re-install version … to make sure every file was copied.
4. “Another update is currently in progress”? WordPress holds an update lock for up to 15 minutes. Wait, then try again. If it never goes away, delete the core_updater.lock row from the wp_options table in phpMyAdmin, or run wp option delete core_updater.lock with WP-CLI. Take a database backup first.
5. Dashboard broken after a half-finished update? Download the same WordPress version from wordpress.org and upload only the wp-admin and wp-includes folders and the files in the main folder, overwriting the old ones. Never overwrite wp-content or wp-config.php.

Quick checklist

What you see	Most likely cause	Fix
Not writable in Site Health	Permissions or owner	755 / 644, owner = your hosting user
Everything writable, installs still fail	Disk or inode limit, leftover folder	Free space; empty wp-content/upgrade
FTP credentials form	Owner mismatch	Fix ownership, not FS_METHOD
“file streaming” error	Temp folder	WP_TEMP_DIR
Update-failed notice, site works	Old .maintenance file	Delete it, update again
Another update in progress	Update lock	Wait 15 minutes, then delete core_updater.lock
No install buttons	DISALLOW_FILE_MODS	Remove it from wp-config.php if you set it

FAQ

Is it safe to delete the .maintenance file?

Yes, as long as no update is running right now. If you just clicked Update, wait a few minutes first. The file contains only a timestamp; deleting it doesn’t undo or break anything.

Can I just install the plugin manually?

You can upload the unzipped plugin folder to wp-content/plugins by FTP or File Manager, and it will show up under Plugins. But WordPress still won’t be able to update it, and automatic security updates will fail too. Fix the permissions so updates keep working.

Why did it start after I changed hosts?

Because the files were copied by a different user than the one that runs PHP on the new server: a migration tool running as root, or an FTP account. The files look normal in the File Manager but belong to someone else. Ask the host to reset ownership, or run the chown command from step 2.

Sources: WordPress Developer Resources, maintenance_nag() and wp_is_maintenance_mode(); Rollback for failed plugin and theme updates in 6.3; Changing File Permissions.