Full disk on Ubuntu: differences between df, du and inodes
Published on 2026-10-26 by frfrand
Diagnosis of space and small files on a Linux VPS
The server says «No space left on device» but you deleted a large file and the error persists. Sometimes bytes are missing; other times, inodes. df and du look at storage from different points and help understand it.
I'll show you where the problem is, how to check it without guessing, and what I would do in an application that really has users. You don't need to memorize an entire manual to fix a specific failure.
What df, du, and inodes mean in practice
df -h reports filesystem usage; du summarizes space occupied by directories; df -i reveals inode usage, which can be exhausted by many small files. There may also be deleted files that remain open by a process.
A clarification before touching the server: if the project is already in production, save the state you found and check which user and machine you will run the commands on. Working as root without need and changing several things at once makes it difficult to find the cause of an error.
Useful commands to start
df -h
df -i
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h
sudo lsof +L1 | head
journalctl --disk-usagePaths, unit names, and domains are examples. Adapt them to your service. If a command requires administrator permissions, check what changes and why. Diagnostic queries should come before modifications.
Step by step, with checks
- Identify exactly which filesystem is full with
df -h. - Check inodes with
df -ito detect too many small files. - Explore folders of the same filesystem with
du -xwithout crossing mount points. - Inspect logs, old backups, and containers; do not delete system directories blindly.
- If you deleted a huge file and space does not return, check if any process still has it open.
After each step, verify an observable result: a status, a file, an HTTP response, or a log entry. If you find an unexpected message, save it for investigation instead of hiding it with repeated restarts.
Real example: an application that needs to be maintained
An invoice generation service creates thousands of temporary PDFs and never cleans them up. The disk runs out even though PostgreSQL occupies little. The solution involves retention policies and alerts, not just increasing the volume.
At the end, test the full path: enter via domain, call the API, write a test data point, and verify that the information is still there after a controlled restart. A server that "boots" is not always an application that works.
Mistakes worth avoiding
Never run destructive cleanup commands copied without reviewing paths. Deleting internal PostgreSQL or Docker files directly can corrupt data.
It is also important that credentials do not end up in terminal history, logs, shared files, or screenshots. For users and services, use minimum permissions and document who can revoke access.
How ArduMaker fits into this scenario
In ArduMaker, monitor VPS disk usage and separate temporary directories, databases, and backups. A process without file limits can affect all shared projects.
ArduMaker can help you manage VPSs, deploy repositories, and work with services, databases, and domains from the same platform. It does not replace what we just explained about Linux: precisely for that reason, it is worth understanding the diagnosis and having a way to repeat it.
When it is worth automating
If the task is repeated, first document the manual procedure and its checks. Then consider a script or a scheduled task with visible errors, logs, and limited permissions. Do not automate a command that you still do not know how to recover when it goes wrong.
Frequently asked questions
Can I try it without affecting customers? In many cases, yes: a staging VPS or a separate test service allows you to validate the configuration before changing production.
How do I know it worked? Check logs and a functional operation, not just that the command ended with exit code zero.
When do I need more resources? When metrics indicate CPU, RAM, disk, or connection saturation. A configuration failure is rarely fixed by hiring more memory.
References
In one sentence: first understand the error, then change one concrete thing and check its effect. That discipline saves you many hours of support.