“No space left on device” always seems to show up at the worst moment: halfway through a kernel update, during a database write, or at 97% of a container build.
This guide shows how to free up disk space on Linux the right way. That means finding what is actually eating your storage, removing it through the tool that owns the data, and setting limits so you don’t repeat the exercise every few months. It works for a laptop, a homelab box, or a production server.
Ubuntu 26.04 LTS shipped on April 23, 2026 (official release notes), and Fedora 45 arrived in early November 2026. Fresh installs are tidy on both, but every system accumulates the same clutter over time, whatever the version.
Why Guessing Is the Wrong Approach
The classic mistake is deleting by instinct. Someone spots a large folder, runs rm -rf, and breaks something. Wiping /var/log while services run, hand-deleting pieces of /var/lib/docker, or removing the kernel you are booted into can turn a storage problem into a recovery job.
A safer method has three parts:
- Measure before touching anything.
- Clean through the owner of the data: the package manager, journald, Docker, Snap.
- Cap growth so the problem doesn’t return.
Across desktops and servers, most of the reclaimable space tends to sit in the same few places: package caches, journals, container leftovers, Snap/Flatpak remnants, and home-directory caches. We will go through them in order of safety.
Example Scenario (Illustrative)
To make the numbers concrete, here is a typical developer laptop with a 512 GB drive at 94% full. After following this guide in order, the breakdown looked like this:
| Source | Space reclaimed |
|---|---|
| Docker build cache and dangling images | 38 GB |
Rust target/ folders in old projects | 21 GB |
| Snap old revisions | 4.2 GB |
| journald logs | 3.1 GB |
| apt cache + old kernels | 2.4 GB |
~/.cache and npm/pip caches | 6.8 GB |
| Total | ~75 GB |
These figures are an example, not a benchmark. Your split will differ, but the order of magnitude is realistic for anyone who builds software or runs containers.
Step 1: Measure First
Start with the big picture:
df -h
df -idf -h shows space per filesystem. df -i shows inodes. If inodes are at 100% while space looks fine, you have millions of tiny files (mail queues, session files, build artifacts), and deleting a few large files won’t help.
Next, find the heavy directories. The -x flag keeps du on a single filesystem:
sudo du -xh / --max-depth=1 2>/dev/null | sort -hDisk Usage Tools Compared
| Tool | Interface | Best for | Trade-off |
|---|---|---|---|
du + sort | CLI | Quick checks, scripts, any server | No interactivity |
ncdu | Terminal UI | SSH sessions, delete-as-you-browse | Scans can be slow on huge trees |
gdu | Terminal UI | Large NVMe drives, parallel scanning | Usually a separate install |
| Disk Usage Analyzer (Baobab) | GTK GUI | GNOME desktops | Needs a desktop session |
| Filelight | Qt GUI | KDE users who like radial maps | Same: desktop only |
| BleachBit | GUI + CLI | Per-app cache cleanup | Aggressive presets can remove things you wanted |
My default: sudo ncdu -x / on servers, Baobab on desktops.
Step 2: Package Caches and Orphans
Package managers keep downloaded files for fast reinstalls. After a year or two of updates, that cache is often several gigabytes.
Debian, Ubuntu, Linux Mint
sudo apt clean
sudo apt autoremove --purgeFedora and RHEL-family (DNF5 on current Fedora; DNF5 docs)
sudo dnf clean all
sudo dnf autoremoveArch and Manjaro (see the Arch Wiki on cache cleaning)
sudo paccache -r # needs pacman-contrib; keeps 3 versions per package
sudo pacman -ScAvoid pacman -Scc unless you are sure. It deletes every cached package, including the older versions you would need for a rollback.
openSUSE
sudo zypper clean --allTypical savings: 0.5–5 GB, depending on update frequency.
Step 3: Old Kernels
Each kernel update leaves the previous one behind on purpose, as a fallback. But a kernel with modules and headers can occupy 300–500 MB, and they add up.
On Debian-based systems, sudo apt autoremove --purge normally trims the oldest. Check what you have first:
uname -r
dpkg -l 'linux-image*' | grep ^iiFedora limits installed kernels to three by default, so it largely manages itself. Arch typically keeps one per kernel package.
The rule I follow: never remove the running kernel, and keep one older version until the new one has survived a reboot or two.
Step 4: The systemd Journal and Core Dumps
Check the journal size:
journalctl --disk-usageLong-running servers often show multiple gigabytes. Trim safely:
sudo journalctl --vacuum-size=300M
# or by age
sudo journalctl --vacuum-time=2weeksTo prevent regrowth, set a permanent cap. Create /etc/systemd/journald.conf.d/size.conf:
[Journal]
SystemMaxUse=500MRestart with sudo systemctl restart systemd-journald. The journald.conf reference covers the other limits. Don’t hand-delete files under /var/log/journal; the vacuum commands keep the journal consistent.
Core dumps from crashed programs land in /var/lib/systemd/coredump. Review them with coredumpctl list. If you are not debugging anything, clear old ones and cap future ones with MaxUse=500M under [Coredump] in /etc/systemd/coredump.conf.d/size.conf.
Step 5: Snap and Flatpak Leftovers
Snap
Snap keeps old revisions for rollback. Remove the disabled ones:
snap list --all | awk '/disabled/{print $1, $3}' | while read name rev; do
sudo snap remove "$name" --revision="$rev"
doneThen limit future retention (2 is the minimum):
sudo snap set system refresh.retain=2Flatpak
flatpak uninstall --unused
flatpak repairUnused runtimes pile up after you remove apps. To also clear an app’s stored data, use flatpak uninstall --delete-data <app-id>, but only if you won’t want those settings back. See the Flatpak docs for details.
Typical savings: 1–8 GB.
Step 6: Containers Without Collateral Damage
If you use Docker or Podman, this is often the biggest single win. See what is there first:
docker system dfThen clean in order of rising risk (full behavior is in the Docker pruning guide):
docker builder prune # build cache
docker image prune # dangling images
docker system prune # stopped containers, unused networks, dangling images
docker image prune -a # every image not used by a containerVolumes deserve extra caution because they often hold databases. Run docker volume ls and inspect before pruning any, and never do it on a host you don’t fully understand. Podman users have equivalent podman system prune commands.
One firm warning: don’t rm -rf /var/lib/docker to “reset” things. The daemon depends on metadata in that folder, and partial deletion corrupts it.
Typical savings: 5–50 GB on active developer machines.
Step 7: Home Directory Caches
Your home folder holds the stuff most likely to be both large and safe to remove.
~/.cache: nearly everything regenerates. Check withdu -sh ~/.cache/* | sort -h.- Trash:
gio trash --empty - Browser caches: clear them in browser settings, not by deleting profile folders.
- Toolchain caches:
pip cache purgenpm cache clean --forcego clean -cachecargo cleaninside old Rust projects (a singletarget/folder can reach tens of gigabytes)~/.gradleand~/.m2for Java builds
Also scan for stale node_modules folders in projects you haven’t opened in months.
Step 8: Large Files and Duplicates
Find individual big files:
sudo find / -xdev -type f -size +1G -exec ls -lh {} + 2>/dev/nullCommon finds are forgotten ISOs, VM disks, old backups, and downloaded datasets.
For duplicates, use a dedicated tool:
fdupes -r ~/Documentslists duplicates and can prompt for deletion.rmlintgenerates a reviewable removal script instead of deleting directly.- Czkawka offers a GUI with duplicate, empty-file and similar-image search.
Review every list yourself. Duplicates inside application or config directories sometimes need to exist.
Step 9: When df and du Disagree
Deleted but still open
If df says the disk is full but du can’t account for it, a process may be holding a deleted file open. This is common when a log file is deleted while its service is still writing.
sudo lsof +L1The space returns when you restart the owning service. It is the usual explanation for “I deleted 20 GB and nothing changed.”
Btrfs snapshots
On Btrfs (the default on Fedora Workstation and openSUSE), df can mislead because of snapshots, compression and shared extents. Use Btrfs’s own view (Btrfs documentation):
sudo btrfs filesystem usage /
sudo snapper list
sudo snapper delete <number>Space may not return instantly after deleting a snapshot, so wait a minute and recheck. If data chunks are mostly empty but fully allocated, a light sudo btrfs balance start -dusage=50 / can reclaim them. Run it when the system is idle.
Reserved space on ext4 data drives
On a non-root ext4 data disk, the default 5% reserve is wasteful. On a 4 TB archive drive, that is about 200 GB. Lower it with sudo tune2fs -m 1 /dev/sdXN. Leave your root filesystem alone, because the reserve protects system stability.
Cleanup Methods Compared
| Method | Typical recovery* | Risk | Reversible? | Best for |
|---|---|---|---|---|
| Package cache clean | 0.5–5 GB | Very low | Yes (re-downloads) | Every system |
| Old kernel removal | 0.3–2 GB | Low with one fallback kept | Yes (reinstall) | Frequently updated machines |
| Journal vacuum + cap | 0.5–4 GB | Very low | No (logs gone) | Servers, long uptimes |
| Snap/Flatpak cleanup | 1–8 GB | Low | Yes (reinstall) | Ubuntu and desktop users |
| Docker/Podman prune | 5–50 GB | Medium (volumes) | Rebuild or pull again | Developers, homelabs |
| Home cache cleanup | 1–20 GB | Low | Mostly regenerates | Everyone |
| Duplicate removal | Varies | Medium | Only with backups | Media and document archives |
| Btrfs snapshot pruning | 5–100+ GB | Medium | No | Fedora/openSUSE on Btrfs |
*Typical ranges based on common real-world setups, not lab benchmarks. Your results will vary.
If you are short on time, work from the top of the table down. The first three rows carry almost no risk.
Manual Commands vs. Cleaner Apps
Command-line cleanup
Pros:
- Shows exactly what is removed and why.
- Works over SSH on headless servers.
- Easy to script and schedule.
Cons:
- Requires learning a handful of commands.
- A typo in a path can cause real damage.
GUI cleaners such as BleachBit
Pros:
- Previews deletions before running them.
- Knows per-application cache locations you would never remember.
Cons:
- Aggressive presets can wipe saved sessions or history.
- Running as root widens the damage from any bad rule.
- Doesn’t understand containers, snapshots or custom data.
Which to pick: on servers, stay with CLI tools. On desktops, use the package manager for system-level cleanup and let a GUI tool handle application caches in your own user account only. Always preview first.
Mistakes That Turn Cleanup Into Recovery
- Running a
rm -rfcommand copied from a forum without reading it. - Deleting
/var/logcontents while services run. Usesudo truncate -s 0 file.logor logrotate instead. - Removing the running kernel and rebooting.
- Pruning Docker volumes on a host holding production data.
- Bulk-deleting duplicates without a backup.
- Running a file manager or cleaner under
sudo.
When in doubt, move instead of delete. Shift the folder to another disk for a week and see whether anything complains.
Keep It Clean: A Simple Prevention Routine
A one-time cleanup helps. A habit is better:
- Cap the journal with
SystemMaxUse. - Limit Snap revisions with
refresh.retain=2. - Schedule a monthly package cache clean via cron or a systemd timer.
- Set an 85% usage alert. A small script is enough:
#!/bin/bash
USAGE=$(df / --output=pcent | tail -1 | tr -dc '0-9')
[ "$USAGE" -gt 85 ] && echo "Root disk at ${USAGE}%" | mail -s "Disk warning on $(hostname)" [email protected]- Run
ncduonce a quarter. It takes five minutes and catches surprises early. - Prune Docker build cache weekly on build servers.
FAQ
How much free space should I keep on a Linux system?
Keep at least 10–15% of your root filesystem free. Below that, updates, logging and package installs can start failing.
Is it safe to run apt autoremove?
In nearly all cases, yes. Read the list it prints first, since it removes packages that nothing depends on any more.
Why does df show a full disk when du shows less?
Usually a deleted file is still held open by a running process, or snapshots are retaining old data. Check with sudo lsof +L1 or your Btrfs snapshot list.
Can I delete everything in ~/.cache?
Generally yes, because applications rebuild it, though some may start slower the first time. Close running apps before clearing it.
What is the fastest way to free several gigabytes on Linux?
Run your package manager’s clean command, vacuum the journal, and prune unused Docker images. Together they often recover 5–20 GB in minutes.
Conclusion
Learning how to free up disk space on Linux the right way comes down to one habit: measure first, then clean through the tool that manages the data. Package caches, journals, Snap and Flatpak leftovers, container images and home caches account for most of the waste, and each has a safe, built-in command.
Keep a fallback kernel, treat volumes and snapshots with respect, and don’t let rm -rf solve problems it can easily create. Add a few size caps and a quarterly ncdu check, and your drive should stay healthy long after today’s cleanup.
Disclaimer: The commands and recommendations in this guide are provided for general informational purposes. Linux distributions, versions and system configurations differ, so results may vary on your machine. Deleting files, pruning containers or removing snapshots can cause permanent data loss if done incorrectly. Always back up important data and review each command before running it, especially anything used with sudo. Test on a non-production system first when possible. The author and this website are not responsible for data loss, downtime or other issues resulting from the use of this information. Savings figures are typical ranges and example scenarios, not guaranteed outcomes.
