A Linux application can fail to create a file even when a disk-space dashboard shows free gigabytes. One possible cause is inode exhaustion: the filesystem has run short of the metadata entries needed to represent new files and directories. Start by checking the exact destination filesystem, not by deleting the largest file you can find.
This workflow uses read-only GNU tools commonly available on Ubuntu and other Linux distributions. It separates a capacity diagnosis from a cleanup decision, so you can gather evidence before changing a production service.
1. Check the filesystem containing the failing path
Identify where the application is actually trying to write. A separate mount for logs, application data, or temporary files can be full while your home directory is healthy. Use an existing parent directory if the intended file does not yet exist. For example, if the failure concerns a file under /var/tmp, run:
df -h /var/tmp
df -i /var/tmpThe first command reports block-space usage in readable units. The second switches to inode information. Look at the available count and percentage used, and confirm that both commands refer to the expected mount. The Ubuntu df manual explicitly documents the distinction between ordinary space reporting and the inode option.
Do not interpret a healthy result for /home as proof that /var is healthy. Containers, network storage, and mounted volumes can complicate the picture further. Run the check in the same relevant environment as the failing application whenever possible.
2. Distinguish missing inodes from missing disk blocks
Consider a hypothetical support case: an application cannot create a small cache file, block usage is well below capacity, but the inode report shows no available entries. That pattern supports investigating many small files rather than searching only for large downloads. A directory containing numerous tiny cache objects can consume few bytes per object while still needing a filesystem entry for each one.
Not every filesystem has the same inode-allocation model, and some report inode statistics differently. Treat the output as evidence for that filesystem, not a universal rule about all Linux storage. If both blocks and inodes are available, keep investigating instead of forcing an inode diagnosis. Permissions, quotas, a read-only mount, or an application-specific limit may explain the failure.
3. Locate file-heavy directories without crossing mounts
On GNU du, use inode counting with a shallow directory summary. Substitute the affected mount or a known application subtree:
du --inodes -x --max-depth=1 /varHere, –inodes counts inode usage rather than bytes, -x avoids descending into different filesystems, and –max-depth=1 limits the displayed summary depth. The scan still needs to traverse the included tree; shallow output does not make a large scan free. Run it during an appropriate maintenance window if the tree is huge or storage is busy.
The Ubuntu du manual documents these options. Inspect the largest reported child subtree next, repeating the same approach with that directory. Avoid following symbolic links unnecessarily. If permission errors appear, the scan is incomplete; ask an authorised administrator to inspect the restricted locations rather than treating missing results as zero usage.
4. Choose cleanup based on the owning application
Once you identify a file-heavy directory, determine what creates those files and how long they must be retained. A build cache, expired application sessions, and a mail queue require different handling. A mail queue, for example, is not disposable merely because it contains many small files.
- Confirm the directory belongs to the affected application.
- Check the documented retention or cleanup mechanism.
- Preserve required records and verify any backup or regeneration plan.
- Use an approved application-aware cleanup during a suitable window.
- Repeat both df commands and confirm that the application can create its intended file.
Do not issue a recursive delete against an unfamiliar system directory. Moving files elsewhere on the same filesystem generally does not solve inode exhaustion; the files still exist. Also address the producer or retention setting, or the directory may fill again. For broader preparation, see the site’s Linux backup and safe rollback guidance.
Quick questions before escalating
Will buying a larger disk automatically fix this? Not necessarily. First establish which resource is exhausted and how the filesystem manages it. Expansion and filesystem changes need a separate tested plan.
Does this require a restart? The diagnostic commands do not. Any service restart or cleanup should follow the application runbook, not be a reflex response to a storage error.
Safety notice: This tutorial is for educational purposes. Test procedures carefully before using them in production. The site owner is not responsible for misuse, damage, data loss, or production issues.
