Linux No Space Left On Device

Introduction

When you run into the dreaded Linux “no space left on device” error, it can halt critical workflows, block log rotations, and even prevent package managers from updating. This error typically appears as No space left on device or Disk full and signals that the filesystem associated with a specific mount point—such as /, /home, or /var—has reached its storage capacity. Understanding why this happens and how to recover quickly is essential for anyone managing Linux servers, desktops, or containers. In real terms, in this guide we’ll explore the root causes, walk you through a step‑by‑step recovery process, and explain the underlying filesystem mechanics that make the error appear. By the end, you’ll have a reliable toolkit to diagnose, clean, and prevent future storage crises No workaround needed..

Understanding the Error

The “no space left on device” message is a generic kernel notification that the underlying storage medium (HDD, SSD, or a mounted partition) cannot accommodate additional data. If either runs out, the kernel returns this error. This leads to linux checks two primary resources when writing: disk space (measured in blocks) and inodes (metadata structures that track file attributes). While the symptom looks the same regardless of the cause, the remedy differs depending on whether you are out of blocks or inodes.

Common Triggers

• Full root partition – / runs out of free blocks.
• Exhausted home directory – /home fills up with user files.
• Log accumulation – /var/log grows unchecked.
• Package cache – /var/cache or /var/lib/apt stores unresolved dependencies.
• Container images – Docker or LXC images consume large amounts of space in /var/lib/docker.
• Database files – MySQL, PostgreSQL, or MongoDB data directories swell over time.

How to Diagnose the Issue

Before you start deleting files, confirm exactly where the shortage lies and whether it’s a block or inode problem.

1. Identify the mount point

   df -h
   

   Look for the line where Avail is 0 or very low. Note the Mounted on column That alone is useful..

2. Check inode usage

   df -i | grep 
   

   Compare IUsed and IFree. If IFree is zero while blocks are still available, you are out of inodes Nothing fancy..

3. Locate the largest directories

   du -sh //* | sort -hr | head -10
   

   This quickly reveals which subdirectories are consuming the most space Easy to understand, harder to ignore..

4. Examine log sizes

   ls -lh /var/log | awk '$5 ~ /%/ {print $5, $9}'
   

   Identify logs that are nearing 100 % of their partition.

Steps to Free Up Space

Clean Temporary Files

• User temporary directories

  sudo rm -rf /tmp/* ~/.local/share/Trash/*
  

• System-wide temporary files

  sudo apt clean
  sudo yum clean all
  

Remove Unused Packages

• Autoremove (Debian/Ubuntu)

  sudo apt autoremove -y
  

• Remove orphaned packages (CentOS/RHEL)

  sudo yum autoremove -y
  

Manage Docker or Container Images

If Docker is installed:

docker system prune -a --volumes

This removes stopped containers, dangling images, and unused volumes Easy to understand, harder to ignore. Less friction, more output..

Check and Rotate Logs

• Identify large logs (example for /var/log)

  find /var/log -type f -size +100M -exec ls -lh {} \;
  

• Rotate using logrotate (ensure /etc/logrotate.conf and related configs are active)

  sudo logrotate -f /etc/logrotate.d/
  

Use Disk Cleanup Tools

• For systemd‑based systems

  sudo journalctl --vacuum-size=100M
  

  Keeps only the most recent 100 MB of journal logs.
• For BTRFS

  sudo btrfs filesystem df /dev/sdX
  sudo btrfs filesystem usage -b /dev/sdX
  

Shrink or Move Large Directories

If a directory is essential but oversized:

• Move to another partition (requires sufficient free space):

  mv /path/to/big_dir /new_mount/point/
  

• Compress older files using gzip or pigz for parallel compression.

Reclaim Inodes

If inode exhaustion is the problem:

• Delete empty directories recursively

  find /path -type d -empty -delete
  

• Remove orphaned files (files with no directory entry) – rarely needed but can be scanned with lsof or find / -type f -inum <inode>.

Scientific Explanation

The Linux kernel uses a filesystem abstraction layer to manage storage. Two key metrics determine whether a write succeeds:

1. Blocks – The actual data storage units (e.g., 4 KB blocks). The df -h output reports Avail in blocks.
2. Inodes – Metadata structures that store file names, permissions, timestamps, and links. Each file consumes one inode, regardless of its size.

When a process attempts to create a file, the VFS layer first checks for a free inode. If none exist, the operation fails with “No space left on device,” even if free blocks remain. Because of that, conversely, a full block pool triggers the same error. This dual‑resource limitation explains why simply deleting large files sometimes does not resolve the issue—inode exhaustion may persist.

Different filesystems handle this differently:

• ext4 – Supports up to 4 billion inodes per filesystem; typical default inode‑to‑block ratios are 1:128.
• XFS – Uses a dynamic inode allocation; inodes are plentiful but still finite.
• BTRFS – Implements copy‑on‑write and has its own space management; it may reserve space for snapshots, affecting availability.

Understanding these mechanics helps you choose the right cleanup strategy. To give you an idea, on an ext4 system with many small files (like log entries), you might need to delete files rather than just freeing blocks Not complicated — just consistent..

FAQ

Q: Can I safely delete files from /var/log?
A: Yes, but only after rotating and compressing logs. Use logrotate to create archived copies (.1, .2, etc.) before truncation Easy to understand, harder to ignore..

**Q: My /home partition is

Q: My /home partition is full—what can I do without losing personal data?
A: Start by identifying the biggest space hogs:

# Show the top 10 directories by size (human‑readable)
du -h --max-depth=1 /home | sort -rh | head -n 10

If you see a few directories (e.g., ~/Videos, ~/Downloads, or a large ~/projects folder) consuming most of the space, you have three safe options:

1. Move the directory to another mount point

   # Assuming /mnt/data has ample free space
   sudo mkdir -p /mnt/data/home_big
   sudo mv ~/Videos /mnt/data/home_big/
   # Create a symlink so applications still find the files
   ln -s /mnt/data/home_big/Videos ~/Videos
   

   Verify the symlink works (ls -l ~/Videos) and update any backup scripts that reference the old path.

2. Compress infrequently accessed files
   For archives, old backups, or media you rarely touch:

   # Parallel gzip (pigz) is faster on multi‑core CPUs
   find ~/projects -type f -name "*.log" -mtime +30 -exec pigz {} \;
   

   After compression, you can optionally move the .gz files to a cheaper storage tier (e.g., an external HDD).

3. Enable user‑level quotas (if you share the machine)

   sudo apt install quota   # Debian/Ubuntu
   sudo edquota -u $USER    # edit your soft/hard limits
   

   Quotas prevent a single user from filling the partition and give you early warnings before hitting the hard limit.

Additional FAQ

Q: How do I safely clean up Docker images and containers?
A: Docker stores layers under /var/lib/docker. Use the built‑in prune commands, but first list what will be removed:

docker system df          # view usage
docker image prune -a     # removes unused images
docker container prune    # stops and removes exited containers
docker volume prune       # removes dangling volumes

Add --filter "until=24h" to target only objects older than a day if you want a more conservative cleanup.

Q: My SSD reports “available” space but writes still fail.
A: SSDs reserve a portion of capacity for wear‑leveling and garbage collection (often called over‑provisioning). If the drive is near its advertised limit, the controller may refuse writes even though the filesystem shows free space. Check the drive’s health with smartctl -a /dev/sdX and look for the Media Wearout Indicator or Percentage Used. If those values are high, consider securely erasing the drive or replacing it Easy to understand, harder to ignore..

Q: Can I shrink a live ext4 filesystem?
A: Ext4 does not support online shrinking. You must unmount the partition (or boot from a live USB), run e2fsck -f /dev/sdXn, then resize2fs /dev/sdXn <newsize> where <newsize> is expressed in blocks. After shrinking, you can safely resize the partition with fdisk or parted and reclaim the freed space for another partition or LVM volume Worth knowing..

Conclusion

Managing disk space on Linux is a two‑front battle: you must monitor both block consumption (the raw storage capacity) and inode consumption (the metadata that tracks each file). In practice, remember that different filesystems (ext4, XFS, BTRFS) have distinct inode allocation behaviors, so tailor your approach to the underlying storage technology. But by routinely checking df -h and df -i, identifying large or numerous files with tools like du, ncdu, or find, and applying the appropriate cleanup strategy—whether it’s vacuuming journal logs, moving directories to alternate mounts, compressing old data, or pruning container images—you can keep your system healthy and avoid the dreaded “No space left on device” error. With regular maintenance and a clear understanding of how the kernel accounts for space, you’ll ensure smooth operation even under heavy workloads Simple as that..