Linux disk full: read-only troubleshooting
Troubleshoot a full Linux disk safely: identify the filesystem, check bytes and inodes, map visible directories, and verify ownership before cleanup.
Direct answer
First identify which mounted filesystem is full and whether the shortage is blocks or inodes. Then scan that same filesystem, compare its visible directory usage with capacity, investigate any gap, and only after that review service-specific retention or cleanup procedures.
When this guide applies
- A service reports “No space left on device.”
- df shows one mount near 100 percent.
- Deleting an obvious file did not restore the expected free space.
Step-by-step review
Identify the filesystem
Read mounted-filesystem capacity and map the failing path to its mount point.
Check blocks and inodes
Byte capacity and inode availability are separate limits; a filesystem can exhaust either.
Scan visible paths on that filesystem
Keep the scope aligned with the mount and inspect largest directories and files without crossing into unrelated mounts.
Explain the difference
If visible totals are much lower than filesystem usage, consider unreadable paths, deleted-but-open files, hidden mount contents, snapshots, metadata, and reserved space.
Escalate to the owning service
Use its documented retention, rotation, package, database, container, or backup workflow instead of a generic recursive delete.
Technical context
Start from the failing path
A host can contain many filesystems. Scanning / while the failing application writes to a separate data mount can waste time or mix unrelated totals.
Inode exhaustion is a different failure
A filesystem with free bytes can still reject new files when no inodes remain. Directory size alone will not diagnose it.
A large df-versus-du gap is evidence
The commands measure different layers. The gap should trigger targeted checks, not an assumption that either result is wrong.
Time pressure increases cleanup risk
When a production disk is full, record the current evidence and coordinate with the service owner before changing active data.
Read-only signals and what they mean
| Signal | Question answered | Important limit |
|---|---|---|
| Filesystem bytes | Which mount is low on capacity? | Does not identify a pathname. |
| Filesystem inodes | Has the filesystem run out of file records? | A low byte percentage does not rule this out. |
| Directory totals | Which visible hierarchy is large? | Misses inaccessible and unlinked files. |
| Largest files | Which visible regular files are biggest? | Large does not mean safe to remove. |
| Snapshot delta | Which matching path grew between scans? | Requires two comparable complete scans. |
Risks and actions to avoid
Do not delete active logs blindly
The process may keep an unlinked file open, and direct deletion can break expected rotation or audit retention.
Do not assume sudo fixes the diagnosis
Elevation expands visibility and risk; it does not explain ownership or safe retention.
Do not compare mismatched scans
A different host, root path, mount mode, or incomplete run can produce a misleading delta.
What the Omuuz product can—and cannot—do
What it can do
SSH Disk Visualizer can show mounted capacity, visible hierarchy, large items, completeness warnings, categories, and matching-snapshot growth in one read-only investigation.
What it cannot do
It cannot inspect kernel-only causes, diagnose every filesystem, restart a service, close an open handle, alter retention, or free space automatically.
Product evidence
