{"id":3824,"date":"2025-12-31T15:48:03","date_gmt":"2025-12-31T12:48:03","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/how-to-avoid-inode-limits-on-shared-hosting\/"},"modified":"2026-11-04T22:30:50","modified_gmt":"2026-11-04T19:30:50","slug":"how-to-avoid-inode-limits-on-shared-hosting","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/how-to-avoid-inode-limits-on-shared-hosting\/","title":{"rendered":"How to Avoid Inode Limits on Shared Hosting"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>On shared hosting, free disk space does not necessarily mean you can create more files: your account may have reached its <strong>inode limit<\/strong>. Hosting inode usage tracks filesystem objects such as files and directories, rather than their size. If your provider enforces a hard inode limit, creating new files \u2014 logs, cache, emails, uploads \u2014 can fail, even when disk space remains. That can break updates, uploads, cron jobs and sometimes even your whole site. The good news: inode problems are usually fixable with smart file management and regular cleanup, without immediately jumping to a bigger plan. In this guide, we\u2019ll explain exactly what inodes are, how to check your usage, what typically fills them up, and a practical, step\u2011by\u2011step cleanup strategy you can repeat every few months. We\u2019ll also look at when it makes sense to offload some data or upgrade to a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> at dchost.com.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_Are_Inodes_and_Why_They_Matter_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">1.<\/span> What Are Inodes and Why They Matter on Shared Hosting<\/a><\/li><li><a href=\"#How_to_Check_Inode_Usage_in_cPanel_and_Other_Panels\"><span class=\"toc_number toc_depth_1\">2.<\/span> How to Check Inode Usage in cPanel and Other Panels<\/a><ul><li><a href=\"#Checking_inode_usage_in_cPanel\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> Checking inode usage in cPanel<\/a><\/li><li><a href=\"#Using_File_Manager_or_SSH_to_investigate_file_counts\"><span class=\"toc_number toc_depth_2\">2.2.<\/span> Using File Manager or SSH to investigate file counts<\/a><\/li><\/ul><\/li><li><a href=\"#Where_to_Investigate_High_Inode_Usage_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">3.<\/span> Where to Investigate High Inode Usage on Shared Hosting<\/a><ul><li><a href=\"#1_Application_and_plugin_cache_folders\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> 1. Application and plugin cache folders<\/a><\/li><li><a href=\"#2_Old_backups_stored_inside_your_account\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> 2. Old backups stored inside your account<\/a><\/li><li><a href=\"#3_Email_accounts_and_never-cleaned_mailboxes\"><span class=\"toc_number toc_depth_2\">3.3.<\/span> 3. Email accounts and never-cleaned mailboxes<\/a><\/li><li><a href=\"#4_Logs_temporary_files_and_session_files\"><span class=\"toc_number toc_depth_2\">3.4.<\/span> 4. Logs, temporary files and session files<\/a><\/li><li><a href=\"#5_Abandoned_test_sites_and_old_app_versions\"><span class=\"toc_number toc_depth_2\">3.5.<\/span> 5. Abandoned test sites and old app versions<\/a><\/li><\/ul><\/li><li><a href=\"#StepbyStep_Cleanup_Safely_Reducing_Inode_Count\"><span class=\"toc_number toc_depth_1\">4.<\/span> Step\u2011by\u2011Step Cleanup: Safely Reducing Inode Count<\/a><ul><li><a href=\"#Step_1_Take_a_fresh_backup_but_store_it_smartly\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> Step 1: Take a fresh backup (but store it smartly)<\/a><\/li><li><a href=\"#Step_2_Clean_application_caches_the_proper_way\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Step 2: Clean application caches the proper way<\/a><\/li><li><a href=\"#Step_3_Remove_obsolete_local_backups_and_backup_copies\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> Step 3: Remove obsolete local backups and backup copies<\/a><\/li><li><a href=\"#Step_4_Archive_or_delete_abandoned_test_sites\"><span class=\"toc_number toc_depth_2\">4.4.<\/span> Step 4: Archive or delete abandoned test sites<\/a><\/li><li><a href=\"#Step_5_Tidy_up_logs_and_debugging_leftovers\"><span class=\"toc_number toc_depth_2\">4.5.<\/span> Step 5: Tidy up logs and debugging leftovers<\/a><\/li><li><a href=\"#Step_6_Clean_email_folders_and_set_retention_policies\"><span class=\"toc_number toc_depth_2\">4.6.<\/span> Step 6: Clean email folders and set retention policies<\/a><\/li><li><a href=\"#Step_7_Remove_unused_themes_plugins_and_modules\"><span class=\"toc_number toc_depth_2\">4.7.<\/span> Step 7: Remove unused themes, plugins and modules<\/a><\/li><\/ul><\/li><li><a href=\"#Prevent_Hitting_Inode_Limits_Again_Ongoing_Hygiene\"><span class=\"toc_number toc_depth_1\">5.<\/span> Prevent Hitting Inode Limits Again: Ongoing Hygiene<\/a><ul><li><a href=\"#Schedule_a_simple_quarterly_cleanup_routine\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> Schedule a simple quarterly cleanup routine<\/a><\/li><li><a href=\"#Configure_backups_for_low_inode_impact\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> Configure backups for low inode impact<\/a><\/li><li><a href=\"#Keep_an_eye_on_plugins_and_extensions\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> Keep an eye on plugins and extensions<\/a><\/li><li><a href=\"#Educate_mailbox_users_about_storage_habits\"><span class=\"toc_number toc_depth_2\">5.4.<\/span> Educate mailbox users about storage habits<\/a><\/li><li><a href=\"#Monitor_other_resource_limits_too\"><span class=\"toc_number toc_depth_2\">5.5.<\/span> Monitor other resource limits too<\/a><\/li><\/ul><\/li><li><a href=\"#When_Its_Time_to_Move_Beyond_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">6.<\/span> When It\u2019s Time to Move Beyond Shared Hosting<\/a><\/li><li><a href=\"#Wrapping_Up_Make_Inode_Management_a_Routine_Not_a_Crisis\"><span class=\"toc_number toc_depth_1\">7.<\/span> Wrapping Up: Make Inode Management a Routine, Not a Crisis<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_Are_Inodes_and_Why_They_Matter_on_Shared_Hosting\">What Are Inodes and Why They Matter on Shared Hosting<\/span><\/h2>\n<p>On Linux-based hosting (including most shared hosting platforms), every file and directory is represented by an <strong>inode<\/strong>. Think of an inode as a filesystem record holding metadata about a file or directory. Whether a regular file is 0 bytes or 50 MB, it still uses <strong>one inode<\/strong>; hard links to that same file share its inode.<\/p>\n<p>That leads to an important detail: <strong>inode limits are about quantity, not size<\/strong>. You can have an account that uses only 2 GB of disk, but still hits the inode limit because it holds hundreds of thousands of tiny cache files, emails or logs.<\/p>\n<p>On shared hosting, providers set inode limits to:<\/p>\n<ul>\n<li>Keep file systems fast and healthy for everyone on the server<\/li>\n<li>Prevent one account from creating millions of small files and affecting backups<\/li>\n<li>Limit uncontrolled file growth from malware, misconfigured scripts or runaway cron jobs<\/li>\n<\/ul>\n<p>If an enforced inode limit prevents new file creation, you may see symptoms like those below. These errors can also have other causes, so confirm inode usage and the applicable limit before treating cleanup as the solution:<\/p>\n<ul>\n<li>WordPress or application updates failing with \u201ccould not copy file\u201d errors<\/li>\n<li>New email messages not being stored in mailboxes<\/li>\n<li>Backups failing because new archive files cannot be created<\/li>\n<li>File uploads in WordPress, Laravel or custom apps randomly failing<\/li>\n<\/ul>\n<p>So avoiding inode limits is not just a \u201cquota game\u201d; it\u2019s about <strong>keeping your hosting account stable and predictable<\/strong>.<\/p>\n<h2><span id=\"How_to_Check_Inode_Usage_in_cPanel_and_Other_Panels\">How to Check Inode Usage in cPanel and Other Panels<\/span><\/h2>\n<p>Before cleaning anything, establish how many inodes you are using and where. Panel features and labels depend on the provider. DirectAdmin also supports inode tracking and limits, but do not assume it uses cPanel\u2019s menu paths. In any panel, look for an explicitly labelled inode or file-usage statistic; if it is absent, ask your provider for the count, limit and directories included.<\/p>\n<h3><span id=\"Checking_inode_usage_in_cPanel\">Checking inode usage in cPanel<\/span><\/h3>\n<p>If your shared hosting uses cPanel, you will typically find inode usage here:<\/p>\n<ul>\n<li><strong>cPanel dashboard &gt; Statistics<\/strong>: look for \u201cFile Usage\u201d. It is visible only when your provider enables it; distributed accounts may show \u201cLocal File Usage\u201d for the local server.<\/li>\n<li><strong>cPanel &gt; Disk Usage<\/strong>: use this to investigate disk space, not as a substitute for a file count. If inode usage is not displayed, ask your provider for the account total and limit.<\/li>\n<\/ul>\n<p>Compare usage and the inode limit only when they cover the same scope. For a distributed cPanel account, Local File Usage excludes files on the child node; ask your provider how to obtain that usage and which quota applies. Confirm any missing limit or unclear scope before calculating a percentage. For example, 185,000 files and directories against a 200,000 limit covering those same files is 92.5% usage. This is an illustrative calculation, not a guaranteed panel display. Start cleanup while sufficient headroom remains for expected growth, updates and backups; 80\u201390% can be an early planning signal, not a universal failure threshold.<\/p>\n<h3><span id=\"Using_File_Manager_or_SSH_to_investigate_file_counts\">Using File Manager or SSH to investigate file counts<\/span><\/h3>\n<p>Even if you don\u2019t have full SSH (or don\u2019t feel comfortable using it), you can still identify inode-heavy directories:<\/p>\n<ul>\n<li>Open <strong>cPanel &gt; File Manager<\/strong><\/li>\n<li>Inspect main folders (like <code>public_html<\/code>, <code>logs<\/code>, <code>mail<\/code>) for large collections of files; use recursive file counts if your panel provides them<\/li>\n<li>Inspect likely high-count directories, such as cache folders; sorting by file size alone can miss thousands of tiny files<\/li>\n<\/ul>\n<p>If you do have SSH access and basic Linux familiarity, you can run commands like:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd ~\/public_html || exit\nfind . | wc -l\n\n# or per subdirectory\nfind wp-content -maxdepth 2 -type d -print0 | \n  xargs -0 -I{} sh -c &#039;printf &quot;%s: &quot; &quot;$1&quot;; find &quot;$1&quot; | wc -l&#039; sh &#039;{}&#039;\n<\/code><\/pre>\n<p>These commands only read directory listings. They estimate file and directory counts under <code>public_html<\/code>, not account-wide inode usage: mail and other directories may be elsewhere. Hard links, filenames containing newlines and inaccessible directories can make the counts differ from actual inode usage. The second command is WordPress-specific; each total includes descendants, so overlapping totals must not be added together.<\/p>\n<h2><span id=\"Where_to_Investigate_High_Inode_Usage_on_Shared_Hosting\">Where to Investigate High Inode Usage on Shared Hosting<\/span><\/h2>\n<p>The following categories are useful places to investigate high inode usage. Identify what each directory contains before deciding whether it is safe to clean. Do not delete live application core files, configuration files or required dependencies to reduce the count. Large <code>vendor<\/code>, <code>node_modules<\/code> and <code>.git<\/code> directories may support runtime or deployment requirements; check those requirements before removing anything. If usage rises suddenly alongside unexpected PHP files in upload directories or many unexplained files, investigate a possible compromise rather than treating the files as ordinary cleanup candidates.<\/p>\n<h3><span id=\"1_Application_and_plugin_cache_folders\">1. Application and plugin cache folders<\/span><\/h3>\n<p>CMSs and frameworks can generate many files when configured to use file-based caching:<\/p>\n<ul>\n<li><strong>WordPress<\/strong>: <code>wp-content\/cache\/<\/code>, file-based page caches, page builder caches<\/li>\n<li><strong>Magento \/ PrestaShop<\/strong>: version-dependent locations such as <code>var\/cache<\/code> or <code>cache\/<\/code> directories<\/li>\n<li><strong>Laravel and other frameworks<\/strong>: <code>storage\/framework\/cache<\/code>, compiled views, sessions<\/li>\n<\/ul>\n<p>If expired cache entries are not cleaned up, file counts can grow quickly, especially on busy stores or sites with thousands of URLs and multiple cached variants. Session files need separate care: follow the application\u2019s session-expiry and cleanup guidance rather than treating active sessions as disposable cache.<\/p>\n<h3><span id=\"2_Old_backups_stored_inside_your_account\">2. Old backups stored inside your account<\/span><\/h3>\n<p>Check for retained backups under <code>public_html<\/code> or in a <code>backup<\/code> folder, including:<\/p>\n<ul>\n<li>Full cPanel backups generated manually and never removed<\/li>\n<li>WordPress backup plugins (UpdraftPlus, Duplicator, etc.) storing dozens of archives locally<\/li>\n<li>Per-day or per-week database dumps saved in a subdirectory by cron<\/li>\n<\/ul>\n<p>Each backup archive might contain tens of thousands of files, but <strong>one archive file uses one inode<\/strong>; its contents do not count separately unless extracted. Archives therefore usually consume far more disk space than inodes. A backup process that stages separate file copies can temporarily use many inodes, and each archive chunk or unpacked backup file also uses an inode.<\/p>\n<p>We have a dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-backup-strategies-for-shared-hosting-and-vps\/\">WordPress backup strategies for shared hosting and VPS<\/a> if you want a deeper backup design.<\/p>\n<h3><span id=\"3_Email_accounts_and_never-cleaned_mailboxes\">3. Email accounts and never-cleaned mailboxes<\/span><\/h3>\n<p>If you host email on the same shared account using <strong>Maildir storage, each message is normally a separate file using an inode<\/strong>. Other mailbox formats have different file-count characteristics. Over years, especially with IMAP and many folders, mail storage can easily hit hundreds of thousands of files per domain.<\/p>\n<p>Large <code>Sent<\/code>, <code>Trash<\/code> and <code>Spam<\/code> folders are common culprits, especially when users never archive old messages or configure automatic cleanup rules.<\/p>\n<h3><span id=\"4_Logs_temporary_files_and_session_files\">4. Logs, temporary files and session files<\/span><\/h3>\n<p>Many apps and libraries write logs by default:<\/p>\n<ul>\n<li>PHP error logs, application logs, access logs kept for months<\/li>\n<li>Debug logs from plugins, staging tools, or payment integrations<\/li>\n<li>Session files stored on disk instead of Redis\/Memcached<\/li>\n<\/ul>\n<p>On shared hosting, you often don\u2019t control system-wide logs, but you can control logs under your home directory (like <code>public_html\/error_log<\/code> or <code>storage\/logs\/<\/code>). Some of these logs can grow both in size and number of files.<\/p>\n<h3><span id=\"5_Abandoned_test_sites_and_old_app_versions\">5. Abandoned test sites and old app versions<\/span><\/h3>\n<p>Look for unused copies such as:<\/p>\n<ul>\n<li>Multiple old copies of the same WordPress site (e.g., <code>oldsite\/<\/code>, <code>backup-2022\/<\/code>, <code>test\/<\/code>)<\/li>\n<li>Previous versions of a Laravel or custom PHP app left on disk \u201cjust in case\u201d<\/li>\n<li>Staging subdomains that were never cleaned up<\/li>\n<\/ul>\n<p>Each of these may be a full copy of your application \u2014 thousands of files you don\u2019t actually need in production.<\/p>\n<h2><span id=\"StepbyStep_Cleanup_Safely_Reducing_Inode_Count\">Step\u2011by\u2011Step Cleanup: Safely Reducing Inode Count<\/span><\/h2>\n<p>Here\u2019s a practical cleanup routine for shared hosting accounts before considering a change of plan. Take it slowly, and always keep at least one recent backup.<\/p>\n<h3><span id=\"Step_1_Take_a_fresh_backup_but_store_it_smartly\">Step 1: Take a fresh backup (but store it smartly)<\/span><\/h3>\n<p>Before deleting anything, secure a current backup. If the account is already at its inode limit, creating a local backup may fail or exhaust the remaining headroom. In that case, copy files directly to off-account storage and export databases there, or ask your provider for backup assistance. Keep any temporary local archive outside the public web root, and do not leave it in the inode-limited account indefinitely.<\/p>\n<ul>\n<li>Use your control panel\u2019s backup tool or a WordPress\/plugin backup if there is sufficient headroom. Include the files and databases you will change; a site-only backup may not include email.<\/li>\n<li>Download the backup to your computer.<\/li>\n<li>Delete the backup file from the hosting account only after verifying that the downloaded archive is readable and contains the required data.<\/li>\n<\/ul>\n<p>If you\u2019re planning a more advanced strategy, you can later move to off-site backups using object storage. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/object-storage-backups\/\">automating off-site backups to object storage with rclone and restic<\/a> shows one approach that avoids filling your shared account with archives.<\/p>\n<h3><span id=\"Step_2_Clean_application_caches_the_proper_way\">Step 2: Clean application caches the proper way<\/span><\/h3>\n<p>Avoid manually deleting cache folders from File Manager unless you know what you\u2019re doing; some apps may recreate them incorrectly or throw permissions errors. Instead:<\/p>\n<ul>\n<li><strong>WordPress<\/strong>: use your cache plugin\u2019s \u201cClear all cache\u201d \/ \u201cPurge all\u201d button. If using LiteSpeed Cache on a LiteSpeed server, use its built-in purge tools.<\/li>\n<li><strong>WooCommerce or Magento<\/strong>: use the cache controls documented for your platform and installed caching extensions; menu locations vary.<\/li>\n<li><strong>Laravel<\/strong>: if you have SSH, select the commands appropriate to your deployed application, such as <code>php artisan cache:clear<\/code>, <code>php artisan config:clear<\/code>, <code>php artisan view:clear<\/code>. Follow your version-specific deployment instructions, including any required cache rebuilding, rather than running every command indiscriminately.<\/li>\n<\/ul>\n<p>After purging caches, re-check inode usage in cPanel once its statistics refresh. The reduction depends on how many cache files were removed, and caches may rebuild as visitors use the site.<\/p>\n<p>If your site is cache-heavy or uses page builders, consider reading our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-performance-for-elementor-divi-and-page-builders\/\">hosting performance for Elementor, Divi and other page builders<\/a>; good caching strategy is part performance, part resource management, including inode usage.<\/p>\n<h3><span id=\"Step_3_Remove_obsolete_local_backups_and_backup_copies\">Step 3: Remove obsolete local backups and backup copies<\/span><\/h3>\n<p>Next, look for leftover backup archives:<\/p>\n<ul>\n<li>Search for files with names like <code>*backup*<\/code>, <code>*old*<\/code>, <code>*-copy*<\/code>, <code>.zip<\/code>, <code>.tar.gz<\/code>, <code>.sql<\/code>.<\/li>\n<li>Check typical plugin backup directories (e.g., <code>wp-content\/updraft\/<\/code>, <code>wp-content\/backups\/<\/code>).<\/li>\n<li>Look at root-level directories like <code>backup\/<\/code>, <code>OLD_SITE\/<\/code>, <code>site-2021\/<\/code>.<\/li>\n<\/ul>\n<p>Rules of thumb:<\/p>\n<ul>\n<li>Keep only the recent local backups your recovery plan requires (for example, 1\u20133), <strong>stored outside<\/strong> your web root. Moving them within the same account does not reduce its inode usage.<\/li>\n<li>Delete obsolete copies only after verifying that the backups you retain can be restored and meet your retention needs.<\/li>\n<li>For long-term archives, transfer them to your local machine or off-site storage and verify the transfer before removing the hosting copy.<\/li>\n<\/ul>\n<p>Some backup plugins store data as many small chunks. Removing obsolete backup sets can reduce inode usage, but use the backup tool\u2019s retention or deletion controls rather than deleting individual chunks that retained backups may still need.<\/p>\n<h3><span id=\"Step_4_Archive_or_delete_abandoned_test_sites\">Step 4: Archive or delete abandoned test sites<\/span><\/h3>\n<p>If you have multiple test\/staging copies inside the same account:<\/p>\n<ul>\n<li>List all subdirectories under your home or <code>public_html<\/code> (e.g., <code>test\/<\/code>, <code>old\/<\/code>, <code>backup-2020\/<\/code>).<\/li>\n<li>Check each candidate site\u2019s owner, domain mapping, scheduled jobs and dependencies to confirm it is no longer needed; visiting its URL alone cannot establish this.<\/li>\n<li>For sites you no longer need, back up the files and any required databases, verify the downloaded backup, then delete only the confirmed site directory\u2014not an account or system directory.<\/li>\n<\/ul>\n<p>If you want to keep them for reference but not as live code, consider compressing them into <code>.zip<\/code> or <code>.tar.gz<\/code> archives. A single archive file normally uses one inode, regardless of how many files it contains. Creating it does not free the source files\u2019 inodes: verify the archive before removing the original directory. Allow enough free disk space and inode headroom for archive creation and any temporary files. If local headroom is insufficient, use the off-account backup approach from Step 1. Keep retained archives outside the web root or off-site.<\/p>\n<h3><span id=\"Step_5_Tidy_up_logs_and_debugging_leftovers\">Step 5: Tidy up logs and debugging leftovers<\/span><\/h3>\n<p>Search for large or numerous log files in your account. Large files consume disk space, but inode usage depends on file count, not file size:<\/p>\n<ul>\n<li>Common names: <code>error_log<\/code>, <code>debug.log<\/code>, <code>laravel.log<\/code>, <code>system.log<\/code>, <code>exception.log<\/code>.<\/li>\n<li>Check directories like <code>wp-content\/<\/code>, <code>storage\/logs\/<\/code>, and root-level log files.<\/li>\n<\/ul>\n<p>After identifying which logs are active and which must be retained, you can:<\/p>\n<ul>\n<li>Download logs needed for analysis or retention and verify the copy before deleting them<\/li>\n<li>Delete only obsolete, inactive log files. For a log still being written, use supported rotation controls or ask the host; deleting an open log may not free its inode or disk space until the writer closes it.<\/li>\n<li>Disable verbose debugging modes in <code>wp-config.php<\/code> or app config files if they are no longer needed<\/li>\n<\/ul>\n<p>On VPS servers we recommend proper log rotation with <code>logrotate<\/code>; we even have a full article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-disk-full-errors-logrotate\/\">VPS disk usage and logrotate to prevent disk errors<\/a>. On shared hosting you won\u2019t have full control, but you can still manage logs under your own directories.<\/p>\n<h3><span id=\"Step_6_Clean_email_folders_and_set_retention_policies\">Step 6: Clean email folders and set retention policies<\/span><\/h3>\n<p>Email often remains invisible until you inspect the <code>mail\/<\/code> directory in File Manager or cPanel\u2019s Email Disk Usage tool. To reduce inode usage from mail, use webmail, an email client or the panel\u2019s mail-cleanup tools rather than deleting mailbox files directly. Apply retention requirements before removing messages:<\/p>\n<ul>\n<li>Ask mailbox users to empty large <code>Trash<\/code>, <code>Spam<\/code> and <code>Junk<\/code> folders.<\/li>\n<li>Delete very old messages from <code>Sent<\/code> and large custom folders.<\/li>\n<li>Configure automatic cleanup in email clients (e.g., delete Trash older than X days).<\/li>\n<li>For long-term archiving, copy old mail to a local archive or dedicated email archiving system, verify that it is readable and backed up, then remove the server copies permitted by your retention policy.<\/li>\n<\/ul>\n<p>Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/email-archiving-and-legal-retention-on-cpanel-and-vps\/\">email archiving and legal retention on cPanel and VPS<\/a> explains how to design sustainable e\u2011mail storage so that your main hosting account doesn\u2019t become a permanent archive for everything.<\/p>\n<h3><span id=\"Step_7_Remove_unused_themes_plugins_and_modules\">Step 7: Remove unused themes, plugins and modules<\/span><\/h3>\n<p>Each plugin, theme or module is typically a folder with dozens or hundreds of files. On WordPress and other CMSs:<\/p>\n<ul>\n<li>Delete themes you no longer need, but retain any parent theme required by the active theme and any maintained fallback theme you intend to keep.<\/li>\n<li>Remove deactivated plugins that you don\u2019t plan to use again.<\/li>\n<li>In other platforms, remove unused extensions or modules from their admin panels.<\/li>\n<\/ul>\n<p>This not only reduces inode count but also shrinks your attack surface. We discuss this in more depth in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-security-on-shared-hosting\/\">WordPress security on shared hosting<\/a>, where unused plugins and themes are a common security weakness.<\/p>\n<h2><span id=\"Prevent_Hitting_Inode_Limits_Again_Ongoing_Hygiene\">Prevent Hitting Inode Limits Again: Ongoing Hygiene<\/span><\/h2>\n<p>Once you\u2019ve done a first deep cleanup and brought inode usage down, the next step is to stop it from climbing back up quickly. A bit of regular hygiene goes a long way.<\/p>\n<h3><span id=\"Schedule_a_simple_quarterly_cleanup_routine\">Schedule a simple quarterly cleanup routine<\/span><\/h3>\n<p>Use a quarterly review as a starting point, not a guaranteed safe interval. Monitor more often if file counts grow quickly or headroom is low. Repeat a quick version of the steps above, retaining their backup and deletion safeguards:<\/p>\n<ul>\n<li>Check inode usage in your control panel and note the trend.<\/li>\n<li>Clear caches via admin tools.<\/li>\n<li>Delete old backups and logs.<\/li>\n<li>Review email usage and clean large folders.<\/li>\n<\/ul>\n<p>Set a calendar reminder so this becomes routine, not a crisis response when inode usage reaches your plan\u2019s limit.<\/p>\n<h3><span id=\"Configure_backups_for_low_inode_impact\">Configure backups for low inode impact<\/span><\/h3>\n<p>Instead of keeping many backup copies inside your shared hosting account, aim for:<\/p>\n<ul>\n<li>Only the recent local backups your recovery plan requires (for example, 1\u20133), rotated regularly and kept outside the web root.<\/li>\n<li>Primary long-term backups stored off-site (object storage, another server, or your own device), with readability and recovery checks.<\/li>\n<\/ul>\n<p>Where your application and hosting plan support it, offloading backups and media files to object storage can reduce local storage needs and serving I\/O. Inode savings depend on how many local files are removed, not their size; uploading copies while retaining the originals does not free local inodes. Before removing local media, verify the transfer, media links and the application\u2019s need for local files, then use the offload tool\u2019s supported removal method. Verify backup readability and recovery requirements before removing local backup copies. If you\u2019re curious about that approach, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/s3-minio-media-offload-for-wordpress-woocommerce-and-magento\/\">offloading WordPress and e\u2011commerce media to S3\/MinIO-compatible object storage<\/a>.<\/p>\n<h3><span id=\"Keep_an_eye_on_plugins_and_extensions\">Keep an eye on plugins and extensions<\/span><\/h3>\n<p>Before installing a new plugin or extension, ask:<\/p>\n<ul>\n<li>Does it create its own cache or log directory?<\/li>\n<li>Can you configure retention or auto-clean features?<\/li>\n<li>Is it actively maintained and efficient, or does it tend to leave junk files behind?<\/li>\n<\/ul>\n<p>Choosing well-maintained plugins and configuring their cache and log retention can help limit inode growth. Keep a reviewed set of necessary plugins so their file-generation and cleanup behavior remains manageable.<\/p>\n<h3><span id=\"Educate_mailbox_users_about_storage_habits\">Educate mailbox users about storage habits<\/span><\/h3>\n<p>If your team uses the same shared hosting account for email, brief them on simple habits:<\/p>\n<ul>\n<li>Regularly empty Trash and Spam when retention requirements permit.<\/li>\n<li>Plan which messages must remain in live IMAP mailboxes and which can be archived.<\/li>\n<li>For long-term retention, use a local or dedicated archive that meets your access, backup and retention needs; verify it before removing server copies.<\/li>\n<\/ul>\n<p>This may sound like a small thing, but over a few years it can be the difference between a clean account and one that regularly bumps into inode ceilings.<\/p>\n<h3><span id=\"Monitor_other_resource_limits_too\">Monitor other resource limits too<\/span><\/h3>\n<p>Monitor CPU, RAM and I\/O limits separately from inode usage. A high file count alone does not show whether PHP or MySQL is overloaded at peak times. We have a separate article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/fix-resource-limit-reached\/\">avoiding the \u201cResource Limit Reached\u201d error on shared hosting<\/a>, which pairs nicely with this inode-focused guide.<\/p>\n<h2><span id=\"When_Its_Time_to_Move_Beyond_Shared_Hosting\">When It\u2019s Time to Move Beyond Shared Hosting<\/span><\/h2>\n<p>Even with careful cleanup, some projects simply outgrow shared hosting. Typical signs include:<\/p>\n<ul>\n<li>You hit inode limits every few months despite regular hygiene.<\/li>\n<li>You host many websites (agency, freelancer, or multi\u2011project account) on one shared plan.<\/li>\n<li>Your application generates lots of logs, cache files or uploads by design (e.g., big WooCommerce store, LMS, media-heavy site).<\/li>\n<\/ul>\n<p>In these cases, a VPS or dedicated server may offer more storage-management flexibility, depending on the plan, administrative access and filesystem. When comparing options, look for the ability to:<\/p>\n<ul>\n<li>Plan disk capacity and inode capacity for your workload.<\/li>\n<li>Use advanced tools like <code>logrotate<\/code>, Redis\/Memcached, and external object storage.<\/li>\n<li>Separate high-churn data (logs, cache, sessions) from your main web root.<\/li>\n<\/ul>\n<p>If you are worried about downtime during migration, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/shared-hosting-to-vps-sizing-and-migration\/\">moving from shared hosting to a VPS without downtime<\/a> walks through a calm, step\u2011by\u2011step plan: staging, DNS changes, and cutover strategies.<\/p>\n<p>One possible approach is a hybrid: keep small, low\u2011traffic sites on shared hosting, and place busy, file-heavy or mission-critical projects on a managed VPS or dedicated server.<\/p>\n<h2><span id=\"Wrapping_Up_Make_Inode_Management_a_Routine_Not_a_Crisis\">Wrapping Up: Make Inode Management a Routine, Not a Crisis<\/span><\/h2>\n<p>Inode limits matter alongside disk space and bandwidth because file count can prevent new file creation even when storage space remains. Start by checking your account\u2019s usage and quota scope, then identify where files accumulate: caches, unpacked backups, mail, logs and old site copies. A careful initial cleanup, followed by a quarterly review and more frequent monitoring when growth or limited headroom warrants it, can reduce the risk of inode-related failures during updates or busy seasons. Focus on removing confirmed unnecessary files, not simply the largest ones.<\/p>\n<p>If you regularly hit inode ceilings even after cleanup, review both file-generation behavior and whether your plan fits the workload. Before moving your busiest sites to a VPS or dedicated server, verify that the arrangement provides suitable inode and disk capacity and the control you need over storage, logs, caching and backups. Whether you stay on shared hosting or plan a gradual upgrade, treating inode management as part of normal maintenance\u2014alongside backups and updates\u2014can help reduce troubleshooting time, support tickets and the risk of inode-related downtime.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Free disk space does not prevent inode-limit errors. Check file usage, identify high-count directories, follow a backup-first cleanup routine and assess when shared hosting no longer fits.<\/p>\n","protected":false},"author":1,"featured_media":13041,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[184],"tags":[],"class_list":["post-3824","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3824","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3824"}],"version-history":[{"count":7,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3824\/revisions"}],"predecessor-version":[{"id":13043,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3824\/revisions\/13043"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/13041"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3824"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3824"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3824"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}