How to find what is using disk space on Linux

• First, confirm which filesystem is actually full
• Narrow it down with du
• Where the space usually is
• Use something visual when the command line runs out
• When df and du disagree
• A safe order to work in

Your disk is full, or close enough that something has started failing. You need two answers fast: what is taking the space, and what can safely go. This walks through both, starting with commands that are on every machine already.

First, confirm which filesystem is actually full#

Before hunting for big files, find out where the problem is. /home filling up is a different problem from / filling up, and /boot filling up is a different problem again.

df -h

Read the Use% and Mounted on columns. A machine with separate partitions can have a completely full /boot (usually old kernels) while the main drive sits at 40%. If everything shows sensible numbers but you are still getting out-of-space errors, skip to the two cases where the numbers lie.

Worth checking at the same time:

df -i

That is inode usage. It is rare, but a filesystem can run out of inodes while it still has free bytes, usually from a directory holding hundreds of thousands of tiny files. The fix is the same (find them and clear them), but you would never spot the cause from df -h alone.

Narrow it down with du#

du sums up real disk usage per directory. The useful invocation walks one level at a time so you can follow the space down:

du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

Then repeat on whichever directory is the biggest, and keep going:

du -h --max-depth=1 /var 2>/dev/null | sort -hr | head -20

A few notes that save time:

• Run it with sudo for system directories, otherwise unreadable folders are silently counted as zero and you chase the wrong branch.
• 2>/dev/null hides the permission-denied noise.
• Add -x to stay on one filesystem. Without it you will wander into /proc, network mounts, and external drives, and the totals stop meaning anything.

To find individual large files rather than large directories:

find /home -xdev -type f -size +1G -exec ls -lh {} \; 2>/dev/null

Where the space usually is#

After doing this on enough machines, the same suspects come up. Check these before anything else.

Package manager caches. Every install leaves the downloaded package behind.

# Debian / Ubuntu
du -sh /var/cache/apt/archives && sudo apt clean

# Arch (keep the last 2 versions of each package)
du -sh /var/cache/pacman/pkg && sudo paccache -r

# Fedora / RHEL
du -sh /var/cache/dnf && sudo dnf clean all

Systemd journal logs. These grow until told otherwise, and a few gigabytes is common.

journalctl --disk-usage
sudo journalctl --vacuum-size=500M

Your user cache. Browsers, thumbnails, package tooling, and build caches all land here, and nothing prunes it for you.

du -h --max-depth=1 ~/.cache | sort -hr | head

Docker. If you use it at all, this is frequently the single biggest item on the machine. Images, stopped containers, build cache, and volumes.

docker system df
docker system prune          # containers, networks, dangling images
docker system prune -a --volumes   # aggressive, read what it lists first

Flatpak and Snap. Both keep old versions around.

flatpak uninstall --unused
du -sh /var/lib/snapd/snaps

The trash. Deleting in a file manager moves files here, and it still counts.

du -sh ~/.local/share/Trash

Old kernels, if /boot is the full one. On Debian and Ubuntu, sudo apt autoremove --purge clears the ones no longer needed. Never delete kernel files by hand; let the package manager do it so the bootloader config stays consistent.

Use something visual when the command line runs out#

Commands are fine for the suspects above. They are a slow way to answer "what is actually on this drive", because you have to guess where to look and re-run du at every level.

A treemap answers that in one pass. It draws every file and folder as a rectangle sized by what it uses, so the space hogs are simply the big rectangles. You look at the picture and you know.

Three good options on Linux:

• Storage Sifter, ours. A GPU-accelerated treemap, plus a right-click "safe to delete?" verdict that names what a path actually is (cache, build output, personal media, credentials) and gives you the matching cleanup command for your distribution. Free and open source, and it never deletes anything on its own.
• baobab (GNOME Disk Usage Analyzer), preinstalled on most GNOME systems. Rings rather than a treemap, and perfectly good for a quick look.
• Filelight on KDE. Same concentric-ring idea, fast, integrates with Dolphin.

If you are on a remote machine over SSH, none of those apply, and ncdu is the answer instead. It is a terminal browser over du results and it is excellent at what it does.

We compared all of them honestly, including where ours is the wrong choice, in Linux disk usage tools compared.

When df and du disagree#

This is the case that wastes an afternoon if you have not seen it before. df says the disk is full, du adds up to far less, and the missing space is nowhere. There are two normal explanations.

A deleted file that a process still holds open. Space is only reclaimed when the last file handle closes. A log file deleted while its service keeps writing to it is the classic version, and it is invisible to du because the directory entry is gone.

sudo lsof +L1

Anything listed has a link count of zero and is still consuming space. Restart the owning process to release it.

Snapshots. If you are on Btrfs or ZFS, or you use Timeshift, old snapshots hold onto the blocks of everything you have deleted since.

# Btrfs
sudo btrfs filesystem usage /
sudo btrfs subvolume list /

# ZFS
zfs list -t snapshot

Deleting files inside a snapshotted filesystem frees nothing until the snapshots referencing them are removed.

There is also a smaller, non-mysterious gap: ext4 reserves 5% of the filesystem for root by default, so a "100% full" disk still has a little space that only root can use. On a large data partition that reservation is worth reducing:

sudo tune2fs -m 1 /dev/sdXN

A safe order to work in#

1. df -h to find the full filesystem.
2. Clear the known caches (package manager, journal, Docker, trash). This is usually enough and carries almost no risk.
3. If it is still tight, look at the whole drive with a treemap and go after the biggest rectangles.
4. If the numbers do not add up, check lsof +L1 and your snapshots.

And the rule that matters most: understand what something is before deleting it. Space you free by removing a cache comes back the next time you build. Space you free by removing a directory you did not recognise is sometimes your photos.

Storage Sifter is our free, open-source disk-usage treemap for Linux. It maps your filesystem, colour-codes it by what things are, and tells you whether an item is safe to delete before you do anything. Get Storage Sifter.