Linux Inode Exhaustion: No Space Left With Free Disk Capacity

A Linux application can report no space left on device even while the disk appears to have plenty of gigabytes available. One possible cause is inode exhaustion: the filesystem has run out of the structures needed to represent additional files. Session stores, file caches, mail queues, and temporary-file directories are common places to investigate because their contents can grow in count faster than in size.

Check file count capacity separately

Run df -i and identify the filesystem containing the failing path. Compare its inode usage with the byte usage shown by df -h. Inode behavior depends on the filesystem, so avoid treating every storage format as if it has the same fixed allocation model. The GNU coreutils manual documents inode reporting in df and du. A clear distinction between count pressure and byte pressure prevents an irrelevant cleanup of a few large files.

Narrow the search to likely producers

On GNU systems, du --inodes -x --max-depth=1 /var can show where inode usage concentrates. Start with a narrower application directory if you already know which service is failing. A scan over millions of files takes work, so avoid launching several recursive scans together on an already strained server. Check the application's own metrics or administrative interface when those can report cache entries, sessions, or queued items more cheaply. Record both the dominant directory and the program that owns it.

Interpret a small-file example

Imagine an application that writes one temporary file for every image preview and never expires old previews. Each file is small, so monthly storage graphs show modest byte growth. After enough requests, new uploads and package operations begin failing because both need new filesystem entries. Removing a large archived export may free gigabytes without solving the count constraint. Expiring verified disposable preview files addresses the relevant resource, while fixing the missing expiration policy prevents the same incident from returning.

Clean through the owning application

Use documented cache, session, or queue maintenance procedures when available. Those procedures understand whether entries are active and whether metadata must be updated with them. Do not assume that every old file in a spool or temporary-looking directory is expendable. Preserve a sample and confirm ownership before bulk removal. For a production mail queue, for example, deleting files directly can lose messages and break the software's bookkeeping. A safe action should identify exactly which data is disposable and what users might notice.

Monitor growth in the right unit

After recovery, record inode usage and application entry counts on a schedule that reveals the growth rate. Alert early enough to leave time for a controlled cleanup. Put a retention limit on the producer and check that its scheduled maintenance actually completes. If the workload legitimately creates many small files, consider whether application storage design or filesystem selection needs a planned review. More disk capacity alone is not a universal guarantee of more usable file entries under every configuration.

Keep this count-based check beside ordinary storage monitoring in your guest runbook. Consult LayerOne documentation for service access and the backup guide before cleanup. The most useful prevention is a measurable retention policy owned by the application that creates the files.