How to Fix the “Parent Directory Writable by the Server” WordPress Error

The message “Is its parent directory writable by the server?” means WordPress cannot create a file or folder in its uploads location. Confirm that wp-content/uploads exists, correct the uploads path, then set the uploads directories to 755 and files to 644. On a VPS, make sure the PHP/web-server account owns the folder; on shared hosting, preserve your hosting account’s ownership and ask the host to correct server restrictions if needed.

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

What the error means

WordPress creates folders and files whenever you upload an image, add other media, install a theme or plugin, or apply an automatic update. A typical failure reads:

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

• Is its parent directory writable by the server?
• Unable to create directory wp-content/uploads/YYYY/MM
• Unable to create directory uploads/2022/10. Is its parent directory writable by

The year-and-month path is normal: WordPress commonly organizes uploads below wp-content/uploads in folders such as 2022/10. The error does not necessarily mean that the final year/month folder is damaged. It means the PHP process handling WordPress was refused permission to create that folder or write a file somewhere above it.

There are five practical causes, and they are best checked in this order:

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

1. The uploads directory is missing.
2. WordPress is pointing at an old or incorrect uploads path, often after a migration.
3. Directory or file permissions are too restrictive.
4. The directory is owned by a user different from the account running PHP.
5. A server limit, such as open_basedir, a full disk, or exhausted inodes, is blocking writes.

Start with the least invasive checks. Do not recursively change your entire wp-content tree before you know which condition is actually failing.

Prepare before changing paths or permissions

Back up the site

Make a current backup of the database and files before changing ownership, permissions, or configuration. Keep a copy outside the web root or in your host’s backup system. A permissions mistake can make the dashboard or other site functions inaccessible, while an incorrect path can make existing media appear to be missing even though the files are still on disk.

Identify your hosting setup

Your available fix depends on whether you control the server:

Do not assume that a username from another server applies to yours. A command that is correct for one VPS can lock you out of another, and shared hosts may deliberately prevent customers from changing ownership.

Check available storage first

A full filesystem can produce the same symptom as a permissions problem. On a Linux server where you have SSH access, check both space and inodes:

df -h
df -i

df -h reports storage capacity; df -i reports inodes, the filesystem entries required for each file and directory. If either is exhausted, remove or expand storage according to your host’s procedures before changing WordPress permissions. On shared hosting, the control panel may show a quota or inode counter; otherwise ask support to verify it.

Step 1: Confirm that the uploads folder exists

A migration or server move can leave WordPress configured for an uploads path that was never copied to the new account. In your host’s file manager, open the WordPress installation and look for:

wp-content/uploads

If the directory is absent, create uploads inside wp-content. Preserve any existing media files; do not create a second folder with a similar spelling or capitalization. Then retry the upload that failed.

With SSH access, create the directory only if it is missing:

mkdir -p /path/to/wordpress/wp-content/uploads

Replace /path/to/wordpress with the real document-root path. The command does not copy old media, so a moved site may still need its previous uploads directory restored from a backup.

If the folder exists but WordPress still reports that it cannot create YYYY/MM, continue to the path check rather than repeatedly creating year and month folders by hand. WordPress should be able to create those subdirectories itself once the parent path and access rights are correct.

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

Step 2: Correct the uploads path

Use Settings > Media when the field is available

In the WordPress dashboard, open Settings > Media. Older and some customized installations show a field labelled Store uploads in this folder. Set it to:

wp-content/uploads

Save the setting, then try a small media upload. Use a path relative to the WordPress installation unless your host’s documentation specifically requires an absolute filesystem path. An old absolute path from the previous server is a common migration failure.

Some current WordPress installations do not display this field. If it is absent, do not add a random value to the database. Check the configuration file and your host’s migration instructions instead.

Check wp-config.php for an override

An installation can define the uploads directory in wp-config.php. A common form is:

define( 'UPLOADS', 'wp-content/uploads' );

Only add this definition if your installation needs it and does not already define UPLOADS. If a definition points to an old server path, correct it or remove the override so WordPress can use the intended wp-content/uploads location. Make a backup of the file first, keep the statement above the line that says WordPress stops editing the file, and avoid leaving two conflicting UPLOADS definitions.

After changing the path, verify that the directory named by the setting is the directory containing your existing media. Correcting the setting alone does not move files from an old location. If the files remain elsewhere, restore or move them carefully and retain a backup.

Step 3: Set narrow, standard permissions

Once the path is correct, check permissions on wp-content/uploads and its contents. The usual starting point is:

These modes are a starting point, not a reason to make every WordPress file writable. Begin with the uploads directory rather than recursively changing all of wp-content. The WordPress Codex guidance emphasizes trying a narrow correction first and expanding it only if the narrow fix fails.

Using a hosting file manager

Select wp-content/uploads, open the permissions or file-properties dialog, and set the directory to 755 if your host presents numeric modes. Apply directory permissions to subdirectories and file permissions to files separately when the interface supports that distinction. Save, then test a new upload.

If the panel uses checkboxes instead of numbers, the directory needs read, write and execute for the owner, and read and execute for group and everyone. A file needs read and write for the owner, and read for group and everyone. Do not enable the write checkbox for everyone merely to make the error disappear.

Using SSH

Run these commands from the WordPress installation or use the full path:

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

find /path/to/wordpress/wp-content/uploads -type d -exec chmod 755 {} ;
find /path/to/wordpress/wp-content/uploads -type f -exec chmod 644 {} ;

The first command applies 755 to directories, and the second applies 644 to files. If the uploads directory itself does not yet have the expected mode, the first command includes it. Use the real path and an account authorized to change those entries.

Do not jump straight to chmod -R 777. It grants write access broadly and can expose uploaded content to unwanted modification. Even if it appears to solve the immediate message, it creates a separate security problem and can hide the underlying ownership or server-limit issue.

Step 4: Correct ownership on a VPS or dedicated server

Permissions are evaluated together with ownership. A directory set to 755 is writable only by its owner. If the uploads folder belongs to a different account from the one running PHP, WordPress can still be denied.

On many Ubuntu configurations the web account is www-data; other systems use apache or nginx. Confirm the actual PHP/web-server user from your server configuration or host documentation before changing ownership. Then, for example:

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

Replace www-data:www-data with the correct user and group. The recursive ownership command affects every existing upload below that directory, so check the path twice before pressing Enter. It requires appropriate administrative privileges.

Ownership rules differ on shared hosting. The Codex guidance for that environment generally keeps files owned by your hosting account rather than changing them to the web-server user. If you cannot identify the account that runs PHP, ask the host to correct ownership instead of guessing.

Step 5: Check server restrictions and quotas

open_basedir restrictions

PHP can be configured with open_basedir, which restricts the directories scripts may access. If the uploads path is outside the permitted list, changing its mode or owner will not help. A host may expose this setting in a PHP information page or control panel; otherwise support can confirm whether the configured WordPress path is allowed.

Disk quotas and inode limits

Shared plans can impose storage or inode quotas even when the underlying server has free capacity. An account at its quota may fail to create a tiny year/month directory and report the same parent-directory message. Ask the host to check both limits, not just available gigabytes.

Server security policies

Mandatory security policies, container boundaries, or a PHP process running under an unexpected account can also prevent writes. These conditions are controlled by the host. Provide the exact error text, the affected path, the time of the failure, and the results of your folder, path and quota checks when opening a support ticket.

Why 777 is a poor first fix

Search results and older hosting instructions sometimes suggest trying 775 and then 777. WordPress Codex pages also contain conflicting historical guidance: one discussion says an uploads directory may need 755 or higher, while another advises that directories should not be given 777 and explains that PHP can write to a 755 directory it owns. These recommendations reflect different hosting and process models, not a universal requirement.

Use the safer sequence: verify the path, set directories to 755, set files to 644, and correct ownership for the account running PHP. If a host explicitly requires a different mode, obtain that requirement from the host and understand the security trade-off. Treat 777 only as a host-directed last-resort diagnostic, never as a permanent default. If you temporarily test it, restore a restrictive mode immediately and continue looking for the ownership or server-policy cause.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

On shared hosts using suEXEC-style separation, the Codex guidance cited for that environment recommends still more restrictive file settings in some cases: 644 or 640 for files and 440 or 400 for wp-config.php. Your host’s documented PHP handler takes precedence because the correct mode depends on how that server executes PHP.

Hosting-specific repair paths

Shared hosting without shell access

1. Open the file manager and confirm that the WordPress installation contains wp-content/uploads.
2. Use Settings > Media to correct the uploads path if the field is available.
3. Set the uploads directory to 755 and files below it to 644 where the panel permits it.
4. Check the account’s storage and inode quota.
5. Contact support if the path is correct and the quota is available. Ask them to verify ownership, PHP’s open_basedir value, and the user under which PHP runs.

Do not attempt to change ownership to www-data or another server user through a panel unless the host explicitly instructs you to do so. On many shared accounts, that would be incorrect or impossible.

VPS or dedicated server with SSH

1. Back up the site and identify the actual document-root path.
2. Run df -h and df -i to rule out capacity and inode exhaustion.
3. Confirm that wp-content/uploads exists; create it with mkdir -p only when necessary.
4. Inspect the WordPress media setting and any UPLOADS definition for a stale migration path.
5. Set ownership to the account that executes PHP, then apply 755 to directories and 644 to files under uploads.
6. Retry the upload and inspect the web-server or PHP error log if it still fails.

If the log points to open_basedir, a container restriction, or a quota, changing Unix modes will not resolve it; adjust the server configuration or involve the host.

Diagnose the result of each attempt

The folder was missing

If creating wp-content/uploads immediately restores uploads, verify that the directory has the intended mode and ownership before leaving it in production. A missing folder after migration can recur if the deployment process omits empty directories, so include the path in future backups or deployment checks.

The path was wrong

If correcting Settings > Media or wp-config.php fixes new uploads but old images remain broken, the files are probably still in the former location. Restore the old uploads tree or move it to the configured location, then check the site’s existing media URLs. Do not delete the old directory until you have confirmed that the files are present at the path WordPress now uses.

Permissions fixed uploads but not updates

If media uploads work but a theme or plugin update still fails, the update may need write access to another specific directory. Check the error’s exact path and apply the same narrow path-and-ownership analysis there. Avoid making all of wp-content writable by everyone. The Codex notes that some plugins may need wp-content writable, but that is a separate requirement to verify rather than a reason to use broad 777 permissions.

Nothing changed

If the message remains after the folder, path, permissions and ownership are correct, stop escalating modes blindly. Check disk and inode usage, then ask the host about open_basedir, quota enforcement, PHP-FPM or web-server user configuration, and any security policy blocking the path. Include the exact attempted path, such as wp-content/uploads/2022/10, so support can trace the refusal.

Verify the repair safely

1. Log out and back into the WordPress dashboard if the path or configuration was changed.
2. Upload a small image with a new filename.
3. Confirm that WordPress creates the expected year/month directory under wp-content/uploads.
4. Open the attachment in the Media Library and load its public URL.
5. If the original failure involved an update, perform the relevant update only after the media test succeeds, and keep the backup until it completes.

A successful upload proves that WordPress can write to the uploads path; it does not prove that every plugin directory or update operation has the same requirements. Test the operation that originally failed.

Prevent the error after a migration

• Copy the complete wp-content/uploads tree, including year/month subdirectories, rather than copying only the database.
• Review the media path after changing domains, document roots, or server accounts.
• Record the PHP/web-server account and the permission policy used on the new server.
• Check storage and inode quotas before a large media import.
• Keep the uploads directory at the narrowest permissions that your host supports; do not leave it at 777.
• After deployment, test one media upload and one operation that writes files before declaring the migration complete.

Quick decision checklist

• “Unable to create directory” immediately after moving hosts: check that wp-content/uploads exists and that the configured path is not the old server path.
• Folder exists but uploads fail: set directories to 755 and files to 644, then verify ownership.
• VPS with correct modes but failure persists: set ownership to the actual PHP account and inspect logs.
• Shared hosting with no ownership controls: keep account ownership, check quota, and ask the host to verify PHP restrictions.
• Tempted to use 777: stop and treat it as a last-resort, host-directed diagnostic rather than a fix.

Frequently asked questions

Does this error mean WordPress is broken?

No. It normally indicates that the server refused a filesystem write. WordPress can continue running while media uploads, installations, or updates fail until the path, permissions, ownership, or server limits are corrected.

Should I change the whole wp-content folder to 777?

No. Start with the specific uploads directory, use 755 for directories and 644 for files, and investigate ownership or host restrictions if that does not work.

Why did the error appear after a site move?

A move can leave the uploads directory absent, preserve an old absolute path, or assign ownership to a different server account. Check all three before changing broader permissions.

When should I contact my host?

Contact the host when you cannot change ownership, when quotas or inodes may be exhausted, when open_basedir blocks the configured path, or when the standard path and permission checks do not restore writing.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.