Linux Disk Usage & No Space Left Troubleshooting

Do not start by deleting files. First identify which filesystem is constrained, whether the problem is bytes or inodes, and what owns the data.

Fast troubleshooting flow

“No space left” / disk alert↓df -h: which filesystem is full?↓df -i: are inodes exhausted?↓du: which directory accounts for space?↓find: which files are large?↓If df ≫ du: check deleted-open files↓Remediate the owner/cause, then verify

1 — Identify the affected filesystem

df -h

Look at Use%, Avail and Mounted on. A 95% root filesystem and a 20% data filesystem are separate problems. Once you know the mount point, keep the investigation scoped to it.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   47G  3.0G  95% /
/dev/sdb1       200G   40G  160G  20% /data

Here, investigate /; scanning /data would waste time.

2 — Check inode exhaustion

df -i

Filesystem      Inodes   IUsed  IFree IUse% Mounted on
/dev/sda2      3276800 3276501    299  100% /

What to check: IUse% and IFree on the affected mount. Here the filesystem is effectively out of inodes even if df -h still shows free bytes. If byte usage looks reasonable but applications report No space left on device, check IUse%. A filesystem can have free bytes but no free inodes, commonly after creating huge numbers of small files.

3 — Drill down with du

sudo du -xhd1 / 2>/dev/null | sort -h

-x stays on the same filesystem, -h makes sizes readable and -d1 shows one level. Suppose /var is largest; repeat the same method:

sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h

The goal is a controlled drill-down: / → /var → /var/log → specific data, not a blind scan of everything.

4 — Find unusually large files

sudo find /var -xdev -type f -size +500M -printf "%s %p\n" 2>/dev/null | sort -n

A large file is evidence, not permission to delete it. Ask what owns it and why it grew. A log may need rotation; a database/WAL file may be essential state; a container-runtime file may be runtime-managed.

5 — Understand df vs du

df reports blocks used by the filesystem. du walks visible files/directories and totals what it can account for. If df reports much more usage than du, investigate rather than assuming either command is wrong.

A classic cause is a file deleted from the directory tree while a running process still has it open:

sudo lsof +L1

COMMAND  PID USER   FD   TYPE DEVICE   SIZE/OFF NLINK NAME
java    8421 app     7w   REG  8,2   8589934592     0 /var/log/app.log (deleted)

What to check: NLINK 0, (deleted), file size and the owning PID. This example accounts for roughly 8 GiB that du can no longer see. The blocks cannot be reclaimed until the process closes the file. Identify the owning process and use the application's appropriate log-reopen/restart procedure if required. Do not kill a production process solely to free blocks.

6 — Treat /var carefully

/var/log — logs; check rotation, retention and repeated errors.

/var/cache — caches; determine which application/package manager owns them before cleanup.

/var/lib — persistent service state. This may contain databases, container state or other critical data; large does not mean disposable.

7 — If Docker is consuming the filesystem

docker system df

TYPE            TOTAL  ACTIVE  SIZE     RECLAIMABLE
Images          18     6       12.4GB   7.1GB (57%)
Containers      8      6       1.2GB    210MB (17%)
Local Volumes   10     8       24.8GB   1.4GB (5%)
Build Cache     42     0       6.7GB    6.7GB

What to check: which category is large and the reported reclaimable amount. Reclaimable is a clue, not permission to remove production data. Use it to see space attributed to images, containers, local volumes and build cache before deciding what can be removed.

Do not jump straight to docker system prune -a. Prune operations remove resources. Diagnose first and remove only resources you understand are safe to remove.

8 — Fix the cause, not only today's symptom

Typical root causes include missing/broken log rotation, excessive application logging, incorrect retention, temporary files never cleaned, runaway jobs, backups written to the wrong filesystem, container/build accumulation or simply insufficient planned capacity.

Verify

df -h <mountpoint>
df -i <mountpoint>

Confirm capacity/inodes recovered, then monitor long enough to ensure usage is no longer climbing at the previous rate.