cPanel Says the Inode Limit Is Reached but Disk Space Is Fine

When cPanel's Statistics panel shows File Usage at its limit while Disk Usage looks comfortably low, it is easy to assume something is broken. It isn't. The two counters measure different things. Disk Usage counts bytes, and File Usage counts inodes, which roughly means the number of files and directories the account owns. You can run out of the second with gigabytes of the first still free. When that happens, uploads fail, mail stops arriving, and caches stop writing, all at once and for no obvious reason.

What the File Usage counter is counting

An inode is the record a Linux filesystem keeps for each file or directory: owner, permissions, timestamps, and where the data lives on disk. Every file, directory, and symlink uses one, regardless of size. A 1-byte session file and a 2 GB backup archive cost the same single inode. That is why the two limits behave so differently. A site with a few large videos uses lots of space and very few inodes. A site with a busy cache plugin, years of unpurged sessions, or a mailbox full of spam can use very little space and an enormous number of inodes. The limit itself belongs to the hosting account, not the server. How it is enforced depends on the setup. It might be filesystem quotas, CloudLinux limits, or another mechanism, and your host can tell you which one applies. In every case, once the account reaches its cap, the kernel refuses to create new files for that user, even though the disk underneath has room.

Symptoms that point to inodes, and the red herrings

The pattern support engineers learn to recognize is several unrelated features failing together. File Manager uploads error out. WordPress can't save media or update plugins. A cache plugin reports it can't write to its folder. PHP logs warnings about session files. Incoming mail gets deferred or bounced with quota-related messages. In error logs, the system error you usually find is Disk quota exceeded. Linux uses that message for both the block (space) quota and the inode quota, which is part of why people chase the wrong one. Two red herrings come up all the time. The first is checking the server. If you have SSH access and run df -i, the filesystem may show plenty of free inodes. That tells you about the whole partition, not your account's quota. A server-wide inode shortage is a different problem, covered in why "No space left on device" appears when the disk still has room. The second red herring is deleting big files. Removing a large backup archive frees space but only one inode, so the File Usage counter barely moves. The fix is almost never "delete something big." It is "find the directory with a huge number of small things." The first thing worth doing on any ticket like this is to put both counters side by side. If disk is low and files are high, stop looking at sizes and start counting.

Finding the directories with the most files

With SSH or cPanel's Terminal, du can count inodes instead of bytes. Start at the home directory and work down one level at a time:

BASH

# Count inodes per top-level directory in your home folder, largest last
cd ~
du --inodes -d 1 . 2>/dev/null | sort -n | tail -15

The output pairs an inode count with each directory. Repeat the command inside whichever directory is largest until you reach the one actually holding the files.

TEXT

Illustrative output format (numbers are made up and round):
800      ./etc
2000     ./public_html
5000     ./tmp
150000   ./mail
160000   .

In that example, mail is the obvious place to drill into next. If your system's du doesn't support --inodes, a slower fallback works almost anywhere: run find . -xdev | cut -d/ -f2 | sort | uniq -c | sort -n from the directory you're inspecting. It prints a count per subdirectory in the same spirit. Without shell access, File Manager can still help. Open a directory you suspect and look at the item count. It's slower, but the suspects are predictable.

The usual suspects

PHP sessions are a classic. Every visitor who triggers session_start() gets a small file, usually named sess_ followed by a random ID. PHP is supposed to clean old ones up through garbage collection, but depending on how PHP was packaged, that job may be disabled in favor of a separate cron cleanup. If an application sets its own session.save_path inside your home directory, nothing may be cleaning it at all. To find the real path, check it from the site's own PHP, for example a temporary phpinfo page you delete afterwards. Command-line PHP can report a different value than the PHP serving the website. Cache plugins are the second big source. Page cache plugins often write one file, sometimes several, per URL and per variant. Query strings, filter combinations on shop category pages, mobile versions, and compressed copies multiply that quickly. A site with a few hundred real pages can end up with far more cache files than that if every crawled filter URL gets cached. Clear the cache from the plugin's own settings first, then look at why it grew: caching query-string URLs, no expiry, or an aggressive preload. Mail is the third. cPanel stores mail in Maildir format, where each message is its own file, usually under a path like ~/mail/example.com/user/, with folders such as .Trash and .spam as dot-prefixed subdirectories. Trash folders that never get emptied, spam folders on catch-all addresses, and the account's default mailbox collecting cron job output can each hold a very large number of messages. Cron output is easy to miss. Every scheduled run can send an email, and nobody reads that inbox. Smaller contributors include the File Manager's own .trash directory (deleting through File Manager may only move files there, see why emptying the cPanel .trash folder matters), node_modules or vendor folders left behind in old staging copies, and extracted backups nobody remembers making.

Cleaning up safely and confirming the fix

Prefer the application's own cleanup tools where they exist. Purge cache from the cache plugin so its internal state stays consistent. Empty mail folders through webmail or a mail client so the mail server's indexes stay in sync. In Roundcube, you can also have Trash emptied on logout from the preferences, though the exact option location varies by version. For PHP session files, deleting old ones directly is generally safe, as long as you only touch files old enough that no active visitor is using them. Always preview before deleting:

BASH

# Replace the path with your actual session.save_path
# Step 1: preview session files older than 24 hours
find ~/path/to/sessions -type f -name 'sess_*' -mmin +1440 -print | head -20

# Step 2: only after checking the preview, delete them
find ~/path/to/sessions -type f -name 'sess_*' -mmin +1440 -delete

A word of caution before running the second command. -delete is permanent, and there is no trash to restore from. Double-check the path, keep the -name filter, and never point it at ~ or public_html. Logged-in users whose sessions get removed will simply need to log in again, but a wrong path can wipe real site files. After cleaning, run du --inodes again to confirm the count actually dropped. cPanel's File Usage counter may take a little while to catch up, depending on how the server refreshes quota data, so don't panic if the sidebar lags behind the shell. Then test the things that were failing: upload a file, save a post, send a test email to an affected address. Mail deferred while the account was full is typically retried by the sending server on its own schedule, so some messages may arrive late rather than never. Finally, fix the source so it doesn't refill. Set a cron to clean the session directory if nothing else does. Set expiry and query-string exclusions in the cache plugin. Redirect or silence cron output with >/dev/null 2>&1 on jobs you don't need mail from. Set auto-cleanup on Trash and spam folders. The short version: when File Usage is full and Disk Usage isn't, stop looking for big files and start counting small ones. du --inodes will usually point at sessions, cache, or mail within a few minutes. The cleanup is quick. What keeps the ticket from coming back is fixing whatever was creating all those files.