Inode Limits on Shared Hosting: How to Clean Up Files

A shared-hosting account can stop accepting uploads while its disk usage still looks comfortable. The missing resource is often the inode allowance: the host limits how many filesystem objects your account can contain, not just how many bytes it stores.

This walkthrough shows how to locate the directories responsible, distinguish disposable data from essential files, and reclaim capacity without breaking media URLs or deleting your only backup.

Understand the limit before deleting anything

An inode stores metadata about a filesystem object. Regular files and directories generally consume inodes; hard links share an inode with their target. Hosting dashboards may report an account-specific file count rather than raw filesystem allocation, so the provider's definition is the one that controls your allowance.

Image-heavy sites frequently accumulate generated variants: thumbnails, alternate formats, and plugin-specific crops. Use the Image Dimension Resizer Calculator below to calculate proportional dimensions and plan a smaller responsive-image set. It does not scan hosting accounts or count files; it helps prevent unnecessary variants after you identify image growth.

Record the current count, the enforced limit, and any warning threshold. Ask whether mailboxes, staging sites, and backups count toward the same total. A full account can disrupt sessions and email as well as uploads, making a modest safety margin operationally important.

Measure directory growth without changing files

Start with the control panel's file-usage report. If SSH is available, these GNU/Linux commands provide a second view. Run them as your account user, not root, and expect large trees to take time to scan.

# Filesystem-wide inode availability, not your account quota:
df -i "$HOME"
# Inodes used under this account, without crossing filesystems:
du --inodes -x --max-depth=2 "$HOME" 2>/dev/null | sort -n | tail -20
# Compare with byte usage:
du -h -x --max-depth=2 "$HOME" 2>/dev/null | sort -h | tail -20

The distinction between filesystem capacity and account quota matters. A healthy result from df -i cannot prove that your hosting allowance has space. Conversely, a shared filesystem can be exhausted even when your account is under its published limit.

The --inodes option is a GNU extension and may be missing on restricted shells. Use the panel report or request a directory-level count from support instead of installing tools on an account you do not administer. Consult the GNU Coreutils manual for command behavior.

Compare the largest directories with their purpose. Uploads, cache trees, mail folders, and old deployment directories deserve separate investigation. Permission errors mean the scan is incomplete; do not interpret an incomplete count as proof that the dashboard is wrong.

Save the results outside the account if it is nearly full. A count collected before cleanup makes it possible to measure improvement and detect the same growth pattern later.

Classify files by owner and recovery path

Before cleanup, establish what regenerates each directory. A cache created by an application is different from a directory merely named cache that contains customer uploads. Identify the responsible plugin, job, or deployment script and its supported cleanup mechanism.

• Usually regenerable: documented page caches, obsolete build outputs, and thumbnails that can be recreated from preserved originals.
• Review before removal: expired sessions, rotated logs, staging copies, and application-managed temporary files.
• Preserve unless verified: original uploads, configuration, mail, private keys, current releases, and backups without another tested copy.

For WordPress, start with the official documentation and the relevant plugin's settings. Clear caches through the application when possible. Deleting cache files behind a running process can cause errors or immediately regenerate the same tree.

Check whether a directory contains symlinks or shared content before treating it as an isolated copy. A staging site may use production uploads or the same database. Removing its apparent duplicates without understanding that relationship can damage the live site.

If you need an offsite recovery workflow first, follow the server backup guide. A compressed archive on the same hosting account is not sufficient protection against account loss, and creating it may itself fail when the quota is already exhausted.

Clean one bounded target and verify the result

Use a preview-first process, not a recursive delete across your entire home directory. The following example assumes you have positively identified a disposable application temporary directory, stopped its writer, and checked retention requirements. Replace the path before running it.

TARGET="$HOME/example-app/tmp"
# Preview only regular files older than 14 days:
find "$TARGET" -xdev -type f -mtime +14 -print
# After reviewing the preview and confirming recovery:
find "$TARGET" -xdev -type f -mtime +14 -delete

The age test uses filesystem modification time, not business meaning. A stale-looking file might still be referenced by a live job. Do not apply this example to uploads, database files, mailboxes, or session stores without application-specific guidance. The GNU Findutils manual explains these selection rules and deletion behavior.

After each cleanup, recount the target, check a representative page, and test a new upload. If email shares the quota, send and receive a test message too. Keep changes small enough that a failure points to one specific action rather than a dozen simultaneous deletions.

Deleting an open file removes its directory entry, but its storage and inode may remain allocated until the process closes it. Ask support to investigate if a verified deletion produces no expected improvement. Dashboard updates may also be delayed; record both the measurement time and the measurement source.

Prevent the next file-count surge

Reduce the number of generated image sizes to those the theme actually uses. Changing registered sizes normally affects future uploads; it does not automatically remove old derivatives. Regeneration tools can create more files before removing obsolete ones, so test on staging and confirm their deletion behavior first.

Return to the image sizing calculator to choose intentional widths for cards, article columns, and high-density displays. The responsive image pipeline guide explains how dimension planning fits delivery. Keep originals until you have verified that every required derivative can be rebuilt.

Set bounded retention for caches, logs, local backup copies, and abandoned releases. Cache expiration is not always physical deletion: some systems stop serving an expired entry but leave the file until a cleanup job runs. Verify that scheduled cleanup actually executes on your hosting plan.

Review file counts weekly and after plugin changes or bulk imports. Record both total files and growth by directory. If legitimate content growth consumes the allowance despite disciplined retention, compare plans using explicit inode limits rather than vague unlimited-storage language.

Key takeaways

• Measure both quotas: account file limits and filesystem-wide inode availability answer different questions.
• Preserve recovery options: identify ownership, dependencies, and a tested offsite copy before removing anything important.
• Preview one bounded cleanup, verify application behavior, and compare counts afterward.
• Prevent recurrence with fewer unnecessary image variants, documented retention, and scheduled directory-level reviews.