Inode exhaustion

Inode exhaustion means your account has used every available file name slot, even when plenty of disk space remains. Applications then fail with errors such as ENOSPC, uploads stop, and databases may refuse temporary tables. Inodes track each file and directory entry; millions of tiny files can fill them while bytes stay around 40%. Run df -i to see inode use, then find the directory with the most names and clean it with a clear plan.

On Linux filesystems such as ext4, the inode count is fixed when the disk is formatted. Skipping df -i often leads people to delete a useful log instead of twenty million empty session files. Shared hosting accounts also carry inode quotas for this reason, so File Manager can feel slow long before the disk-used bar looks full.

df -i; find /var -xdev -printf ‘.’ | wc -c

The first command shows inode usage across mounted filesystems. The find one-liner gives a rough file count under /var without crossing into other filesystems. It does not name the worst folder; it only tells you whether that tree is worth inspecting. Narrow the search next, for example with find /var/tmp -xdev -type f | wc -l, then check session paths and mail directories. du can mislead here because empty files cost almost nothing in bytes and a great deal in inodes.

How to locate the heavy directories

Work from broad trees down to specific folders. Count files with find on each suspect path rather than sorting only by size. On a cPanel account you will usually look inside the home directory for sessions, caches, email, and leftover backup copies. Do not empty wp-content/uploads just to free names; that folder holds your media library originals.

cPanel File Manager often times out on a directory with hundreds of thousands of entries. Treat that as a signal to use SSH and file counts instead of assuming the panel is broken. If you must delete in the panel, work in small batches so the interface can keep up.

Sessions, thumbnails, and mail

A busy PHP site without session garbage collection is the most common case. You can end up with many millions of zero-byte session files. A plain rm -rf on that tree can run for a long time and load the disk heavily, so open a ticket with us if the count is extreme; faster cleanup options exist than a single naive remove. WordPress intermediate image sizes you never display are the second frequent cause. Turn off the extra sizes you do not need, then remove the generated derivatives while keeping the originals. Neglected Maildir mailboxes are the third pattern, with huge numbers of tiny unread messages consuming inodes.

Prevent the next fill-up

Session cleanup belongs in php.ini through session.gc_probability and a sensible gc_maxlifetime, not as a weekly emergency delete. On WordPress accounts, review image sizes and cache plugins so they do not keep creating files you never use. After you free inodes, recheck with df -i and another targeted find … | wc -l so you know the pressure is gone. Our nameservers and hosting stack do not change this process; the work is always count names, remove the right trees, then keep garbage collection in place.