Out of inodes: disk space is free but files can't be created — causes and fix

Site owners sometimes hit a confusing situation: the hosting panel shows less than half the disk in use, yet the site cannot upload a new image, WordPress refuses to update plugins and the mailbox stops receiving mail. The logs say "No space left on device" or "Disk quota exceeded". The problem here is not the amount of data but the number of files. Every file and directory takes one inode in the file system, and hosting plans usually limit inode count as well as disk size.

What an inode is and why it runs out separately

An inode is a file system record that stores metadata about a file: owner, permissions, size and where its data lives on disk. Large or small, every file uses exactly one inode. A 2 GB video uses one inode, while a hundred thousand 1 KB cache files use a hundred thousand, even though together they weigh about 100 MB. That is why you can hit the file count limit while the disk looks nearly empty.

Once the limit is reached, the system simply refuses to create new files. PHP cannot write session files, so users cannot log in; the cache plugin cannot store new pages; image uploads fail; incoming mail is not saved. From the outside the site looks broken, while in reality one directory has quietly filled up with junk.

Confirming that inodes are the problem

Start with the hosting panel. In ISPmanager the user resources section shows the file count and its limit next to disk usage. If disk usage is low but the file count is near the limit, the diagnosis is clear. With SSH access you can count from the terminal:

find ~ -xdev | wc -l

On shared hosting df -i often reports the whole server rather than your personal quota, so don't rely on it. The panel, or quota -s where the server allows it, is more accurate.

Finding the folder that collected the files

GNU du can count inodes instead of bytes. This lists the 20 directories with the most files:

du --inodes -x -d 3 ~ 2>/dev/null | sort -n | tail -20

On older servers without --inodes, use find:

for d in ~/*/ ~/www/*/*/; do
  printf '%s %s\n' "$(find "$d" -xdev | wc -l)" "$d"
done | sort -n | tail -20

One or two directories usually stand out. The usual suspects are WordPress cache folders under wp-content/cache, the tmp folder with PHP session files, mailboxes nobody has cleaned in years, extracted and forgotten backup archives, and full node_modules or vendor trees uploaded to the server.

Example: an online shop in Tashkent

Imagine a clothing store on misol.uz running WooCommerce. One morning the owner cannot upload product photos and customers say items won't go into the cart. The panel shows 40 percent disk usage, but the file counter is at the limit. du --inodes reveals several hundred thousand files in wp-content/cache: the cache plugin stored a separate page for every combination of colour and size filters. The plugin's own "clear cache" button timed out because of the sheer number of files, so the folder was cleared over SSH and caching of URLs with filter parameters was disabled. A few minutes later the shop worked normally.

Safe cleanup commands

Always check what you are deleting and back up anything important first. Cache files are regenerated by the site, so clearing them is safe:

cd ~/www/misol.uz/wp-content/cache
find . -type f -delete

Session files start with sess_; removing ones older than two days does not affect active users:

find ~/tmp -type f -name 'sess_*' -mtime +2 -delete

In huge directories rm -rf * may fail with "Argument list too long" because the shell expands every name into one command line. find ... -delete avoids that. Mail stored in Maildir format keeps every message as a separate file, so archiving old mail and emptying Spam and Trash folders also frees inodes.

Preventing a repeat

Limit cache lifetime in the cache plugin and enable automatic purging. Add a daily cron job in the panel to clear old sessions:

0 4 * * * find $HOME/tmp -type f -name 'sess_*' -mtime +2 -delete

Don't leave extracted backups inside the site; keep them as archives or move them off the hosting account. If the site genuinely needs a huge number of files, such as a large photo gallery, consider a plan with a higher limit or a VPS. Exact limits can be checked in the sayt.uz cabinet or with technical support.