Asciiroot Systems

Linux troubleshooting guide

Linux disk full: check space, inodes and recovery

A write failure can result from exhausted filesystem space, inodes or a quota. Identify the affected mount and type of limit before deciding how to recover capacity.

Before you begin: The examples use common Linux df options. Mount namespaces, quotas and filesystem behavior vary; confirm the view seen by the affected application. These examples are not executed or verified against your system. Obtain authorization, protect sensitive output and involve the responsible owner.

Clarify the incident

Collect the relevant scope and timeline before choosing an action:

  • Which filesystem or volume is affected, and is the limit bytes, inodes or a quota?
  • What is growing, when did the growth begin, and who owns the affected data?
  • Are backups and retention requirements confirmed before any cleanup is considered?

Possible explanations

These are alternatives to investigate, not confirmed causes:

  • Growing application data, logs, backups or temporary files can consume capacity; identify the actual source before acting.
  • Inode exhaustion or a quota can prevent writes even if the filesystem reports free bytes.

Read-only checks

Replace example names and paths only after confirming the applicable platform, permissions and change policy. Command output can contain sensitive data.

Linux: filesystem capacity

Identify the affected mount. If bytes appear available but writes fail, also check inodes and quotas; if space is low, identify the growth source with the data owner before cleanup.

df -h

Linux: inode capacity

Compare inode availability on the affected mount. Low inode availability suggests a file-count investigation; it does not identify files that are safe to remove.

df -i

Linux with GNU du: identify growing directories

Replace the placeholder with a confirmed, narrowly scoped directory on the affected filesystem. The -x option stays on one filesystem; this scan can be expensive, and permission errors or excluded mounts affect the result. Coordinate with the owner and do not delete files from this output alone.

du -x -h -d 1 /path/to/affected/directory

Linux with lsof: inspect deleted open files

If df reports used space that du cannot account for, an authorized operator can check deleted files still held open. The listing may require elevated privileges, be expensive and contain sensitive paths; it is not permission to stop a process.

lsof +L1

Interpret the evidence

Available space is low

Identify the affected mount and review its growth with the data owner. A capacity reading does not identify which files are safe to delete or whether a backup is usable.

Bytes are available but writes fail

Check inode availability and applicable quotas. A full inode table or a quota can prevent writes even when a filesystem reports free bytes.

The application sees a different result

Compare its mount namespace, filesystem and permissions with the host view. Do not assume a host-level reading describes every container or mount.

Plan recovery and verification

  1. Confirm scope and risk: Identify the affected filesystem, application and owners. Treat data deletion as potentially irreversible.
  2. Collect evidence: Review capacity, inode or quota usage, mount details and growth trends using approved, read-only diagnostics.
  3. Prepare recovery: Confirm backups and document recovery options before cleanup; deleted data may require backup restoration.
  4. Choose an approved mitigation: Agree with data owners on retention and backups before any cleanup or capacity change. Do not remove unknown files.
  5. Verify and prevent recurrence: Confirm capacity and application behavior, monitor growth, and assess retention, alerting and capacity planning.

Watch for recurrence: Track growth on the affected mount after the approved mitigation. If space falls again, compare the growth source and retention policy with the baseline; cleanup alone may not address the underlying cause.

Documentation pointers

Check the documentation for your product and installed version. These links are references, not live verification.

Explore a safe demonstration

The scenario lab illustrates a fixed example. It does not reproduce this incident or verify a production fix, and it never executes your commands.

Open the related scenario lab

Related Linux guides