If an application cannot create a file while a disk report shows free bytes, first verify the filesystem behind the failing path. Then check inode availability and the limits applying to the actual service identity. Free capacity on a different mount, or free blocks outside an enforced quota, does not answer whether that operation can succeed.1, 2, 3
This guide focuses on Linux with GNU df, util-linux findmnt and local ext4/XFS storage. The examples inspect existing state only and were not executed. Network filesystems, container storage and other filesystem types need their own allocation and quota rules checked.
Preserve the original failure
Record the exact application error and, where available, the underlying operating-system error. Keep the attempted path, operation, timestamp and service identity. An application may translate several different storage failures into one “disk full” message.
Distinguish creating a new file from extending an existing one, creating a directory or writing a temporary file before renaming it. The application may use a staging directory on a different filesystem from its final destination. A healthy final volume is irrelevant if the failure occurs in the staging area.
Do not create a test file as an unplanned diagnostic step on customer data. Begin with logs and metadata. A future verification write should be an authorised synthetic operation in a designated location under the actual service identity.
Also record whether the incident followed a deployment, mount change, batch increase or retention failure. Those events guide the investigation but are not proof of the cause.
Resolve the path before measuring capacity
findmnt --target accepts a file or directory path and identifies its containing filesystem. Explicit output columns make the result easier to compare than a changing default display.2
findmnt --target '/approved/application/path' --output TARGET,SOURCE,FSTYPE,OPTIONS
df -hT -- '/approved/application/path'
df -i -- '/approved/application/path'
Use an existing path in the intended execution environment. The examples are source-checked illustrations, not commands run for this article. They do not mount, resize or delete anything. Remote or unhealthy storage can still make metadata inspection slow, so keep the scope narrow.
GNU df -T includes filesystem type, while df -i reports inode rather than block usage.1 Preserve both outputs and the target path. A report without the path can easily describe the wrong mount.
For a container or service with a different mount namespace, a host shell may see a different mapping. findmnt documents inspection of another task's mount information, but selecting that task requires correct process identity and authorised visibility.2 Do not assume the host's view establishes the application's path.
Compare bytes and inodes
An inode stores file metadata. A workload producing very many small files can stress file-count-related resources even when their aggregate data size is modest. GNU's inode report is therefore a separate useful observation from the familiar byte-usage report.1
Keep filesystem type visible when interpreting it. Allocation behaviour and remedies differ across ext4, XFS and other filesystems. Do not transfer an inode-sizing recipe from one filesystem to another or assume a virtual-disk extension automatically resolves the relevant limit.
An inode report showing no available entries on the actual failing filesystem strongly directs the investigation towards file-count pressure. It still does not identify which application owns those entries or authorise deletion. The next task is ownership and lifetime analysis.
If both block and inode reports show apparent headroom, investigate identity-specific limits and the precise operation before declaring the error impossible. The dashboard may be accurate about global capacity while omitting the limit that applies to this service.
Check quotas in the correct identity context
RHEL 9's XFS documentation describes separate block and inode limits at user, group and project/directory levels. It also distinguishes quota accounting from enforcement.3
The quota examples here are specifically XFS. ext4 remains in scope for path, byte and inode diagnosis; its quota configuration and reporting require separate filesystem-specific documentation rather than reuse of XFS commands. Therefore, a global free-space reading does not establish the headroom granted to one application.
Ask the storage administrator to inspect the applicable usage, soft/hard limits and enforcement state for the real service identity and project. A successful write by root would not validate the service's quota situation. Keep the account and project mapping with the result.
Use the filesystem's reporting interface first. Do not enable quotas, alter mount options or raise limits just to obtain a diagnosis. Those are changes that need an owner and a capacity/fairness decision.
If the relevant limit is confirmed, decide whether the application is legitimately exceeding its allocation or retaining files incorrectly. Increasing a quota may be justified for growth, but it does not correct an abandoned temporary-file workflow. Conversely, deleting business data to stay under an obsolete allocation is not an acceptable default remedy.
Attribute file growth with bounded work
Select the application-owned subtree most strongly associated with the failure. Review its retention policy, file creation rate and lifecycle. Examples to investigate include session files, small job results, spool entries and failed temporary-file cleanup. These are possible workload classes, not a claim that any particular service is at fault.
Use an approved, bounded inventory rather than recursively scanning every mounted filesystem. Record the scan's scope, permissions and errors. A partial listing must not be reported as a complete count, and a network share should not be traversed accidentally while investigating a local volume.
File counts and names may expose business information. Prefer aggregate counts by owned directory and age where those answer the question. Keep any detailed list restricted and avoid storing a diagnostic report on the filesystem that is already under pressure.
Do not confuse “old” with “safe to delete”. Some small files are indexes, queue state or application metadata. The application owner should define which objects are disposable and whether deletion through an application interface is required to preserve consistency.
Decide which layer needs correction
Use the established evidence to choose one path:
| Finding | Correction to prepare |
|---|---|
| The application writes to an unexpected mount | Correct the path/mount configuration with dependency and data-location review. |
| Inode availability is exhausted | Address file lifecycle and assess a filesystem-specific capacity design. |
| A user/group/project quota is reached | Review legitimate allocation and owner-approved cleanup or quota change. |
| Physical blocks are actually exhausted | Investigate the real consumers and capacity rather than pursuing an inode theory. |
| Reports have headroom but the error persists | Examine filesystem/device errors and the exact operation; keep the cause unresolved until evidenced. |
Filesystem expansion, migration or recreation can require outage and a demonstrated recovery route. This article provides no formatting, inode-recreation or bulk-delete commands. Such operations are not reversible merely because they began as a disk-space investigation.
If another layer, such as an LVM thin pool, is exhausted beneath the filesystem, keep that as a distinct diagnosis. A filesystem's logical free space does not guarantee that every lower allocator can satisfy new writes.
Verify the service, not the administrator shell
After an approved correction, repeat the path, block, inode and applicable quota observations. Use the same namespace and service identity as the original failure. Then perform a separately authorised synthetic application operation with a known cleanup path.
Acceptance should establish that the service can create, extend and complete the kind of file operation it needs, while preserving adequate reserve. A single successful root write or a changed dashboard percentage is insufficient.
For a lifecycle fix, observe a representative creation/expiry cycle through ordinary monitoring. Record whether file count stabilises and whether expected application records remain present. No such runtime verification was performed here.
Keep the previous configuration and recovery plan for changes to paths or limits. Restoring a quota value can reintroduce the incident; reversing a filesystem migration or recovering deleted data requires more than a settings rollback. State those consequences before approval.
Learning notes
- Measure the filesystem behind the exact failing path.
- Global bytes, inode capacity and identity-specific quotas are separate constraints.
- File ownership and application lifecycle determine the safe correction.
Acceptance checklist
- [ ] The failing path is mapped in the service's actual mount namespace.
- [ ] Byte, inode and applicable identity/project quota limits are recorded separately.
- [ ] The authorised service-identity test completes with adequate reserve.
- [ ] The file lifecycle or allocation correction is evidenced without deleting unreviewed business data.
References
- df invocation (GNU Coreutils 9.12). Accessed 2026-11-01.
- findmnt(8) - Linux manual page. Accessed 2026-11-01.
- RHEL 9: Limiting storage space usage on XFS with quotas. Accessed 2026-11-01.