# / is full on Linux — the first five commands to run

> A full root file system takes down services before it takes down your desktop. The order to diagnose it in, the deleted-but-open-file trap that hides gigabytes, and what is safe to remove on any distribution.

Canonical: https://bytesweep.app/blog/linux-disk-full-root.html
Last updated: 2026-10-16

## The root file system is full — diagnose it in five commands

When `/` fills on a Linux machine, services break before you notice anything. PostgreSQL refuses writes, journald stops recording the very events that would explain what happened, and a package upgrade stops halfway. Finding the cause is quick if you go in the right order. The step that catches people out is the third one.

- By [Shajeen Ahamed](https://bytesweep.app/about.html#author)
- Published 26 September 2026
- Last updated 16 October 2026
- 4 min read
- Part of [Disk usage analyzer for Linux](https://bytesweep.app/linux-disk-usage-analyzer.html)
- [How we write](https://bytesweep.app/about.html#how-we-write)

*Each step either finds the cause or rules out a whole class of them, which is why the order matters.*

### 1. Blocks or inodes

```
df -h
df -i
```

Two different failures produce the same “No space left on device”. The first `df` counts blocks. The second counts inodes, and a file system can sit at 12% of its blocks and 100% of its inodes when something has created millions of tiny files: a mail queue, a session directory, a misconfigured cache. If `IUse%` is 100, stop looking for large files and start looking for large numbers of them. This names the directories with the most entries:

```
sudo find / -xdev -printf '%h\n' | sort | uniq -c | sort -n | tail
```

### 2. The biggest directories, on this file system only

```
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15
```

Do not leave out `-x`. Without it `du` walks into `/proc`, `/sys`, network mounts and every other file system mounted below `/`, and the totals mean nothing. Then go one level into whichever directory is largest:

```
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15
```

On most servers the answer is visible by now: `/var/log`, `/var/lib/docker`, `/var/cache`, or someone’s home directory.

### 3. Deleted files that are still open

This is the one that wastes afternoons. A process that holds a file open keeps its blocks allocated after the file is deleted. `du` cannot see those blocks, because there is no directory entry left to walk; `df` counts them, because they are still allocated. The symptom is `df` and `du` disagreeing by many gigabytes.

```
sudo lsof +L1 | sort -k7 -n | tail -20
```

`+L1` lists open files with a link count below one, which is exactly the deleted-but-open set. Usually it is a log file that someone (or a naive cleanup script) removed while the service writing to it kept running. The fix is to restart that service, not to delete anything else. Next time, empty the file instead of deleting it:

```
sudo truncate -s 0 /var/log/some-huge.log
```

### 4. The journal

By default systemd’s journal may use up to 10 per cent of the file system it lives on, capped at 4 GB. On a server that has run for a year it is almost always near that cap and among the largest items.

```
journalctl --disk-usage
sudo journalctl --vacuum-size=200M
```

Set a permanent bound instead of repeating this; [bounding the systemd journal properly](https://bytesweep.app/blog/journalctl-vacuum.html) covers `SystemMaxUse` and the rotation settings.

### 5. The package manager

Arch keeps every package it downloads, and so does `apt-get` on Debian and Ubuntu (the newer `apt` command removes them after a successful install). Fedora and openSUSE do not keep them by default. Every one of them clears its cache on request:

```
sudo apt clean && sudo apt autoremove --purge        # Debian, Ubuntu
sudo dnf clean all && sudo dnf autoremove            # Fedora, RHEL
sudo paccache -rk1 && sudo pacman -Rns $(pacman -Qtdq)  # Arch
sudo zypper clean --all                              # openSUSE
```

On Debian and Ubuntu the `autoremove` half is often the bigger win because it takes old kernels with it, and each kernel with its initramfs and modules is 200 to 400 MB. Fedora limits kernels separately, through `installonly_limit`. The details per distribution are in [apt caches and old kernels](https://bytesweep.app/blog/apt-cache-cleanup.html), [paccache on Arch](https://bytesweep.app/blog/pacman-cache-cleanup.html) and dnf on Fedora.

### When those five find nothing

Each of these is a common single cause:

| Suspect | Check | Safe to clear |
| --- | --- | --- |
| Docker | `docker system df` | Yes, with care over volumes |
| Snap revisions | `snap list --all` | Yes, disabled revisions only |
| Flatpak runtimes | `flatpak uninstall --unused` | Yes |
| Core dumps | `du -sh /var/lib/systemd/coredump /var/crash` | Yes |
| Old kernels | `dpkg -l 'linux-image-*'` | Yes, keep the running one |
| Thumbnails and caches | `du -sh ~/.cache` | Yes |
| Btrfs snapshots | `sudo btrfs subvolume list /` | Carefully: see why df lies on Btrfs |

For `/tmp`, delete files inside it rather than the directory, and preferably by rebooting rather than by hand; what lives in /tmp, /var/crash and the core dump store explains which of those stores clear themselves.

Keep a few hundred megabytes free on `/` at all times. Below that `apt` cannot unpack, journald cannot rotate, and the tools you need to fix the problem are the first to stop working.

### Questions

#### Why is df at 100% when du says the disk is half empty?

Either deleted-but-open files, which `lsof +L1` finds, or reserved blocks. ext4 reserves five per cent of the file system for root by default, which on a 2 TB disk is 100 GB an ordinary user cannot write to.

#### Can I shrink the reserved blocks?

On a data volume, yes: `sudo tune2fs -m 1 /dev/sdXN` drops the reserve to one per cent. Leave the root file system at the default. That reserve is what lets root log in and fix things when the disk is full.

### Let Bytesweep clear this for you

Skip the commands. Bytesweep finds this for you, rates every item safe, review first or keep, and clears what you choose. Most of what it removes can be put back for seven days. See what it finds on your own disk, free for 3 days, then pay once with no subscription.

[Try it free for 3 days](https://bytesweep.app/download.html) [Buy · $29.99](https://bytesweep.app/pricing.html)

### Keep reading

- [**The systemd journal is bigger than you think: bounding it** journald defaults to using up to ten per cent of the file system, capped at 4 GB, and nobody chose that number. How to see the real size, vacuum it safely, and set a permanent cap that survives reboots.](https://bytesweep.app/blog/journalctl-vacuum.html)
- [**paccache, orphans and the Arch package cache** Arch never removes an old package on its own, by design, because downgrading is part of the deal. How to keep the number of versions you actually need and clear the rest, plus orphans and the AUR build cache.](https://bytesweep.app/blog/pacman-cache-cleanup.html)
- [**apt caches, old kernels and what autoremove actually purges** On Debian and Ubuntu the reclaimable space is in three places, and only one of them is the package cache. The commands in order of return, and why purge and autoremove are not the same thing.](https://bytesweep.app/blog/apt-cache-cleanup.html)