Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

The error Unable to create directory wp-content/uploads/2026/10. Is its parent directory writable by the server? means the PHP process handling WordPress cannot create the year/month folder inside the uploads location WordPress resolved. It is usually an ownership or write-access problem, but a stale upload path, relocated wp-content, custom UPLOADS value, or temporary-file problem can point WordPress at a different location than the one you inspected.

Start with the exact path printed in the message. Confirm that path, every parent directory, and the PHP/web-server account that runs WordPress. Correct ownership first, use the narrowest write access that works, then verify WordPress’s path settings and retry with a small image.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What the error actually means

When you upload media, WordPress resolves an uploads directory and normally creates a year/month subdirectory below it, such as /wp-content/uploads/2026/10. The wp_upload_dir() function uses the database upload_path option or WP_CONTENT_DIR/uploads, honors the UPLOADS constant when it is defined, and reports a value in its error key if the path cannot be created.

Therefore, “unable to create directory” is not a diagnosis of one specific chmod value. It says that the effective PHP process could not create the resolved directory, or that the resolved path is not the directory you thought WordPress was using. The WordPress Hosting Handbook also notes that uploads must be web-accessible so browsers can load them and that PHP must be able to write to the uploads folder to handle user uploads.

  • PHP is the relevant account. Your SFTP, FTP, or hosting-panel login may be able to create files even when the PHP worker cannot.
  • Every parent matters. The uploads directory can have a permissive-looking mode while a higher-level directory blocks traversal or creation.
  • Path configuration can redirect the operation. A custom or stale setting may send WordPress to a relative, moved, or symlinked location.
  • Temporary storage is separate. A failure writing PHP’s temporary upload file can occur at the same time as, but is not identical to, an uploads-parent error.

Diagnose in the right order

1. Read and copy the complete path

Do not begin by changing permissions on whichever wp-content/uploads folder you happen to see. Copy the path from the error exactly, including whether it is absolute, relative, symlinked, or outside the WordPress root. Compare it with the site’s actual document root and content directory.

A normal layout is a directory named uploads below wp-content, followed by a four-digit year and a two-digit month. A path containing a different content directory, an old domain-specific folder, a relative segment, or a server filesystem location you do not recognize is a configuration clue. Keep the error text for your host if escalation becomes necessary.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

2. Inspect the directory and every parent

Use the hosting file manager, SFTP, or SSH to inspect the path. Confirm that the intended uploads directory exists. Then inspect each parent from the filesystem root down to the year/month target. The PHP account needs permission to traverse the parents and write in the directory where the new folder is created.

On SSH, commands such as the following display ownership, group, and mode without changing anything:

ls -ld /path/to/site/wp-content
ls -ld /path/to/site/wp-content/uploads
namei -l /path/to/site/wp-content/uploads

Replace the example path with the absolute path shown by your error. In a file manager, look for the same owner, group, and permission information in the directory details panel. A directory can appear to have a reasonable numeric mode yet still belong to a different account from the PHP worker.

3. Perform a controlled write test

If your host provides a safe test facility, ask it to create and remove a temporary directory in the uploads parent using the same PHP handler or pool that serves the site. An SFTP test only proves that your login can write; it does not prove that PHP can. Remove the test directory immediately and never leave an executable test file in a public uploads location.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

When you cannot identify the PHP account or safely run a test as that account, stop before changing ownership. Give the host the path and ask which user and group execute PHP for this site.

Fix ownership and write access safely

Ownership is usually the durable fix

The PHP/web-server worker must be able to write the uploads parent while the site remains isolated from other accounts. If the directory was created by a different user, restored from a backup, copied from another server, or created by a deployment process, the owner or group may no longer match the PHP worker.

Ask the hosting provider to align ownership and group membership for the site’s uploads directory and its required parents. On a server you administer, make the correction according to that server’s PHP-FPM, Apache, or other handler configuration; do not guess a username from another installation. Shared hosting, containers, and separate PHP pools commonly use different service accounts, so a command that is correct on one server can break isolation on another.

Use the least-permissive mode that permits the operation

After ownership is correct, grant only the write access required by the PHP process. Keep files and directories as restrictive as the hosting model allows, and loosen access only on the directory that must accept uploads. The WordPress file-permissions guidance warns that permissions control who can read, write, and modify content and specifically cautions against making files or directories 777.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Leaving an uploads directory at 777 allows every local account, and potentially a compromised process, to write there. An attacker who can upload or modify executable content may gain control of the site and its database credentials. A temporary emergency change, if a host instructs you to make one, should be reverted immediately after the real owner/group problem is corrected; it is not a permanent solution.

Why changing only the mode may not work

Numeric modes do not override an incorrect owner, group membership, filesystem ACL, read-only mount, quota, or hosting isolation rule. If the PHP process is outside the directory’s allowed group, changing a mode bit may have no effect. Conversely, broadening a mode can hide the underlying ownership error and increase exposure. Treat a failed mode change as a reason to inspect the execution account and server policy, not as a reason to keep adding permissions.

Check WordPress path settings

If the filesystem is writable but the error continues, verify that WordPress is testing the path you inspected. The effective location can be changed by several settings:

  • upload_path in the WordPress options database can override the default uploads location.
  • The UPLOADS constant can provide another path and takes precedence when defined.
  • WP_CONTENT_DIR can relocate the entire content directory, including uploads.
  • WP_CONTENT_URL changes the public URL associated with relocated content; it does not by itself grant filesystem write access.

Review these values in the site’s configuration and database using your host’s backup and change-control process. Look for a stale path left by a migration, a relative value that resolves differently under the current document root, a directory that was moved without updating configuration, or a custom constant copied from an old environment.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use absolute filesystem paths that exist on the current server when a custom layout is genuinely required. Remove obsolete custom values rather than adding more constants speculatively. A path correction should point to a directory that is both writable by PHP and reachable by the web server for the resulting media URLs.

Advanced constants: change only when the layout requires it

The wp-config.php handbook documents relocating wp-content with WP_CONTENT_DIR and WP_CONTENT_URL. It also documents FS_CHMOD_DIR and FS_CHMOD_FILE as permission-related constants. These are advanced settings, not a general remedy for an unknown owner or a wrong path. Back up the configuration, make one change at a time, and verify the resulting path before editing additional constants.

Distinguish uploads permissions from temporary-file failures

PHP first receives an uploaded file in a temporary location before WordPress moves it into the media directory. WordPress’s get_temp_dir() selection checks, in order, PHP’s system temporary directory, the PHP upload_tmp_dir, WP_CONTENT_DIR, and finally /tmp, choosing a writable directory. A WP_TEMP_DIR definition can override that selection.

A temporary-directory problem usually produces wording about a temporary file, upload size, or inability to move an uploaded file rather than an explicit “Is its parent directory writable by the server?” message. Nevertheless, check temporary storage when the uploads parent passes a write test but uploads still fail. Confirm that the selected temporary directory exists, is writable by the PHP worker, has available space and quota, and is not mounted read-only.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Do not set WP_TEMP_DIR simply because an uploads error appeared. It changes temporary-file selection and does not make the resolved uploads parent writable. Correct the specific layer identified by the error.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Retry the upload and verify the result

  1. Clear any failed test directory or partial file you created during diagnosis.
  2. In the WordPress dashboard, upload a small image with a simple filename.
  3. Confirm that WordPress creates the expected year/month directory below the configured uploads path.
  4. Open the image from the Media Library and in a private browser window to verify that the file is both stored and web-accessible.
  5. Check the directory owner and mode again if the upload succeeds, especially after an automated deployment or backup restore.

If the directory is created but the browser receives a 403 or 404, the write problem is solved and the remaining issue is URL mapping, web-server access, or a security rule. If WordPress still reports the same path error, compare the path in the new message with the one you inspected; a changed path usually indicates an unresolved configuration override.

When to contact your hosting provider

Escalate when you lack root or hosting-panel access, cannot identify the PHP account, or find that ownership looks correct but the worker still cannot write. Provide evidence instead of asking for “777”:

  • the complete error text and exact filesystem path;
  • the site’s document root and whether wp-content or uploads was moved;
  • current owner, group, and mode for uploads and each parent;
  • the PHP handler type and pool or container, if visible;
  • whether an SFTP test worked and whether a PHP-context write test failed;
  • available disk space, quota, and any read-only or isolation message.

Ask the provider to make the PHP worker able to create year/month directories while preserving isolation from other sites, and to confirm the corrected owner/group and path. Managed WordPress hosting can be a practical option for owners who cannot control PHP ownership, filesystem isolation, or deployment permissions; choose a provider only after checking its current support and security practices.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Compare the possible fixes

Fix What it corrects Scope Security and durability Who usually applies it
Align owner/group with the PHP worker An ownership or group mismatch Uploads and required parent directories Least exposure when narrowly scoped; normally survives routine uploads Site administrator with server access or the host
Adjust directory write access A mode or ACL that blocks the worker The specific directory whose contents must be created Use the narrowest access; broad modes increase risk and can be undone by deployments Site administrator or host
Correct upload_path, UPLOADS, or WP_CONTENT_DIR WordPress resolving an unexpected location Potentially all future uploads or all of wp-content Durable when documented and backed up; a wrong value can break every media URL WordPress administrator and developer, sometimes the host
Set or repair temporary storage PHP’s temporary upload-file location Temporary files, not the final uploads parent Use only when diagnostics identify a temp-directory failure PHP/server administrator
Move to managed hosting Lack of control over PHP users, pools, and filesystem policy Usually the whole hosting environment Can reduce operational burden; verify isolation, backups, and migration support Site owner with the provider

Prevent the error from returning

  • Document the absolute uploads path and any intentional content-directory relocation.
  • Keep wp-config.php and database changes under versioned, reviewable change control.
  • Ensure deployment and backup-restore jobs preserve the intended owner and group instead of recreating directories as an unrelated account.
  • After migrations, test a small media upload as a normal administrator and verify the generated year/month folder.
  • Monitor disk space, inode or file-count limits, and hosting quotas.
  • Keep permissions tight; do not leave the site or uploads at 777.
  • Remove abandoned custom constants and stale database paths once you have confirmed they are no longer needed.
  • Ask the host how PHP-FPM pools, containers, ACLs, and read-only mounts affect this site before changing server permissions.

Quick decision checklist

  1. Is the path unexpected? Inspect upload_path, UPLOADS, and WP_CONTENT_DIR before changing modes.
  2. Does the uploads parent exist? Create it only at the resolved path, then inspect every parent.
  3. Can PHP write there? An SFTP success is not sufficient; test with the PHP worker or ask the host.
  4. Do owner and group match the PHP account? Correct ownership before broadening access.
  5. Is temporary storage implicated? Check get_temp_dir() inputs, quota, and free space only when the symptoms point there.
  6. Does a small image upload create the expected year/month folder? If not, send the host the path, owner/group/mode, handler details, and exact error.