What to Do When Linux Disk Space Is Full

When Linux disk space is full, first identify the filesystem and mount point that rejected the write, then compare byte capacity with inode usage. Use du -x -d 1 on that same filesystem to find large directories (-d sets the depth in both GNU du on Linux and the BSD du on macOS), check journal and package-cache usage, and look for deleted files still held open. Free a small, recoverable amount first, verify it on the affected mount, and only then plan deeper cleanup.

Key Takeaways

• A full root filesystem, full home filesystem, inode exhaustion, and an unavailable mount need different repairs.
• df reports filesystem usage; du totals reachable directory entries. Their numbers can differ for valid reasons.［1］［2］
• Keep scans on one filesystem so another mount does not distort the result.
• Never delete unknown files from /usr, /var/lib, or application data merely because they are large.

For the general evidence-first approach, see the Device and App Troubleshooting Guide. If package operations are failing too, preserve their error and use the APT error guide after restoring working space.

When Linux disk space is full, which filesystem is it?

Keep the failing path and error. Ask df about that path directly:

df -h /path/that/failed
df -i /path/that/failed
findmnt -T /path/that/failed

df -h shows used and available byte capacity for the containing filesystem; df -i shows inode usage. The df manual defines these filesystem-level reports and the human-readable option. findmnt -T helps identify the mount backing a path.

A filesystem can have free bytes but no free inodes when it contains very many small files. Conversely, a large filesystem elsewhere does not help a full root or separate /var mount. If an expected data mount is missing, the application may be writing into the underlying directory on the root filesystem; restore the mount safely before deciding what belongs there.

Check reserved-space and quota policies with the system owner rather than assuming that an apparent percentage is the whole story. On production or encrypted systems, preserve recovery access before storage changes.

How do you find the largest directories on Linux safely?

Start at the affected mount point and stay on that filesystem. For root:

sudo du -x -h --max-depth=1 / 2>/dev/null

The -x option skips directories on other filesystems, while --max-depth=1 bounds the first pass. Sort or inspect the totals, then repeat against the one large directory you recognize, such as /var or a specific home directory. Do not begin with an unbounded scan across every mounted disk, network share, container mount, and backup volume.

du reports reachable directory content. Do not delete a directory merely because it ranks first. Determine its owner and purpose: a database, virtual-machine image, container store, backup, mailbox, or photo library requires its own retention and shutdown procedure.

For large user data, prefer moving verified files to another backed-up filesystem or deleting recoverable downloads through the owning account. Confirm that the destination is a different filesystem and has enough space before moving data.

Why can df and du disagree?

Common reasons include:

• a process still holds a file open after its directory entry was deleted;
• filesystem metadata, snapshots, reserved blocks, or copy-on-write behavior;
• a directory was measured without permission to read some children;
• data is hidden beneath another mounted filesystem;
• du and df were measured at different times while writes continued.

On systems with lsof installed, inspect deleted-open files:

sudo lsof +L1

If a large file is held open, arrange a controlled restart or reload of the owning service according to its documentation. Do not truncate an unknown descriptor or stop a critical service without a maintenance plan. The space is normally reclaimed when the final process closes the file.

How do you inspect journals and caches?

Check systemd journal disk usage first:

journalctl --disk-usage

The journalctl manual documents --disk-usage and vacuum options that remove the oldest archived journal files until a size or time boundary is met. Active journal files are not removed by vacuuming, and rotation can have the greatest effect when combined deliberately.［3］

If archived journals are confirmed as the main reclaimable category, set a bounded target appropriate to the system, for example:

sudo journalctl --vacuum-size=500M

Choose the limit from retention, incident-response, and compliance needs; 500M is an example, not a universal policy. Keep recent logs needed to understand the space growth.

For APT cache, inspect before cleaning:

du -sh /var/cache/apt/archives
sudo apt-get clean

apt-get clean removes retrieved package files from APT's local archive cache, not installed packages. Use it only when that cache is on the affected filesystem and the package database has enough working space. Other applications have different supported cleanup commands; do not invent a generic deletion rule for their data directories.

How do you create emergency headroom without losing evidence?

When a nearly full filesystem prevents normal tools from working, the immediate objective is a small, measured amount of headroom—not the largest possible deletion. First slow or pause the known writer when doing so is operationally safe. Then choose one recoverable category whose owner and location you have confirmed, such as a duplicate export or downloaded archive on the affected mount. Record its path, size, ownership, and reason for removal before changing it.

Check four questions before the first cleanup action:

• Is the object actually on the filesystem reported by df -h /path/that/failed?
• Is it reproducible, backed up, or covered by an approved retention rule?
• Is an application still writing to it or expecting it to remain in place?
• How much space or how many inodes should the action release, and how will you measure that result?

Free one bounded category, then immediately repeat df -h and df -i for the same failed path. If the expected amount does not appear, stop and investigate deleted-open files, a missing mount, permissions, snapshots, or continued writes instead of deleting a second unrelated category. This preserves evidence about the original growth and prevents an emergency cleanup from becoming an unreviewed retention policy.

On a shared or production machine, document the service owner and maintenance decision before restarting a process or vacuuming logs. Emergency headroom should be enough to restore controlled operation and diagnostics; permanent retention, quotas, mount correction, or capacity expansion is a separate follow-up with its own rollback and monitoring plan.

What should you free first?

Use this order:

Step 1: Slow the confirmed writer

Stop or pause the workload generating new data if that is operationally safe.

Step 2: Reclaim recoverable user data

Move or delete known recoverable user downloads, exports, or duplicate temporary artifacts.

Step 3: Use the package cache owner

Clean a confirmed package cache through its owning tool.

Step 4: Bound archived journal cleanup

Vacuum archived journals to an explicit size or time boundary after checking retention needs.

Step 5: Close deleted-open files safely

Address deleted-open files through a controlled service restart.

Step 6: Apply application-specific retention

Handle databases, containers, backups, or mail only with their documented procedure.

Do not directly delete files under /usr or /var/lib, wipe a directory by wildcard, or truncate unknown logs. Those actions can corrupt packages, databases, containers, or audit evidence while freeing less space than expected.

How do you verify recovery?

Repeat the measurements against the same path:

df -h /path/that/failed
df -i /path/that/failed

Confirm both available bytes and inodes, then retry one representative write or the original service health check. Record how much space was reclaimed and which category grew. A one-time cleanup is incomplete if a runaway log, failed backup, unbounded cache, or missing mount immediately fills the filesystem again.

After stability returns, set application-supported retention, monitoring, and alert thresholds. Leave enough headroom for package upgrades, logs, database transactions, and rollback—not only today's steady-state data.

Summary

Locate the failed filesystem, compare capacity and inodes, and use same-filesystem du passes to narrow the owner. Reconcile df and du with journal, cache, mount, and deleted-open-file checks. Reclaim only identified, recoverable data through the owning tool, then verify the same mount and prevent recurrence.

FAQ

Why does Linux say “No space left on device” when df -h shows room?

The filesystem may have exhausted inodes, a quota may apply, or the failing path may be on a different mount. Check df -i and findmnt -T for that path.

Why is du smaller than df?

Deleted-open files, filesystem metadata, reserved space, snapshots, hidden mount content, or unreadable directories can explain the gap.

Is it safe to delete logs manually?

Not as a general rule. Identify the owning logger and retention policy. For systemd journal, use documented bounded vacuum operations for archived files.

What does du -x do?

It skips directories on different filesystems. That keeps the investigation tied to the full mount instead of counting unrelated disks or network shares.

What does the du -d depth option mean on Linux and macOS?

-d N limits output to directories at most N levels below the path you name. In GNU du on Linux it is the short form of --max-depth=N［2］, so du -x -h -d 1 / gives the same bounded first pass as the command above. The BSD du that ships with macOS also accepts -d, -x, and -h, but not GNU long options such as --max-depth; run man du on the Mac to confirm the installed version.

Does apt-get clean uninstall packages?

No. It removes downloaded package archives from APT's cache. Installed package state remains, but you may need to download those archives again.

How is space from a deleted-open file released?

The final process holding it must close it, often through a controlled restart or reload. Deleting the pathname again has no effect.

Should I delete the largest directory immediately?

No. First identify its owner, purpose, backup status, and supported retention method. Large database or application directories are not ordinary disposable files.

---

Disclaimer: Storage layouts, filesystems, quotas, snapshots, and service procedures vary. Use backups, recovery access, and application-specific retention guidance on important systems.

Sources:

1. Ubuntu Manpage Repository — df(1) — https://manpages.ubuntu.com/manpages/noble/man1/df.1.html
2. Ubuntu Manpage Repository — du(1) — https://manpages.ubuntu.com/manpages/noble/man1/du.1.html
3. Ubuntu Manpage Repository — journalctl(1) — https://manpages.ubuntu.com/manpages/noble/man1/journalctl.1.html

Sources checked 4 October 2026.

---

Related Articles:

• Device and App Troubleshooting Guide
• recover APT after disk space is available
• understand Linux package formats and their managers
• Windows and Linux Dual-Boot Checklist