One of the most common (and misunderstood) elements of a website and web hosting is the inode. If you run your own website or handle maintenance on any level at all, you will deal with inodes at some point. Whether that is through routine maintenance or attempting to fix an error, knowing what an inode is and how it affects your WordPress installation is imperative to your long-term success.
- 1 What is an Inode?
- 2 The Problem with Inodes
- 3 Why Inodes Matter for WordPress Users
- 4 How WordPress Users Build Up Inodes
- 5 How to Fix Common Inode Errors
What is an Inode?
In a very general sense, an inode is a single file within your file system. For most users, that’s enough information to deal with almost everything that they will come across.
More technically, however, an inode is where the metadata for files is stored on UNIX systems (Linux servers and Apple computers are UNIX based). Inodes are the table entries that are linked to by directories and files Inodes contain all sorts of information:
This metadata includes (1) the size of the file (in bytes) and its physical location (i.e., the addresses of the blocks of storage containing the file’s data on a HDD), (2) the file’s owner and group, (3) the file’s access permissions (i.e., which users are permitted to read, write and/or execute the file), (4) timestamps telling when the inode was created, last modified and last accessed and (5) a reference count telling how many hard links point to the inode.
Because most web servers are Linux-based, inode management is going to be important. You can think of them like they are links to your website. You can have multiple links pointing to the same page of your site, but that doesn’t mean there are multiple copies of that page. The same is true of files and inodes.
While technically, there is not a 1:1 relationship, you will find many instances where there is only 1 file linked to 1 inode. Most users can work under the idea they are.
The Problem with Inodes
They run out. They are finite. And you probably aren’t tracking your inode usage.
Not too long ago, I received the “Warning: Account YourSite.com Reached 80% Of The Allowed Inode Quota” email from Siteground out of the blue. I hadn’t done anything out of the ordinary, but somehow, I was stacking up my inodes like a tower. I would guess that if you’re running multiple installations of WordPress on your hosting account, you have gotten (or will get) a similar email.
Now, in the email, they’re very straightforward: To decrease the number of inodes, you need to reduce the number of files and folders on your account via cPanel – File Manager or your preferred FTP client. And in essence, that’s all you have to do. But it’s a bit more complicated than that because if you’ve had your host for any amount of time, you’ve probably got a pretty decent archive of files and folders in there.
To check your inode usage, you will want to log into your cPanel and look for the Stats box. In most versions of cPanel, it will be to the left of the page somewhere. You will see primarily the Disk Usage Space in MB and GB, as well as the number of inodes you’re allowed and the number of inodes you’re using at that moment.
Luckily, like most things about WordPress, the CMS is put together in a way that makes managing your inodes relatively straightforward.
Why Inodes Matter for WordPress Users
Many of you may never have to work with inodes. In day-to-day business, you won’t really notice them at all. As long as everything is going well with your site, nothing should make you ever even see the word. It’s when something goes wrong that you will start seeing errors in your WordPress dashboard or somewhere else.
Generally, every hosting provider out there who uses cPanel (which is most of them, unless you’re going for managed hosting) has allotted you a certain number of inodes based on your package. The rule is generally the more you pay, the more inodes you get.
Keep in mind that this is entirely separate from how much storage space you have. The two may be 1:1-ish in volume, but you will generally run out of inodes before you run out of storage space because inodes are a lot smaller in terms of bits and bytes than most of your files (because they’re only part of the file itself).
That said, WordPress users often find themselves fighting some inode-centric issues.
How WordPress Users Build Up Inodes
While every CMS out there has its own unique ways of taking up inodes, WordPress has some that are specific to its ecosystem. Primarily images, plugins, and themes. Let’s dig in and find out why and what we can do about it.
Images in your media library likely take up a ton of your inodes. Even if you don’t have thousands and thousands of them. I would wager that most of you upload images to your site. And in theory, 1 image equals 1 inode. But that’s not how things actually work. Depending on your theme and your image compression plugin, that 1 image can take nearly a dozen inodes. How? By keeping renders of multiple sizes in storage.
If you check the details of any image in your library and see a file size, then it’s an inode. Think about that for each and every image in your media library. For this one particular site, I have 562 items in the media library. Assuming (probably incorrectly) that they each have 11 versions, that’s 6,000+ inodes. Literally eleven times what it should be.
And that’s for one site. If you take into account the number of sites on any general hosting plan, that number can really add up. On my own account, I have a dozen installations of WordPress running. On top of the Core files from each install, the media libraries from all the users increase inode usage.
Plugins and Themes
You have a few reasons that plugins and themes take up so many inodes. The first is simply that many people have tons of them installed, even if they’re deactivated.
And within each of these plugin folders, dozens and dozens of files are taking up inodes. Some plugins are obviously lighter than others, but all of them add bulk to your installation. So remember that it’s generally best practice to delete any plugins that you aren’t currently using.
Themes work the exact same way. There’s no telling how many themes you have installed on your WordPress site if you’ve had it for a decent amount of time. Even if those themes are simply the default WordPress themes, you have a lot of inodes being used. If you’re not using a theme, delete it. If you’ve made customizations via a child theme, however, it’s generally okay to keep it there (or make a backup) since you can’t just reinstall it as easily as you can the parent theme.
Caching Plugins and Backup Utilities
Comet Cache. WPRocket. Updraft. iThemes. WordFence. WP Super Cache. W3 Total Cache. Sucuri.
All of these (and more) take up precious inodes. For the most part, that’s okay. They’re amazing security and caching plugins that make your life easier and your users’ experiences on your site better. But left unchecked, however, the cache files and backup files and security reports can build up.
So every once in a while, make sure that you clear the cache on your site and let it repopulate itself. Most of the time, you can find a Purge Cache or Delete Cache button in the admin toolbar.
Additionally, extra backups from plugins like UpdraftPlus can take up precious space. So check to see what you have stored on your local server. You can do this from within your WP admin panel for most backup utilities. Or you can check via FTP.
On top of these backups taking up inodes and storage space on your server, they’re also vulnerable to hackers who may get into your installation. So keeping them in a remote destination (Dropbox or Google Drive, for example) is going to be the best idea.
How to Fix Common Inode Errors
And even though WordPress has platform-specific inode issues, there are some that are common across the web. Whether you’re on Drupal, Joomla, WordPress, or even Ghost, you may have to fix these at some point.
- Emails won’t send, either through a traditional client, via autoresponders, or from forms on the site itself
- Can’t receive emails
- Uploads consistently fail
- Posts and Pages won’t update or even create
- Users cannot access the site
- In some cases, migration from one host to another might be blocked
In all of these cases, what might be the culprit is that the server is approaching the top end of its inode quota. Or that it’s completely out of inodes. Remember, even if you’re using only a portion of your storage capacity, you can still use up your inodes.
Every time an email is sent or received, a file is generated. If there are no inodes, no file can be made. If your inodes are full, uploads will fail because there is simply nowhere to store the data. The same can be said for posts and pages in WordPress or other CMS platforms can’t generate the necessary files without a spot. Even when users visit the page, files are generated — cookies, tokens, cached files. If there’s no inode, those users get nothing served to them.
When migrating from one host to another, your inode allotment may be different. Mine was the last time I swapped, personally. So you may not even be near your current quota, be already be over your upcoming one. It may sound like a pain, but it was really easy to fix, actually.
Here are the best ways to remove files and free up some space to fix these common inode errors.
Delete Old Emails
You see, every time an email is sent or received, it creates a file on your server (assuming that you’re not using an external mail service). That means all your mail is taking up inodes. If you archive or simply hold your emails in your inbox, those are sitting on your server, stagnating. So it’s time to delete them. You can do this in your normal client, or you can do it via FTP or through your cPanel’s File Manager.
Simply go into the root directory of your site and find the Mail folder. Under it will be directories for each domain you have an email address for, and under each of those will be any of the aliases you’ve set up. Each one of those folders is important and can be full of inode-stealing files. You will be primarily concerned with the cur and new directories, though. Sometimes Junk.
After just deleting the new emails in this one address, I went from 218316 inodes used to 218218. You should have an even greater gain because this email address was very rarely used in the first place. Just remember to back up all the emails before you delete them. You can’t get them back otherwise.
Clear Your Temp Folders
Temporary files are fantastic beasts. If you know where to find them, you can make sure that they are doing their jobs, but not taking up far too many resources. Whenever you see a tmp directory, this is where those temporary files are stored. Session tokens, cache files, traffic logs, all sorts of stuff that are great at the time, but serve no purpose later.
Unless you’ve set up an automation or CRON job to clear out temporary files, you may need to go in every once in a while and perform a little housekeeping. Primarily these will be in your root directory under tmp.
As a general rule of thumb, you can delete any log files, cache files, or session files. For the most part, you will see them noted very clearly. Usually the file name will contain sess or cache or log, making your job very easy.
Most of the files you delete will be server logs and traffic logs. As long as you have a backup of these files, go through your tmp folders and delete what you need to. In this particular example, I am clearing out the webalizer, webalizerftp, horde, awstats, and analog directories. Please keep in mind that removing these files will remove server statistics and logs, so back them up first if necessary.
You can check the dates on them, too. Depending on your site, you may not need logs all the way back to 2011.
Additionally, you will find a handful of files in your primary tmp folder, too. They might be a mix of session files, log files, and other files that you’re not sure about. Just like everything with computers and web development, if you don’t know what it is, leave it alone. But it is very important that you do not delete any files that have a .sock extension. And to a lesser extent, .lock.
Clear Your Log Files
Similar to the tmp folder, the logs folder is a root directory that contains archive upon archive of your server’s logs. Your server begins keeping a log for each domain for each month you’ve had it active on your host. That can be a lot of logs. Make a backup of them because they’re kind of important and delete away.
Delete Unnecessary Website Installations
There are two reasons that you don’t want to have superfluous installations taking up your inodes. The first is, well, you’re wasting inodes on something that you’re not using. The second is that forgotten websites are vulnerable to major security threats and are the most common way for hackers to get into shared servers via brute force attacks.
Remember how I said earlier there were 12 installations of WP on my personal hosting plan? Well, 8 of those 12 are completely (or at least mostly) useless. Of those, 6 can be deleted without worry and 2 are placeholders.
There are over 5,000 files in each WordPress installation — which is at least 5,000 inodes — and if you did anything to customize it or add plugins or themes…well, you and I should both probably take a look at what we have sitting around on our server.
Running out of inodes on your host is annoying and disruptive. Even if you get warned long before you reach capacity, you still have to take a good amount of time to clear out data from your server. However, if you take a quick pass through all of the tips above, you should be able to easily lower inode usage by at least 20% in one pass.
Whether you’re on WordPress or some other CMS, inode usage is something that may not come up very often, but when it does, you’ll be very glad that you’re ready for it.
What have you found is the best way to lower inode usage on your sites?
Article featured image by strangebirdy / shutterstock.com
Very useful article!
This is a great walkthrough, thanks.
What about SSL Certificates? In my file system, I have a bunch of files in /ssl/certs/ and /ssl/keys/, some are over a year old.
So in other words inode is a fancy word for “file count”
If you have “inode issues” (technically, they are vnodes in modern OS’s, but we’ll let that one slide) then change service providers. In the “olde days,” the number of inodes on a filesystem was fixed. In modern systems, vnodes (which translates to virtual index nodes where inodes are index nodes) can be expanded almost as much as the filesystem could handle. Any service provider limiting you on inodes, or the number of files, has problems. Either they are using it to suck more money from you (see GoDaddy) or they are incompetent (see everyone else).
Thanks for this well-crafted, helpful article!
What a terrific tutorial !
As a GoDaddy client, we have been held hostage with capacity issues. No one could explain to us what was happening, but they wanted more money. Shock!
Emails kept blipping….etc.
This was an intelligent explanation that GoDaddy staff needs to understand. Ugh!
We will now look at the German company. GoDaddy, after 20 years, needs to be replaced.
Thanks everyone for a quality conversation and heads up.
Nice – would love to see a sample script that could be run on chron to clean up the areas where extra files gather.
Wow..haven’t heard of this before but when someone gets a warning about their site size now I know all the things I should check. Most of the general things I do already but the hidden stuff is what I need to look at. Thanks
Thanks BJ, interesting article, I have also done cleaning.
I would recommend for anyone considering to learn Linux, a VPS.
For those who may be interested in the data, my hosting is DigitalOcean, 25GB HD, 5US$/mo. The limit of Inodes is not 300,000 but 1,632,000:
~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 124545 377 124168 1% /dev
tmpfs 127000 1009 125991 1% /run
/dev/vda1 1632000 262571 1369429 17% /
tmpfs 127000 1 126999 1% /dev/shm
tmpfs 127000 4 126996 1% /run/lock
tmpfs 127000 16 126984 1% /sys/fs/cgroup
tmpfs 127000 4 126996 1% /run/user/1000
Filesystem 1K-blocks Used Available Use% Mounted on
udev 498180 0 498180 0% /dev
tmpfs 101600 3020 98580 3% /run
/dev/vda1 25671528 10086312 14319716 42% /
tmpfs 508000 0 508000 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 508000 0 508000 0% /sys/fs/cgroup
tmpfs 101600 0 101600 0% /run/user/1000
tmpfs 101600 0 101600 0% /run/user/0