Linux inode exhaustion: why free disk space can still mean no space left

Confirm blocks versus inodes

Use df for block capacity and df -i for inode usage on the affected filesystem. A “no space left on device” error can mean either resource is exhausted.

Check the mount that actually backs the failing path. Containers, separate /var or /home filesystems, and bind mounts can hide which filesystem is full.

Find directories with extreme file counts

Count files by directory and narrow the search progressively. Avoid an expensive full-filesystem recursive scan during an incident. Caches, sessions, thumbnails, spool directories, package trees, and application temp files are common sources.

Understand whether files are disposable before deleting them. A mail queue or database directory is not a cache just because it contains many small files.

Fix the lifecycle that created the files

Add expiration, rotation, queue processing, cache cleanup, or application retention so the same directory cannot grow forever. Monitor both disk bytes and inode percentage because either can become the first limit.

If the workload legitimately needs huge file counts, filesystem layout and service design may need to change so emergency cleanup is no longer part of normal operation.

Recover cautiously under full conditions

Free a small known-safe amount first so services can create state again, then perform controlled cleanup. Verify application queues, uploads, logging, and package operations after recovery.

• Check df and df -i.
• Locate the high-file-count path.
• Delete only data with a known lifecycle.
• Add inode monitoring and retention.