Fix ENOSPC: No Space Left on Device (inodes full)

You're copying a bunch of small files — maybe a mail spool, a cache directory, or a Git repo — and suddenly the write fails with No space left on device. You run df -h and it shows 40% used. Confusing as hell. I've seen this exact thing happen to a client whose backup script died overnight because a logging directory had millions of tiny files.

Root cause: Inodes, not disk space

Every file on a Linux filesystem needs an inode — a metadata record that stores permissions, timestamps, and pointers to the actual data blocks. When you format a filesystem, a fixed number of inodes is created. If you create millions of 1KB files, you can exhaust the inode table long before the disk is full. The filesystem simply refuses to allocate new inodes, and that triggers ENOSPC even though df -h shows free space.

There's also a second, less common culprit: reserved blocks. By default, ext4 reserves 5% of the disk for the root user, so a non-root user can get ENOSPC when the disk is actually 95% full. That's not your problem if you're root, but it's worth knowing.

Check inode usage first

Run this to see inode usage per mounted filesystem:

df -i

Look at the IUse% column. If it's at 100%, there's your answer. The output will also show the filesystem mount point, usually / or /var.

To find which directory is eating inodes, use find to count files in subdirectories:

find /var -xdev -type f | cut -d/ -f3 | sort | uniq -c | sort -rn | head

This groups files by the third path component (like /var/spool). On my client's server, it was /var/spool/postfix — thousands of undeliverable mail messages.

The fix: Delete files or reformat with more inodes

Deleting files is the quick fix. If you find the offending directory, clean it out. For a mail spool, purge old messages:

find /var/spool/postfix -type f -mtime +30 -delete

But sometimes you can't delete — you need those files. The real fix is to reformat the filesystem with a higher inode ratio. mkfs.ext4 lets you set -i bytes-per-inode (smaller number = more inodes). For example, to get 1 inode per 16KB (good for mail spools), use:

mkfs.ext4 -i 16384 /dev/sdb1

This wipes the partition, so back up first. If you're on a running system and can't reformat, your only option is to free up inodes or move data to a newly formatted filesystem.

Check reserved blocks if you're not root

If inode usage is fine but non-root writes still fail, check reserved block space:

tune2fs -l /dev/sda1 | grep 'Reserved block count'

The reserved blocks are included in the used space shown by df, so it's easy to miss. On a big data drive, you can lower the reservation to 1% using tune2fs -m 1 /dev/sda1. I do this on backup drives all the time — 5% of a 10TB drive is 500GB wasted.

Still failing? Check these next

Run df -h and df -i again — did the problem move to a different mount point?
If you're using overlayfs or Docker, check the upper layer — it might be full even if the lower layer has space.
Look for deleted files still held open by processes. lsof +L1 shows them. Kill the process and space frees up.
Check quotas: quota -u username on a filesystem with quotas enabled.

That last one caught me off guard once — a user had a 1GB quota on /home and got ENOSPC while the disk was half empty. The error message doesn't tell you it's a quota, you just have to know to look.

In short: when Linux says no space left, don't just trust df -h. Check df -i for inodes, and remember reserved blocks. After you fix it once, you'll never forget.