WordPress Installation Failed: Could Not Create Directory - Fix

Installation failed: Could not create directory appears in the WordPress dashboard when you install or update a plugin or theme, and WordPress cannot create the folder it needs on the server. A close relative is "Update failed: Could not create directory" and the media-library variant "Unable to create directory wp-content/uploads/2026/10. Is its parent directory writable by the server?"

The browser-based installer unpacks a ZIP into wp-content/plugins, wp-content/themes or wp-content/upgrade. For that to work, the PHP process must be able to write to those locations, there must be disk space, and no stale folder with the same name should be in the way. The fault is almost always the server's filesystem, not WordPress.

Check quickly in this order

1. Is the disk full or is your quota used up? df -h and df -i (inodes) on a VPS, or check the account quota in your hosting panel. A full disk or exhausted inodes produce exactly this error.
2. Who owns the files, and who does PHP run as?
3. Are the folders writable by that user?
4. Does a leftover folder or partial update already exist?
5. Is another layer (SELinux, chroot, read-only mount) blocking writes?

Step 1: ownership and permissions

Find the PHP user. On many servers it is www-data, apache or nginx, and on shared hosting it is your account user. Then inspect:

ls -ld wp-content wp-content/plugins wp-content/themes wp-content/uploads wp-content/upgrade
ps -eo user,comm | grep -E "php-fpm|apache2|httpd" | sort -u

WordPress's recommended settings are 755 for directories and 644 for files. Ownership should match the user that PHP runs as, or the user that your host expects:

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

If your files are owned by one user (for deployment over SSH) and PHP runs as another, WordPress cannot write directly. It will ask for FTP credentials instead, or fail with this error. Fix ownership, or set the filesystem method below.

Step 2: confirm the parent folder exists

The upgrade folder is created inside wp-content on demand. If wp-content itself is not writable, WordPress cannot create wp-content/upgrade, and installs fail. Create it manually if needed:

mkdir -p wp-content/upgrade wp-content/uploads
chown www-data:www-data wp-content/upgrade wp-content/uploads

Step 3: remove leftovers

A failed earlier install can leave a half-extracted folder. Look in wp-content/plugins or themes for a directory named like the one you are installing, and in wp-content/upgrade for old files. Delete the leftover and try again. Take a backup if you are unsure what a folder contains.

Also check for a maintenance state left over from a failed update; see WordPress stuck in maintenance mode.

Step 4: FS_METHOD and direct file access

WordPress picks a filesystem method (direct, FTP, SSH) by testing whether it can write files it owns. If it detects an owner mismatch, it asks for FTP details. If you know permissions are correct, you can force direct writes in wp-config.php:

define('FS_METHOD', 'direct');

Add it above the "That's all, stop editing" line. Only do this once the folders are truly writable by the PHP user; it does not give PHP permission it does not have.

Step 5: check the temp directory and upload limits

WordPress downloads the ZIP to a temp location first. If PHP's sys_temp_dir or upload_tmp_dir is missing or unwritable, installs fail. Check phpinfo() for these and test:

sudo -u www-data touch /tmp/test && echo ok

Also review upload_max_filesize and post_max_size when uploading a ZIP manually (see WordPress upload exceeds upload_max_filesize), and memory_limit if unpacking runs out of memory (WordPress memory limit fix).

Step 6: SELinux, containers, and read-only mounts

• SELinux on RHEL-family servers can deny writes even with correct modes. Label the directories httpd_sys_rw_content_t; the commands are in PHP failed to open stream: Permission denied.
• Docker: the bind-mounted wp-content is owned by the host user ID; align it with the container's www-data UID.
• Read-only mounts or immutable deployments: some managed hosts mount code read-only and expect updates through Git or a dashboard. Check your host's docs.

Step 7: install manually if you must

Download the plugin ZIP, extract it locally, and upload the folder by SFTP to wp-content/plugins/. Then activate it from the dashboard. This bypasses the writable-directory check but not the underlying problem, so you will see the error again at the next update.

Verify

Retry the install, then check the front end and admin respond normally with the HTTP Status Checker. Run the Website Health Check and WordPress's own Site Health screen (Tools, Site Health), which reports file system permission problems. An Uptime Monitor confirms nothing broke after the permission changes.

Next steps

• Read WordPress critical error on this website if an update leaves the site broken.
• See WordPress updating failed: not a valid JSON response.
• Review WordPress white screen of death.
• Troubleshoot with WordPress plugin conflict troubleshooting.

FAQ

Why does WordPress ask for FTP credentials?

Because PHP cannot write files directly. It detected that the files belong to a different user than the web process. Fix ownership instead of storing FTP details.

Is it safe to chmod 777 to get past it?

No. It is a common cause of hacked sites. Use 755 and 644 with correct ownership.

What if the disk has plenty of space?

Check inodes with df -i, the hosting quota, and the temp directory. Any of them can block writes.

Does the same fix apply to uploads?

Yes. The uploads folder needs the same ownership and write permission for the PHP user.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.