A Linux disk full deleted files still open condition can look impossible: you remove a large log, yet df still reports little or no free space. The usual explanation is not that Linux ignored the deletion. Instead, a running process still holds the file open, or the space belongs to another storage structure that ordinary directory searches miss.
This matters on web servers, databases, file servers, and VoIP systems. A full filesystem can prevent services from writing logs, databases from committing data, or administrators from logging in normally. When you see Linux disk full deleted files still open, work through the checks in order, preserve evidence, and avoid deleting unfamiliar files during an outage.
Start by comparing blocks, files, and inodes
Linux reports storage in more than one way. The df command measures filesystem allocation. The du command totals visible files in directories. Those numbers can differ for legitimate reasons.
df -hT
sudo du -xhd1 / 2>/dev/null | sort -h
findmnt
The -T option shows filesystem types, while -x prevents du from crossing into other mounted filesystems. Without that restriction, a directory such as /var may include another disk, network share, or bind mount. You could then blame the wrong filesystem.
Compare the affected mount in both outputs. For example, df -h /var shows the filesystem containing /var, while du -xsh /var estimates visible usage on that filesystem. If df is nearly full but du finds much less data, investigate deleted open files, hidden mount paths, or filesystem metadata.
Also check inode availability:
df -ih
An inode is a filesystem record that describes a file. A filesystem can have free byte capacity but no free inodes. Many small cache files, mail files, session files, or temporary files can cause this form of exhaustion. In that case, deleting a few large files may not help.
Understand deleted files that remain open
Removing a file deletes its directory entry. The file’s data blocks remain allocated while a process keeps the file open. Linux releases those blocks only after the final open handle closes.
This pattern often follows log rotation. A service opens application.log, an administrator or rotation job replaces and deletes the old file, but the service continues writing to the old inode. The old log no longer appears in directory listings. Nevertheless, it can occupy many gigabytes.
Use lsof to look for open files marked as deleted:
sudo lsof +L1
Review the process name, process ID, user, file size, and mount path. The output may contain harmless temporary files, so do not kill every process it lists. A deleted file may also be legitimate application state that the service expects to keep open.
When a log causes the problem, the safest repair is usually to make the owning service close and reopen its files. First identify the service and its maintenance method. A controlled reload may work; some programs require a restart. Check the service’s documentation and maintenance window before acting.
sudo systemctl status service-name
sudo systemctl reload service-name
If reload is unsupported or ineffective, schedule a restart and verify service health afterward. The systemctl manual explains the commands and their service-management behavior. Never assume that sending a signal, truncating a file, or restarting a database is safe without understanding the application.
After the process closes the handle, run df -h again. Space may return immediately. If it does not, another process or storage layer may be responsible. For cases where commands stall during this check, see our guide to diagnosing a hanging Linux SSH session.
Check mount points and hidden directory contents
A mount point is a directory where Linux attaches another filesystem. Files that existed beneath that directory become hidden while the mount remains active. They still consume space on the underlying filesystem, but normal searches see the mounted filesystem instead.
This can happen after a disk fails to mount, a temporary mount is removed, or an administrator stores files in /mnt, /data, or /var/lib before attaching the intended volume. The visible directory may look small while the root filesystem remains full.
Review active mounts:
findmnt
lsblk -f
sudo du -xhd1 / 2>/dev/null | sort -h
Pay attention to expected mount paths and filesystem types. If you suspect hidden content, do not unmount a production volume casually. Unmounting can interrupt services and expose a large directory beneath it. A safer investigation may use console access, a maintenance window, or a separate rescue environment.
Also inspect mount namespaces. Containers can have different views of the same host storage. A file visible inside a container may not appear from the host’s ordinary process view. Container runtimes, bind mounts, and overlay filesystems require platform-specific checks.
Look for inode exhaustion and metadata pressure
When df -i shows high or complete inode use, find directories containing large numbers of small files. Start with a filesystem-limited count rather than scanning every path blindly.
sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -n | tail -20
This command groups files by parent directory. It can take time on a busy server, and its output depends on GNU find. Test the path and command on the relevant system before using it during an incident.
Common sources include application caches, queued email, web sessions, failed upload fragments, and per-request debug files. Confirm ownership and retention rules before removing anything. Prefer the application’s cleanup process when one exists.
Do not confuse inode use with directory size. A directory containing millions of tiny files may consume relatively few gigabytes while exhausting inodes. Conversely, a large database file can fill blocks without using many inodes.
Investigate journals, logs, and snapshots
System journals and application logs can grow quickly when a service repeats an error. Check visible log usage first:
sudo journalctl --disk-usage
sudo du -sh /var/log/* 2>/dev/null | sort -h
Do not delete active logs by hand unless the application documents that method. Log rotation may depend on file ownership, labels, signals, or a service reload. Fix the repeated error as well, or the filesystem may fill again.
Filesystem journals, such as ext4’s journal, record metadata changes so the filesystem can recover after an interruption. They are not ordinary log files. Do not remove or edit journal structures manually. If the filesystem reports errors, plan an offline check with a tested backup and an appropriate recovery procedure.
Snapshots create another form of hidden retention. Copy-on-write snapshots preserve older blocks after files change or disappear. LVM, ZFS, Btrfs, storage arrays, and hosting platforms each expose different commands and policies. Review snapshot age, reserved space, replication state, and backup dependencies before deleting one.
A snapshot may protect recovery, but it does not automatically provide a restorable backup. Confirm what the snapshot contains and whether deleting it affects replication or retention requirements. This distinction matters when investigating Linux disk full deleted files still open alongside storage-level snapshots.
Use safe cleanup commands carefully
Once you know what consumes space, reclaim it in a controlled order. Start with application caches, old temporary files, and approved package caches. Use a preview before any deletion.
sudo find /var/tmp -xdev -type f -mtime +14 -print
The command only prints matching files. The age threshold is an example, not a universal policy. Confirm that no application needs those files and that the path is correct. Avoid commands such as rm -rf /var/tmp/* during a rushed incident.
Package cleanup also depends on the distribution. Use the package manager’s documented cache command rather than guessing. For systemd journals, retention can be reduced with a documented vacuum operation, but choose a limit that meets operational and audit needs.
Never remove files from /proc, /sys, /dev, database directories, snapshot stores, or unknown service data simply because they look large. Before cleanup, capture df -hT, df -ih, mount information, and relevant process details. This evidence helps explain what changed.
Prevent the next full filesystem
Set alerts for both byte usage and inode usage. A byte-only alert misses workloads that create many small files. Monitor important mount points separately, including volumes used by databases, containers, logs, and backups.
Review log rotation after installing or changing services. Confirm that rotation actually causes the application to reopen files. A monitoring check for large deleted-open files can identify the problem before free space reaches zero.
Finally, document snapshot retention and temporary-file policies. Storage growth is easier to manage when someone owns each cleanup decision. Backups should also undergo testing, because emergency deletion is safer when recovery has been demonstrated.
When to escalate the investigation
If space does not return after a confirmed file handle closes, or if the filesystem reports errors, pause destructive cleanup. Storage layers can involve RAID, encrypted volumes, thin provisioning, containers, quotas, and snapshots. Each layer can change what the usual commands reveal.
For a Linux disk full deleted files still open incident that involves production data or several storage layers, Tech Rescue Ops LLC can help operators collect evidence, identify the responsible process or mount, and plan cleanup without interrupting critical services. Professional remote assistance is especially appropriate when the affected server hosts a database, customer-facing application, backups, or production communications. Our Linux server support service is an appropriate starting point when local staff need a second set of experienced eyes.