Skip to content

Recipes

Scope: the jobs ncdu gets hired for, as short procedures. Each assumes the chapters before it; the dangerous steps say which chapter to reread.

"The root disk is full"

The classic page. Root filesystem only, cache counted (you may be about to delete it — you want it in the numbers):

$ ncdu -x /

Descend by size. The usual suspects are /var (logs, package caches), /usr (seldom guilty), /root and /home only if they share the filesystem — with -x, a separate /home mount shows the > flag and 0.0 B, which is the tool telling you it is not part of this question. When you find the directory, press i before d, and reread chapter 5 before any directory delete. On a production box, browse with -r first.

The before/after cleanup ledger

Chapter 6's workflow, as a habit:

$ ncdu -0 -o ~/snapshots/disk-2026-10-21-before.json /
$ ncdu /          (clean up, per chapter 5)
$ ncdu -0 -o ~/snapshots/disk-2026-10-21-after.json /

Browse the pair when someone asks what the cleanup actually recovered. The exports are a few hundred kilobytes for a home tree — the lab's is 2,920 bytes — so keeping dated snapshots costs nothing and ends arguments.

Scan there, browse here

A remote server with no room to sit in front of:

$ ssh server 'ncdu -o - /' > server-snapshot.json
$ ncdu -f server-snapshot.json

Full colour-free interactive browsing of a scan taken on another machine, with deleting impossible (chapter 6) — the safest way to plan a cleanup before the maintenance window opens.

The home-directory audit

Quarterly, ten minutes:

$ ncdu --exclude-caches ~

The total is your home without the parts you may delete blind; whatever tops the list is a real decision. Then quit, rerun without the flag, and the difference between the two footers is the size of "blind" this quarter — if the cache total shocks you, the tagged directories themselves (chapter 4) are the places to teach better habits.

Hunt the many-small-files directory

One huge file is easy. A million tiny ones fill disks and inodes while looking innocent by size:

$ ncdu ~     then C to sort by item count, c to show counts

In the lab the C ordering puts .cache (24 items) on top despite its modest 4.1 MiB. On a real tree, follow the item counts down: mail folders, node_modules, build trees and browser profiles are the usual nests. And remember chapter 3: each of those items costs a full block, so the disk-usage column already knows — counts tell you why.

Prove a file is sparse

Someone swears the 100 MiB image is "not really taking space":

$ ncdu homedir      (find it, then)
a                   apparent view: it jumps to the top
i                   the popup: both numbers, exact

Mirrored from outside with stat (chapter 3): size large, blocks zero (or far too few). The argument is over when both numbers are on one screen.

Check your blind spots

After any scan whose totals will drive a decision, look for ! flags before believing the footer — descend once through the top directories, or grep the export:

$ ncdu -0 -o scan.json /home
$ grep -c read_error scan.json

A nonzero count (chapter 9's specimen makes it 1) means unreadable corners; the totals omit them silently. Rescan as a user who can read them, or record the blind spot beside the number.

Keep a shrinking disk honest

A weekly dated export, automated:

# cron, Mondays 06:00
0 6 * * 1  ncdu -0 -o /var/backups/disk-$(date +\%F).json -x /

No screen, no interaction — -0 is built for this (chapter 4). Browse any week's file when "it filled up slowly, then all at once" needs a timeline. Mind the hardlink paragraph in chapter 6 before summing these with a script.