How to Find Directories with the Most Files in Ubuntu When Inodes Are Full

One of the most confusing errors a Linux system administrator can encounter is receiving a No space left on device notification when running commands or saving files, even though running df -h shows dozens or hundreds of gigabytes of available storage. On Unix and Linux filesystems (such as ext4), disk space is tracked in two distinct ways: raw storage capacity (blocks) and file system metadata pointers (inodes).

Every file, folder, and symbolic link consumes exactly one inode. When an application generates millions of tiny temporary files, PHP sessions, or mail queue spools, the filesystem can exhaust 100% of its available inodes while block storage remains mostly empty. Here is how to diagnose inode exhaustion, pinpoint the offending directories, and resolve the blockage in Ubuntu.

Step 1: Confirm Inode Exhaustion with df -i

To verify whether inode depletion is the root cause of your disk errors, inspect the inode status table:

1. Open your terminal (Ctrl + Alt + T) or connect via SSH.
2. Execute:

df -i

Evaluate the output columns:

Filesystem       Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1       3276800 3276800       0  100% /
tmpfs            504821       1  504820    1% /dev/shm

If IUse% on your root partition (/) or data volume shows 100%, your system cannot write any new files, create temporary locks, or execute log rotations until inodes are freed.

Step 2: Identify the Directories Holding the Most Files

Standard file management tools like ls or du struggle or crash when scanning folders containing hundreds of thousands of files. Instead, use a streamlined find pipeline that counts file instances per directory path:

Scan Common Problem Areas First (Fastest)

Inode bloat almost always originates within temporary, cache, or spool directories. Run this command to check the top 10 worst offenders in /var:

sudo find /var -xdev -printf '%h
' | sort | uniq -c | sort -k 1 -n | tail -n 10

Command Breakdown:

• -xdev: Prevents the scan from traversing into separate mounted filesystems or virtual filesystems (like /proc and /sys).
• -printf '%h ': Prints only the directory portion of each file path without outputting file names, dramatically reducing memory overhead.
• sort | uniq -c: Groups identical directory paths and counts the exact number of files in each.
• sort -k 1 -n | tail -n 10: Sorts numerically and prints the 10 directories containing the highest file counts.

A typical output revealing an abandoned PHP session folder might look like:

   12450 /var/log/journal
   28910 /var/lib/docker/overlay2
  942150 /var/lib/php/sessions

In this example, /var/lib/php/sessions contains over 940,000 files, accounting for nearly 30% of the entire system’s inode allocation.

Step 3: Common Inode Culprits in Ubuntu and How to Clean Them

Once you identify the bloated directory, clear the accumulated files safely:

1. Abandoned PHP Session Files

If garbage collection cron jobs fail, PHP sessions accumulate indefinitely. Delete sessions older than 7 days using find -delete:

sudo find /var/lib/php/sessions -type f -cmin +10080 -delete

2. Postfix / Sendmail Mail Queues

Undelivered local cron failure emails can fill /var/spool/postfix/maildrop or /var/mail with millions of messages:

sudo find /var/spool/postfix/maildrop -type f -delete

3. Package Cache and Old Kernels

Clear cached APT .deb archives:

sudo apt-get clean
sudo apt-get autoremove --purge

4. Stale Systemd Journal Logs

Vacuum journald logs to free up inode space:

sudo journalctl --vacuum-time=3d

Step 4: Verify Restored Inode Availability

After purging the excessive files, verify that your inode utilization has dropped back to normal operating levels:

df -i /

The IUse% metric should now display healthy headroom (typically below 20-30%), immediately resolving the No space left on device error.

Understanding and monitoring inode utilization ensures your Ubuntu servers remain stable and immune to unexpected storage lockups caused by micro-file accumulation.