Fix WordPress Unable to Create Directory Upload Errors

If WordPress shows “Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?� when you upload images or media, the fix is correcting the folder permissions or ownership on your server. This error almost always means the web server process cannot write to the uploads folder, and you can resolve it in a few minutes using an FTP client or your hosting control panel.

Why This Error Happens

WordPress stores all images, PDFs, and other media in the wp-content/uploads directory. When you upload a file, the PHP process (running as the web server user, often www-data or nobody) needs permission to create subfolders (like 2025/05) and write files inside them. The error appears when that user lacks write access.

The most common causes are:

• Folder permissions set too restrictive (e.g., 755 instead of 755 with wrong owner, or 644 on directories).
• The uploads folder is owned by a different user (e.g., your FTP account) than the web server user.
• A security plugin or server configuration (like SELinux) is blocking writes.
• The uploads directory doesn’t exist or was moved incorrectly.

Quick Fix: Set Correct Permissions via FTP

The standard fix is to set the wp-content/uploads directory to 755 and all files inside to 644. Here’s how:

1. Connect to your site using an FTP client (like FileZilla) or your hosting file manager.
2. Navigate to wp-content and find the uploads folder.
3. Right-click the uploads folder and select “File permissions� (or “Permissions�).
4. Set the numeric value to 755 and check “Recurse into subdirectories� if available. Apply to directories only.
5. After that, select all files inside uploads (but not the subfolders themselves) and set them to 644.
6. Try uploading an image again.

If you don’t see the option to recurse, you can also use your hosting control panel’s file manager, which often has a “Change permissions� button.

What If 755 Doesn’t Work? Try 775 or 777

Sometimes the web server runs under a different user than the FTP user. In that case, 755 (owner read/write/execute, group read/execute, others read/execute) may still not allow the server to write. Try 775 (adds group write) or temporarily 777 (world-writable) to test. Important: 777 is a security risk and should only be used for a quick test. If 777 works, you need to fix the ownership properly (see below) rather than leaving it at 777.

Fixing Folder Ownership (The Real Solution)

Permissions are only half the story. The owner of the uploads folder matters just as much. If your FTP user is john and the web server runs as www-data, even 777 might not help if the server user is blocked by other means, but generally 777 works. The proper fix is to change ownership so the web server user owns the files.

• If you have SSH access: Run chown -R www-data:www-data wp-content/uploads (replace www-data with your server’s web user, e.g., nginx or apache).
• If you don’t have SSH: Many shared hosts let you set ownership via the file manager, but often you can’t change to the server user. In that case, ask your host to fix it, or use a plugin like “File Manager� (but that also runs as the server user, so it might work).

After changing ownership, set permissions to 755 for directories and 644 for files. This is the recommended secure setup.

When the Error Is Not About Permissions

If permissions and ownership are correct but the error persists, check these:

• Disk space: If the server is out of disk space, WordPress may fail to create directories. Check your hosting control panel or run df -h.
• SELinux (on CentOS/RHEL): SELinux can block PHP from writing to certain directories. If you have root access, try chcon -R -t httpd_sys_rw_content_t wp-content/uploads or temporarily disable SELinux to test.
• Security plugins: Some plugins like Wordfence or iThemes Security may have file change detection that interferes. Temporarily disable them and test.
• Corrupted .htaccess: Rare, but a bad .htaccess in wp-content can cause issues. Rename it to .htaccess.bak and test.

Preventing Future Errors

To avoid this error after fixing it, adopt these habits:

• Never use 777 permissions permanently.
• Keep your uploads folder organized; the default year/month structure is fine.
• If you migrate hosts, always re-upload the uploads folder with an FTP client that preserves permissions.
• Consider using a plugin like “Enable Media Replace� that doesn’t create new directories, but that’s not a fix for the underlying issue.

Frequently Asked Questions

Why does WordPress need write permission on uploads?

WordPress creates subdirectories by year and month (e.g., 2025/05) to organize media. It also writes image thumbnails and original files. Without write permission, it cannot create those folders or save files, hence the error.

Is it safe to use 777 permissions?

No. 777 means any user on the server can read, write, and execute files. That could allow a hacker to upload malicious scripts. Use it only as a temporary diagnostic step and switch to 755 or 775 with correct ownership as soon as possible.

What if I don’t have FTP access?

Most hosts provide a file manager in the control panel (cPanel, Plesk, etc.). You can change permissions there. If not, contact your host’s support and ask them to set the correct permissions and ownership for the uploads folder.

Can I fix this from the WordPress admin dashboard?

Not directly, because the error prevents file operations. However, you can install a file manager plugin via the plugin installer (which uses a different path) and then use that plugin to change permissions. But it’s easier to use FTP or your host’s file manager.

Why does this happen after moving to a new host?

When you move a site, the file ownership often changes to your new account’s user, which may differ from the web server user. Also, some hosts set stricter default permissions. Re-applying the correct ownership and permissions fixes it.

Does this error affect plugin or theme uploads too?

Yes, the same error can appear when installing plugins or themes, because those also write to wp-content directories. The fix is the same: ensure wp-content and its subdirectories are writable by the server, but be careful not to leave wp-content itself at 777; set it to 755 and only give write access to the server user.

Related

• Prehistoric Farm Tier List: Best Dinosaurs Ranked
• AI Answer Replay Check Errors: Do Replies Stay in History?
• PostgreSQL Beginner’s Guide: Getting Started with Database Management