A full disk breaks things in confusing ways: services crash and databases stop accepting writes. Work through this guide from top to bottom; most cases are solved in ten minutes.
1. Confirm what is actually full
$ df -h $ df -i
df -h shows the used space per filesystem; the problem is almost always /. df -i shows inodes. If space looks fine but inodes are at 100%, the cause is millions of tiny files (often a mail queue or session folder). The fix is deleting many small files, not finding one big file.
2. Find the biggest directories
du works everywhere with no install:
$ du -xh -d1 / 2>/dev/null | sort -rh | head -15Go into the biggest folder and run the command again (du -xh -d1 /var ...). The -x flag stays on one filesystem, so mounted volumes do not distort the numbers. For an interactive view, install ncdu:
$ sudo apt install -y ncdu$ sudo dnf install -y ncduThen run sudo ncdu -x / and navigate with the arrow keys.
3. Clear the usual suspects
These steps are safe on any server, and they cover most full disks we see.
The systemd journal grows for years if you never limit it. Check its size and trim it:
$ journalctl --disk-usage $ sudo journalctl --vacuum-size=200M
Cap it permanently by setting SystemMaxUse=200M in /etc/systemd/journald.conf, then sudo systemctl restart systemd-journald.
Package manager caches are safe to delete:
$ sudo apt clean && sudo apt autoremove -y$ sudo dnf clean all && sudo dnf autoremove -yThen check /var/log for old rotated logs that were never compressed or deleted (piles of *.log.1 and *.gz files). You can delete old rotated logs freely. Never delete an active .log file that a service still has open; empty it instead: sudo truncate -s 0 /var/log/huge.log.
4. Docker: the silent disk eater
If the server runs Docker, check it even when docker ps shows nothing. Old images, stopped containers, build cache, and unused volumes take space without being visible:
$ docker system df $ docker system prune -a
Volumes hold live data
docker system prune -a --volumes also deletes unused named volumes. If a volume holds a database or uploads for a container that is only stopped, that data is gone. Run the prune without --volumes unless you are sure.
5. When df and du disagree
If df says the disk is 90% used but du cannot find the space, a process is holding a deleted file open. The space is not freed until the process releases the file:
$ sudo lsof -nP +L1 | grep REGLook for large files marked (deleted), note which process holds them, and restart that service (sudo systemctl restart nginx, or whichever service it is). The space comes back right away.
Quick reference
| Symptom | Check | Fix |
|---|---|---|
| Disk full | du -xh -d1 / | sort -rh | Go into the biggest folder, delete or empty files |
| Inodes full | df -i | Delete masses of small files (queues, sessions) |
| Journal huge | journalctl --disk-usage | --vacuum-size=200M + limit in journald.conf |
| Docker bloat | docker system df | docker system prune -a |
| df and du disagree | lsof -nP +L1 | Restart the process holding deleted files |
Where to go next
Once the disk is stable, stop it from filling up again: limit the journal, set up logrotate for your app logs, and on Docker hosts add a weekly docker system prune -af to cron. If you really need more disk, upgrade your plan from the client area under Actions, upgrade/downgrade.