How do I check inode usage in HestiaCP? What's causing the inability to write files even when there's plenty of disk space?

A couple of days ago, a friend messaged me late at night saying that his server had crashed.

The specific symptoms were particularly bizarre: the website suddenly started throwing errors, logs couldn't be written, and creating new files would immediately prompt that the disk was full.

But when he checked with `df -h`, he was shocked to find that the disk clearly had tens of gigabytes of free space. How could it be full?

I told him right then and there, "Brother, you're not just full of storage space, your Inode is overloaded."

He replied with a question mark: What exactly is an Inode?

In fact, many people react exactly the same way he did when they first fell into this trap, because no one in school ever taught them this stuff.

Let's clarify what an Inode is first.

Think of it as a library index card, and it will be easy to understand.

Disk space is like a bookshelf; how many books you can put on it depends on its capacity, which is easy for everyone to understand.

An inode is like an index card for each book, recording its name, location, and who moved it.

In Linux , every file and every directory must occupy an inode, no matter how small the file is.

Even if it's an empty file, the system will still consume an index card for it.

The system has a limit to the total number of files it can create; this limit is the total number of innodes.

Once the inode is used up, even if your disk still has hundreds of gigabytes of free space, the operating system will refuse to create any new files.

Logs cannot be written, cache cannot be created, and the website crashes completely—that's the bizarre scene you're witnessing.

Honestly, this is a really tricky situation because the error message is sent from a location you're not looking at.

The first trick is to use `df -i` to get a quick overview.

In the HestiaCP environment, you can simply SSH into the terminal and type this line.

df -i

It will list out the total number of innodes, the number used, and the number remaining for each mounted partition.

In the output, there is a column called IUse%, which is the key metric you should keep an eye on.

If the IUse% of a partition reaches 100%, even if that partition still has plenty of disk space, it will no longer be able to create any new files or logs.

I suggested to my friend that he run this first, so that it could pinpoint whether the problem was with the Inode in a second , which would be much faster than guessing.

The second method is to use `find` to precisely count a specific user.

After confirming that the problem is with the innode, the next step is to find out who is consuming the index card excessively.

HestiaCP has a separate home directory for each user. You can simply count the total number of files and directories under a specific website directory.

find /home/用户名/web/你的域名/public_html | wc -l

Replace "username" and "your domain name" with your actual path. The pure number returned by the terminal is the sum of all files and folders in that directory.

Each file or directory corresponds to one inode, so this number represents the inode usage.

If you're too lazy to check each one individually and want to see the usage distribution of all users across the entire site at once, there's also a single loop command.

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

This line will print the total number of files in each user directory under /home, making it easy to spot which user directory has an abnormally high number of files.

The third strategy is to identify the subdirectories that consume the most iodine.

Sometimes you know a website has ridiculously high Inode values, but you still can't figure out what's wrong with the screen full of files.

In such cases, you need to drill down one level to find subfolders that contain a large number of small files, such as cache directories, session directories, and log directories—these are the most problematic areas.

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

This command will list the top 10 subfolders that consume the most files.

The path at the very top of the list is where a large number of small files are clustered together.

I told my friend that it was probably some caching plugin secretly generating small files, and running this line would basically confirm it.

The fourth tip is to check the quota limit using repquota.

If your server has Linux file system quotas enabled, you can look at the problem from a different perspective.

repquota -a

This command will pull up the file limit and actual file usage for all users.

Pay close attention to the File Limits section in the output; the used column indicates how many files have been used.

The "soft" and "hard" columns represent the soft and hard limit thresholds. Once "used" reaches "hard", the system will directly refuse to create new files.

This is a completely different story from how much space you have left on your disk.

To wrap things up, let's connect the dots of the investigation.

Let's go back to the friend who crashed the server in the middle of the night at the beginning.

He followed the four steps I described, starting with `df -i` to confirm that the inode was indeed full.

Then, using find, we located the cache directory of an abandoned old website that was generating small files like crazy.

Finally, checking `repquota` confirmed that it had indeed reached the hard limit.

After clearing out that pile of junk cache, the website came back to life immediately.

So next time you encounter this strange situation where "the disk clearly has space but you can't write files," don't rush to add a hard drive.

First, use `df -i` to take a look at the inode; the truth may very well be hidden on that index card you've never noticed before.

I genuinely believe that these little bits of common sense hidden at the system's core are more useful than memorizing a hundred optimization lists.