‘No space left on device’ does not always mean large files have consumed all capacity. Available inodes can also run out. These read-only commands apply to GNU/Linux with GNU Coreutils. Replace /var with the affected existing path.
Step by step
- Record the full error and the path where the application tried to write. Use
df -h /varto inspect that path's filesystem. Check available space and mount point; free space on another filesystem does not help here. - Run
df -i /var. Compare IFree and IUse% with block usage. Exhausted inodes may be caused by many small files. Not every filesystem presents a fixed inode limit in the same way. - Narrow down usage with
du -x -h --max-depth=1 /var. It totals accessible files and stays on that filesystem. It may read many directories and take time on large storage. Missing read permissions make the overview incomplete. - For unusually many small files,
du -x --inodes --max-depth=1 /varcan help compare directories. Investigate only the suspect subtree further. Do not indiscriminately remove log, database or container files. - Document large differences between df and du. Open deleted files, snapshots, reserved space, differing permissions or filesystem-specific accounting need further targeted investigation. Do not immediately restart services for this reason.
Check the result
Repeat df -h and df -i on the same path after a justified cleanup or expansion has been separately planned and performed. Then test the original failing application. If it still fails, also check quotas, read-only mounts and the filesystem of the actual runtime environment, such as a container.
Undo and limitations
These diagnostic commands delete no data. Keep outputs for comparison but review confidential path names before sharing. Deletion is not automatically reversible: establish ownership, retention and recoverability first.