Diagnosing inode exhaustion on a Linux VPS

A VPS can still show free space on its SSD while refusing to create a file. In that case, the problem sometimes comes from inodes rather than the capacity in gigabytes. This guide helps an administrator diagnose a Linux virtual server accessible over SSH, then clean it up without deleting useful data.

Understanding inodes

A filesystem associates metadata with every file and directory. These entries are called inodes. The volume's capacity and the number of inodes are two different limits: a volume can therefore have gigabytes available while all its entries are used up. Small files, logs and caches can accelerate this exhaustion.

Possible symptoms are a file creation error, a service that no longer starts or a game server that can no longer write its logs. These signs are not enough to conclude: you must measure both resources, as you would for CPU, RAM and disk space.

Checking space and inodes

Connect over SSH with an administration account on your Linux distribution, for example Debian or Ubuntu. Use a root account only when necessary and keep your backups before a maintenance operation:

df -h
df -i

In the output of df -i, look at the usage column and the mount point. A value close to 100% confirms that the volume is running out of inodes. If inodes are available but df -h shows a full volume, the diagnosis is different and you must look for large files. The IP address, the SSH password and the private keys must never be published in a report.

Locating the directories that hold too many files

Start with the locations suited to your installation. This command counts the first-level entries of the root filesystem:

for d in /*; do
  [ -d "$d" ] || continue
  printf "%s : " "$d"
  find "$d" -xdev -mindepth 1 -maxdepth 1 2>/dev/null | wc -l
done

Then drill down into the suspect directory. On a game server, inspect notably the server folder, the logs and the backups, without deleting blindly. To spot the subdirectories holding many entries:

find /chemin/du/serveur -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -nr | head -20

Adapt the path to your installation. Searching with -xdev avoids crossing another filesystem mounted at that location. A control panel or a managed-services tool can display the usage, but measuring with df remains useful to confirm the mount point actually used.

Cleaning up without interrupting the server

First identify the retention policy for logs, temporary files and backups. Stop the concerned service cleanly before deleting a file that is still open, and keep a recent backup if it is needed for your recovery. Never delete a system directory or a configuration file only because it appears in a count.

Prudent actions consist of archiving or purging logs according to their planned rotation, removing regenerable caches and deleting only expired backups according to a known rule. After each action, check again:

df -h
df -i

If a deleted file keeps occupying space, a process may still hold it open. Identify the open deleted files with a suitable administration tool, then restart only the concerned service according to your maintenance procedure. Also check that the firewall and permissions do not prevent the service from restarting.

Preventing a new exhaustion

Monitor inodes in addition to disk space. Set an alert threshold, check the logs regularly and avoid scripts that create one file per event without rotation or limit. Log rotation, documented backup retention and a check after updates reduce the risk.

On a virtual server, RAM, CPU and SSD I/O also influence overall behavior, but they do not replace inode checking. A host may provide metrics or a panel, without that removing the need to check the filesystem from Linux. Useful monitoring tracks at least storage space, inodes, CPU load, memory and the state of services.

In a VPS plan, the virtual machine shares an infrastructure with other virtual servers, while a dedicated physical server reserves its resources for a single customer. This virtualization difference does not change the df -i command: inodes remain a limit of the filesystem mounted in your environment.

Choosing a virtual dedicated server or a cloud VPS can change the available resources, bandwidth, processor and redundancy options, but none of these parameters automatically creates additional inodes. The operating system, the storage type and how the volume is mounted still need to be checked before concluding that a plan change will solve the problem.

For a game server, document the data paths, the shutdown commands and the retention duration. This documentation makes cleanup safer during an alert and eases a migration to another Linux VPS if the load evolves. It also helps assess whether a VPS plan, a dedicated server or a cloud architecture suits the amount of data and the level of high availability you need.

When to ask for help

Ask for an analysis before any deletion if the mount point is unknown, if several services share the volume or if the files belong to a container. To prepare your diagnosis, note the outputs of df -h, df -i, the concerned path and the time the problem appeared, without transmitting any secret.

You can also compare this diagnosis with our open file limit guide: this limit is different from inodes, even if the symptoms can look alike. For other network outages, see the diagnosis of an unreachable VPS.

To go further in operations, also see our guides on Docker on a VPS, securing a server and Pterodactyl backups.