Use authorized administrative access and record the affected service, path and error. Preserve incident logs where possible. Identify whether the limit is filesystem blocks, inodes, a user quota or a thin-storage backend rather than assuming every No space left message has the same cause.

1. Run df -hT for block usage and df -i for inode usage. Map the failing application path to its actual mount with findmnt -T PATH.
2. Inspect directory usage within that filesystem, using a bounded du -x scan so unrelated mounts do not distort the result. Avoid repeatedly scanning a struggling storage system.
3. Identify a safe candidate such as an expired retained backup, known application cache or rotated log whose retention permits removal. Preserve active incident evidence and confirm ownership before deleting.
4. Stop or limit the process causing uncontrolled growth through its supported service workflow. For a large active log, use proper rotation/reopen handling rather than simply unlinking it.
5. Free a small controlled amount, verify the filesystem, then restore the affected service and address its retention or capacity policy. Expand storage only through a layout-specific tested plan.

Run these on the affected Linux server. Replace /var with the mount path reported as full. The directory scan remains on that filesystem and can take time on a large tree, so run it once and avoid repeatedly scanning a busy production disk.

df -hT
findmnt --target /var
sudo du -xhd1 /var

Read the result: df reports filesystem capacity; findmnt shows the backing device and mount options; du estimates visible directory usage. If /var is a separate mount, freeing space under another mount does not help it. A large gap between df and du can involve open deleted files, reserved blocks or data hidden beneath a mount.

Investigate the largest relevant directory rather than removing the largest unknown file. Database files, snapshots and mail stores need their own retention or recovery workflow. Check inode availability as well if new small files still cannot be created.

A process can retain an open reference, or the storage can retain snapshot blocks. Identify the actual owner and storage layer before taking another destructive action.

Confirm both blocks and inodes have headroom and the application can create and read a harmless test record or file. Watch growth over time and check that failed writes did not leave an application recovery task or incomplete transaction.

If df remains full after deletion, inspect deleted-but-open files, snapshots, quotas and backend allocation. Never delete database data files, package databases or unknown VM images as emergency cleanup. Escalate filesystem or hardware errors separately from ordinary capacity pressure.

• Diagnosing a Linux server with no free inodes
• Finding deleted files that still consume disk space
• Extending a Linux logical volume safely
• Configuring log rotation for a custom Linux application

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