You attempt to create a file, update a database record, or install a security patch on your production server, and your command fails with an immediate error: No space left on device. Confused, you immediately run df -h to inspect disk utilization, only to discover that your primary volume has 30 GB or 50 GB of free, unallocated storage remaining.
The Linux no space left on device error is a classic sysadmin puzzle with two distinct hardware causes: physical block exhaustion or inode table saturation. On Linux filesystems like ext4 and XFS, every single file, directory, and symbolic link requires an index node (inode) to store metadata. If your system generates millions of tiny files (such as PHP session files, mail queues, or temporary caches), your system can run out of available inodes while retaining gigabytes of free disk capacity.
In this technical walkthrough, we guide you through identifying whether your outage is caused by physical block exhaustion, 100% inode saturation, or unlinked deleted files held open in memory. If your organization requires 24/7 infrastructure management, explore our enterprise cloud and DevOps consulting services.
1. Inode Exhaustion vs Disk Block Exhaustion

Traditional storage monitoring tools only check raw byte capacity (df -h). However, standard POSIX filesystems allocate a fixed number of inodes during initial filesystem formatting. Once that inode table fills up, the kernel rejects all new file creation attempts.
- Uncleaned PHP Sessions: The
/var/lib/php/sessionsdirectory frequently accumulates millions of zero-byte session files if automated garbage collection fails. - Maildir / Postfix Queue Overflow: Unroutable bounce emails or spam attacks can create massive backlogs in
/var/spool/postfix. - Deleted Files Held by Active PIDs: When you delete a massive log file with
rmwhile a daemon (like Nginx or Docker) is still writing to it, the disk space is not released until the process closes the file descriptor.
Diagnostic Rule: Always Run df -i First
Whenever you see a no space error while df -h shows available gigabytes, run df -i. If IUse% reads 100%, you have experienced total inode exhaustion.
2. Step-by-Step Diagnostic and Cleanup Commands
Follow these progressive commands to locate and purge the offending files safely:
Step 1: Check Inode Utilization
# Inspect inode usage per filesystem
df -i
# Inspect human-readable disk capacity
df -hStep 2: Find Directories with Massive File Counts
If inodes are at 100%, execute this one-liner to count files per top-level directory and identify the source of clutter:
# Count files per folder in /var (adjust path as needed)
sudo find /var -xdev -printf '%h
' | sort | uniq -c | sort -k 1 -n | tail -n 10Step 3: Safely Purge Accumulated Session and Cache Files
If millions of files exist in a directory, running rm * will fail with Argument list too long. Use find -delete to stream the deletion cleanly without memory overhead:
# Delete PHP session files older than 7 days
sudo find /var/lib/php/sessions -type f -mtime +7 -delete
# Clear systemd journal logs older than 3 days
sudo journalctl --vacuum-time=3d3. Releasing Deleted Files Held by Open Processes
If df -h indicates 100% full disk space even after you deleted massive log files, active processes are still holding open file descriptors. Verify with lsof:
# Find deleted files still held open in memory
sudo lsof +L1 | grep deleted
# Truncate active log files safely in the future without unlinking
> /var/log/nginx/access.logRestarting the specific service (such as sudo systemctl restart nginx) frees the held file descriptor and releases the space instantly.
4. Storage Diagnostic Matrix
| Condition | df -h Status | df -i Status | Primary Remediation |
|---|---|---|---|
| True Disk Full | 100% Used | < 80% | Delete large files, clear Docker caches |
| Inode Saturation | < 60% Used | 100% Used | Purge session files, mail spool, node_modules |
| Ghost Open File | 100% Used | < 80% | Restart process holding deleted descriptor |
To learn more about modern server deployment configurations and storage optimization, read our guide on deploying web applications efficiently. For comprehensive Linux infrastructure audits, get in touch through our contact page.
5. Where to Go From Here
Preventing unexpected storage outages is a standard component of proactive sysadmin maintenance. Incorporate these automation techniques into your server baseline:
- Configure logrotate with size-based rotation and compression (
compressandrotate 4) to ensure logs never grow uncontrollably. - Set up monitoring alerts on both disk capacity (
df -h) and inode utilization (df -i) at 85% thresholds. - Run automated cron jobs to clean obsolete session files in temporary directories on high-volume web portals.