Fixing the Unable to Create Uploads Directory Error

WordPress tried to create a folder under uploads and could not — either because the folder is not writable, or because the path it tried is on a server you no longer use. "Unable to create directory wp-content/uploads/2026/10. Is its parent directory writable by the server?" names the folder. Before touching permissions, check whether the folder it names is even on this machine.

Step 1: check the upload path option

After a migration or a move between accounts on the same host, the upload_path option can hold an absolute path from the old environment. WordPress uses it verbatim.

wp option get upload_path
wp option get upload_url_path

Both should be empty on a normal site, or upload_path may hold the old default wp-content/uploads, which is harmless. A value like /home/olduser/public_html/wp-content/uploads means every upload is being attempted on a path that does not exist here, and no permission change on the real folder helps. Clear them:

wp option delete upload_path
wp option delete upload_url_path

Without WP-CLI, the same two rows are in the wp_options table, and the fields appear in Settings › Media only when they already have a value. This is the most common cause after migrating a site, and the error message gives it away in a subtle way: WordPress prints only the folder's base name when the path is outside the install, so the message reads Unable to create directory uploads/2026/10 — without the wp-content/ prefix a normal site shows.

Step 2: ownership

If the path is right, the folder is not writable by the user PHP runs as. The folder's owner and PHP's user must match:

ls -ld wp-content wp-content/uploads
ps aux | grep -E 'php-fpm|apache2|httpd|nginx' | head -3

Fix the owner, not the mode:

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

Substitute the user PHP actually runs as. On shared hosting that is normally your own account and the folder is already owned correctly, which pushes the diagnosis back to step 1 or forward to step 3. A folder uploaded over SFTP as a different user, or restored from a backup as root, is the usual way ownership goes wrong.

Step 3: the folder does not exist

A fresh install on a locked-down wp-content may have no uploads folder at all, and WordPress cannot create it if wp-content itself is not writable. Create it by hand with the right owner:

mkdir -p wp-content/uploads
chown www-data:www-data wp-content/uploads
chmod 755 wp-content/uploads

WordPress creates the year and month subfolders itself once the parent is writable.

Step 4: disk and quota

A mkdir fails on a full disk or an exhausted inode quota as readily as on a permission problem, and the message is the same. df -h and df -i on the site's partition, or the hosting panel's disk usage, settle it. Caches and logs are the usual culprits when a site that worked yesterday fails today.

Step 5: open_basedir and symlinks

If wp-content/uploads is a symlink to shared storage — common on multi-server setups — PHP's open_basedir may not include the target, and the write is refused with a log entry naming the restriction. The fix is in the PHP configuration, adding the real path to the allowed list.

After the fix

Existing media is unaffected by any of this; the error only blocked new uploads. If images are also missing from the site, that is a separate problem with its own causes in images not showing, and a stale upload_url_path is one of them — which is why step 1 clears both options. The same ownership principles apply to plugin and theme installs, where the message is could not create directory instead.

Verify

• Upload a small image from Media › Add New: it succeeds and appears in the library.
• Check the file landed under the site's own wp-content/uploads/<year>/<month>/, not somewhere else.
• The new folder and file are owned by the PHP user, so next month's folder will be created without help.
• Settings › Media shows no custom path fields.