Finding a Linux write failure through paths and mounts

The directory name is a clue, not a guarantee about what is safe to remove. A path that looks temporary may be a mount point for persistent application data. Inside a container, it may lead to different storage from the same-looking host path. When a service cannot write, the Linux filesystem hierarchy helps orient the investigation, but the actual mount and the service's use of it determine the repair.

Start with the failing path and exact error. The task is to establish which storage and permissions the service encounters, then distinguish capacity exhaustion from a different reason for the write failure. That sequence is more useful than looking for the largest directory first and deciding afterward what it contained.

What the directory hierarchy tells you

The Filesystem Hierarchy Standard documents these conventional roles. Configuration, persistent state and runtime data have different lifecycles, while /proc and /sys expose interfaces to the running kernel rather than ordinary stored documents. The table helps identify what kind of data or interface deserves closer inspection.

Actual distributions and container images may arrange things differently. Many systems merge /bin, /sbin and /lib into locations under /usr through symbolic links. Two familiar names therefore do not necessarily offer two separate places to reclaim capacity.

Consider a hypothetical directory that appears to contain temporary files but is actually a mounted application volume holding recovery data. Its conventional name suggests one lifecycle; the application's use of the mounted volume establishes another. Following the mount before deleting anything reveals that the apparent cleanup would remove material needed for recovery.

The filesystem the service actually sees

On a Linux host with these utilities installed, substitute the affected service path in these read-only checks:

findmnt -T /var/lib/example-service
df -h /var/lib/example-service
df -i /var/lib/example-service
ls -ld /var/lib/example-service

The findmnt command identifies the containing mount. The two df commands distinguish space from inodes, the filesystem records needed to represent files. The ls command reports ownership and permissions. Together they begin to explain why file creation might fail even when a capacity graph still shows free bytes.

A container adds another view to inspect. Its filesystem namespace determines the paths it can see, and its volume mapping connects those paths to backing storage. A matching name on the host does not establish a matching filesystem. This is the point in the hypothetical cleanup where the apparently disposable directory becomes identifiable as an application volume.

If reported usage does not match visible files, investigate deleted-but-open files with appropriate tools and access. A process may still hold their storage. Removing unrelated visible files could therefore discard useful material while failing to release the capacity the investigation expected.

When capacity and ordinary permissions look healthy, inspect mount options and security policy under the service's actual identity. An administrator's successful write does not demonstrate that the application is allowed to write. The distinction matters before broadening permissions to solve a failure whose cause may be an intentional protection.

Read-only checks of the path, mount, namespace and service identity can narrow the write failure without a complete system map. Before destructive cleanup of the recovery volume, connect the full path to the application's retention and recovery requirements and establish the responsible change owner. A temporary-looking directory name supplies neither that ownership nor evidence that its contents can be discarded.

Trace a write failure to the boundary that denied it

Read diagram description

Read-only investigation sequence: the same-looking path may resolve to different storage inside a container. A successful administrator write does not establish that the service identity can write. Diagram labels: Failing path + service identity: Keep the exact error and environment; Namespace + mount: Resolve container volume and underlying filesystem; Capacity + inode availability: Inspect the filesystem containing this path; Permissions + mount policy: Check ownership, read-only state and security policy; Owned intervention: Preserve evidence before changing the boundary.

What the write error adds to the diagnosis

The filesystem checks narrow the possibilities; the application's own error helps choose among them. Inspect its logging configuration instead of assuming a distribution-specific file such as /var/log/syslog exists. A systemd service may use the journal, while a container may write to standard output for collection elsewhere.

journalctl -u example.service --since "30 minutes ago" --no-pager
systemctl status example.service --no-pager

These commands require a systemd-based environment and appropriate access. The bounded time range keeps attention on the failure and avoids unnecessarily collecting sensitive log data. Preserve the error and relevant mount options before changing either, so the investigation retains evidence of whether capacity, a read-only mount or a denied operation blocked the write.

Capacity, permissions and recovery need different interventions

Capacity growth leads to questions about lifecycle and retention before cleanup. A permissions failure leads to the service identity and intended access. Resource pressure without capacity exhaustion belongs in Linux performance diagnosis, where file deletion may not address the limiting condition at all.

Restarts, mount changes and termination signals also need a connection to the diagnosis. A forced kill can discard in-memory work and bypass cleanup, so a process holding storage is not by itself a reason to kill it. Establish the responsible team and recovery procedure before choosing that intervention.

For the directory carrying recovery data, the investigation should now identify the constrained filesystem, the service’s attempted write and the data that must be retained. Those findings distinguish a retention change from a permissions repair or a capacity increase. The directory convention helped locate the problem; the mount and application lifecycle determine which of those interventions fits.