Upload: Failed to Write File to Disk
WordPress received the file and could not save it. The upload itself worked, so the problem is on the server side and is almost always one of four things.
The short version
- Check free disk space first. It takes five seconds and is a common cause.
- Then the uploads directory permissions and ownership.
- Then whether PHP has a usable temporary directory.
- Then the inode limit, which is the one nobody checks.
1. Disk space
df -h .
# or in the host panel, look at disk usageA full disk produces exactly this error. The usual consumers are backups stored on the server, old cache files, and log files nobody rotated.
# the biggest directories
du -sh * | sort -h | tail -10
# anything large in wp-content
du -sh wp-content/* | sort -h | tail2. Permissions and ownership
The uploads directory must be writable by the user PHP runs as:
ls -la wp-content/ | grep uploads
# should be drwxr-xr-x and owned by the web server user
chmod 755 wp-content/uploads
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;Watch out
If this only works when you set 777, the real problem is file ownership, not permissions. Ask your host to correct ownership. Leaving uploads at 777 on shared hosting means any account on that server can write to your site.
3. The temporary directory
PHP writes uploads to a temp directory before WordPress moves them. If that directory is missing or not writable, the move fails. Check what PHP is using:
<?php echo sys_get_temp_dir(); ?>If it is wrong or unwritable, point WordPress at a directory you control:
// wp-config.php
define( 'WP_TEMP_DIR', ABSPATH . 'wp-content/temp/' );
// then create that directory, 755, correct ownership4. Inode limit
An inode is one file or directory. Shared hosts cap the count, and a site with a large media library plus a cache plugin generating a file per page can reach it while still having plenty of disk space free. The symptom is identical.
df -i .
find . -type f | wc -l
# where the files are
for d in wp-content/*/; do echo "$(find "$d" -type f | wc -l) $d"; done | sort -rnThe usual answers are clearing the cache directory, removing on-server backups, and unregistering image sizes you do not use.
Which one is it?
| Clue | Cause |
|---|---|
| Started suddenly, nothing changed | Disk full or inode limit |
| Started after a migration | Permissions or ownership |
| Only large files fail | PHP upload limits, not this error |
| Every file fails including tiny ones | Permissions or temp directory |
| Disk shows free space but it still fails | Inodes |
Preventing it
- Store backups off-server, not in wp-content.
- Rotate or disable debug logs.
- Unregister image sizes you do not use, then regenerate thumbnails.
- Set a cache lifetime so cached files are cleared rather than accumulating.
- Monitor both disk usage and inode count, not just disk.
Common questions
Why do some uploads work and others fail?
If only large files fail you are looking at upload_max_filesize or post_max_size, which produce a different error. This one usually affects everything.
Can I just set 777?
It will work and it is a real security risk on shared hosting. Fix ownership instead.
The host says there is plenty of space
Ask specifically about the inode count. It is a separate limit and support often does not mention it unprompted.
Sumit
Writes everything on TechMozz.