"No space left on device" stops a server from writing — saves, logs, databases all fail. Usually the disk is genuinely full, but sometimes it's inodes or Docker layers. Here's how to find and fix it, and stop it recurring.
Quick answer
"No space left on device" means the filesystem is full or out of inodes. Check space with df -h and inodes with df -i, find the biggest folders with du -sh /*, then clear old logs, backups and caches — docker system prune if Docker is filling it. If df shows free space but writes fail, look for deleted files still held open with lsof +L1.
The disk is usually genuinely full — but the confusing cases (df shows free space, yet writes still fail) trip people up. Match your situation:
| Symptom | Cause | How to confirm |
|---|---|---|
| df -h shows the disk 100% full | Disk genuinely full | du -sh /* to find the big folders |
| df -h shows free space, but writes fail | Out of inodes (too many tiny files) | df -i shows 100% on that filesystem |
| Space "used" but nothing visibly there | Deleted-but-open files still held | lsof +L1 lists them; restart the holder |
| Only one folder fails | A separate mount/partition is full | df -h and check that mount specifically |
| Fills up fast on a Docker host | Old images/layers/volumes | docker system df, then docker system prune |
Confirm what's full
Check disk usage per filesystem first:
df -h # space used per filesystem
df -i # inode usage (the sneaky one)Find the big folders
Track down what's eating space, largest first:
du -sh /* 2>/dev/null | sort -h
du -sh /home/* /var/log/* | sort -hThe usual culprits
- Log files — runaway logs in
/var/logor a server's logs folder. - Backups — old world/database backups piling up.
- Crash dumps / core files — large hs_err / core files.
- Temp files — leftovers in
/tmpor download caches.
If df -h shows free space but writes still fail, df -i is the answer — you ran out of inodes (too many tiny files). Delete large numbers of small junk files (old cache/session files) to recover.
Free space safely
Delete old logs/backups you don't need, truncate a giant active log rather than deleting it, and set up log rotation so it can't happen again:
truncate -s 0 /path/to/huge.log # empty a live log safely
journalctl --vacuum-size=200M # trim systemd journalsdf -h for space, df -i for inodes, du to find the hog. Clear logs/backups, set up rotation, and you're back.
Docker and quota-specific causes
- Unused Docker images, stopped containers and dangling build layers under
/var/lib/docker/overlay2can silently consume tens of GB —docker system prune(carefully, after reviewing what it will remove) reclaims it. - Some hosting plans enforce a separate storage quota below the actual disk size — if df -h shows plenty of space but writes still fail, see fixing disk quota exceeded.
- Game server auto-save/backup features (world saves, database dumps) can accumulate faster than expected on a busy server — cap how many old backups are kept.
How to prevent it recurring
- Set up log rotation (logrotate) for anything that writes continuously.
- Cap the number of retained backups instead of keeping them forever.
- Monitor disk usage with alerts before it hits 90%+, not after a crash.