Record the failing application path and filesystem. Keep current incident evidence and identify the owner of any candidate cleanup directory. Do not assume that small files are disposable just because there are many of them.

1. Compare df -h and df -i for the affected mount. A near-exhausted inode count with available blocks points toward file-count pressure.
2. Use a bounded directory investigation on that filesystem. Tools such as GNU du --inodes -x can locate file-heavy subtrees when supported, but large scans themselves consume I/O.
3. Determine whether the files are valid retained data, expired sessions, cache, a runaway queue or an application bug. Use the application's supported expiry/cleanup tool where available.
4. Pause the source of abnormal creation and remove only an explicitly reviewed obsolete set. Avoid a broad recursive deletion or wildcard across a live mailbox or application storage tree.
5. Recheck inode availability, restore the affected service and configure a retention/cleanup policy that keeps file counts within the filesystem design.

On the affected Linux server, replace /var with the full filesystem or a suspected directory on it. GNU du can count file entries instead of bytes. The scan is read-only but may be expensive when the directory contains millions of small files.

df -i /var
sudo du --inodes -x -d1 /var

Read the result: An inode use figure near 100 percent explains why new files fail even when gigabytes remain free. The du output helps locate high-count directories such as sessions, cache objects or mail queues. Its totals describe the accessible directory tree, so permissions and filesystem behaviour can affect what it sees.

Apply the owning application's retention or cleanup procedure after identifying the files. Do not recursively delete session, queue or mailbox directories just because they contain many entries. Confirm the count falls and the original write operation succeeds afterwards.

It depends on the filesystem and expansion method. Confirm its behavior before assuming capacity growth fixes a file-count limit, and correct uncontrolled file creation in any case.

Confirm a new harmless file can be created and removed by the application account. Check that cleanup did not break active sessions, queued work or customer data. Monitor inode consumption separately from disk bytes so the same incident is detected earlier.

If cleanup makes no difference, confirm you inspected the actual mounted filesystem and have permission to see its contents. Some filesystem formats allocate inodes differently, so do not apply an ext4-specific remedy universally. A long-term rebuild or migration may be appropriate for workloads whose file count exceeds the original filesystem design.

• Recovering service when a Linux filesystem is full
• Configuring log rotation for a custom Linux application
• Testing a Linux server restore before an emergency
• Finding deleted files that still consume disk space

• Debian manual: Df.1.en
• Debian manual: Du.1.en
• Debian manual: Mke2fs.8.en