linux troubleshooting guide

Disk Full on Linux: First Response Without Guessing

Start with filesystem evidence, separate byte exhaustion from inode exhaustion, then drill down only inside the mount that is actually full.

Problem

An application cannot write files, uploads fail, package installs stop, or the shell reports no space left on device. The tempting move is to delete big-looking directories. The safer move is to prove which filesystem is full and why.

First rule

Do not delete anything until you know whether the problem is bytes, inodes, or a mounted volume that is not the path you first suspected.

Audience

new Linux users, VPS owners, junior administrators, and certification students practicing storage triage

Cert context

Useful for LPIC-1, LFCS, and Linux+ style command practice around filesystems, storage, logs, and safe administration. This is unofficial study support, not provider-approved training.

quick start

Safe first commands

df -h
df -i
du -xhd1 /var 2>/dev/null | sort -h
find /var -xdev -type f -printf '%s %p\n' | sort -nr | head -20

Prove the failing filesystem first

A disk-full symptom often appears in an application path, but the full mount may be root, a data volume, a container volume, or a separate log partition. `df -h` gives the mount-level view, which is the only view that matters for write failures.

df -h
df -h /var /srv /home 2>/dev/null

Check inode pressure before hunting large files

A filesystem can have free bytes and still fail writes if it runs out of inodes. That usually points to too many small files rather than one giant log or backup.

df -i
find /var -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -nr | head

Stay on one filesystem while drilling down

The `-xdev` flag keeps `du` and `find` from crossing into mounted backups, container layers, network filesystems, or data volumes. That matters when root is full and another mount happens to live under the path you are inspecting.

du -xhd1 /var 2>/dev/null | sort -h
find /var -xdev -type f -printf '%s %p\n' | sort -nr | head -20

Prefer archive, rotate, truncate, or service-aware cleanup

Deleting a file that a running process still has open may not free space until the process closes it. Logs, package caches, and application uploads each have different safe cleanup paths. Capture evidence first, then choose the smallest reversible action.

sudo lsof +L1 2>/dev/null | head
journalctl --disk-usage

triage logic

How to read the result

`df -h` shows one mount at 100 percent

Clean inside that mount, not wherever the symptom first appeared.

Next: Run folder and file ranking with `-xdev` against the full mount.

`df -i` shows inode usage near 100 percent

Look for huge counts of small files, not only large files.

Next: Rank directories by file count and inspect application cache or session directories.

large deleted files remain open

Space may not return until the owning process releases the file descriptor.

Next: Identify the process and plan a restart or log rotation.

safety notes

Slow down here

Avoid broad `rm -rf` commands during first response.
Do not clean `/var/lib`, database directories, or application storage without knowing the service contract.
Capture command output before cleanup if this is an incident or shared system.

related lessons