“No space left on device” can mean exhausted disk bytes or exhausted inodes. WordPress, PHP, databases, sessions, caches and logs all need writable space, so a full filesystem can produce several unrelated-looking failures at once.
Measure bytes and inodes before deleting anything
Check every relevant mount, not only the root filesystem. A partition can have free gigabytes and still be unable to create new files because the inode pool is exhausted.
Identify what is growing
- web/PHP/database logs without rotation;
- local backups or failed snapshots;
- cache and temporary directories;
- mail queues or unexpected generated files.
Create a small safe operating margin
Stop or limit non-essential writers, then remove only data you understand to be disposable. Do not delete database files, unknown archives or incident evidence just to recover a few megabytes.
Fix the growth source, not only the symptom
Repair retention, rotation or the application creating the data. If a mail queue is driving growth, compare the WordPress spam-email incident workflow.
Check permissions after space returns
Applications sometimes leave partial files or misleading write errors after a full disk. If the filesystem has space but writes still fail, use the ownership-before-chmod checks.
Exit criteria
Disk and inode use should stay below a documented threshold, WordPress updates/uploads/cache and database writes should work normally, and monitoring should show that the original growth pattern is no longer recurring.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Deleting random files while services continue writing can provide only seconds of relief and remove evidence of the process causing growth.
- 1
Check filesystem bytes and inode usage for every relevant mount.
- 2
Identify the largest recent files, directories and log growth.
- 3
Inspect database, backup, cache, temp and mail-queue locations.
- 4
Record write or corruption errors before restarting services.
What must be verified
- Disk and inode use remain below documented thresholds.
- Database, uploads, cache and updates write normally.
- Monitoring and retention prevent the same growth pattern.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If disk usage looks fine, can the site still fail with a 'no space left on device' error?+
Yes. The error can also come from running out of inodes rather than bytes, so both filesystem bytes and inode usage need to be checked separately across every relevant mount, not just the overall disk percentage.
Is it safe to delete large files immediately to free up space?+
Not randomly. Deleting files while services keep writing can provide only a few seconds of relief and destroys the evidence needed to identify what's actually causing the growth — archive or remove only data you've confirmed is disposable.
Should I delete unfamiliar backup files to recover space during an active issue?+
No, not without understanding what they are, especially if there's any possibility of a security compromise. Removing current database files, unrecognized backups, or evidence during an active incident can eliminate the only path to recovery.
Can malware cause a disk-full error even if no one uploaded unusually large files?+
Yes. Malicious activity or an abused mail queue can generate large numbers of small files or spam messages that accumulate quietly, which is why the mail-queue and unexpected data locations are worth checking alongside logs and backups.