When Linux reports No space left on device, check the filesystem containing the path that failed. It may have exhausted its data blocks or its inodes. Deleting a large file elsewhere will not help if it belongs to another filesystem.
Start with the error message and the destination path. Our df and du guide explains the measurements; this guide uses them to choose a recovery step.
Check bytes and inodes on the failing path
Replace /path/to/directory with an existing directory where the write failed. If the intended file does not exist yet, use its parent directory:
df -hT /path/to/directory
df -i /path/to/directory
findmnt -T /path/to/directory -o TARGET,FSTYPE,OPTIONSThe first report shows storage capacity. The second shows inode availability on filesystems that expose inode counts. The mount report helps identify separate disks, memory-backed filesystems and container mounts.
| Result | Likely next step |
|---|---|
| Available bytes are exhausted | Find what occupies this filesystem, then remove or relocate data using its owner's supported procedure. |
| Inode availability is exhausted | Look for unusually large numbers of small files, such as an application's cache or queue. |
| Both reports show room | Confirm the path and execution environment. Investigate filesystem-specific limits and the precise error. |
A quota failure may instead say Disk quota exceeded. A read-only mount or a permission error is another problem again. Use the permission diagnostic guide when access is denied rather than assuming storage is full.
Locate the data before choosing cleanup
Scan a directory you are authorized to inspect. This GNU du command shows one level and stays on the starting filesystem:
du -x -h --max-depth=1 /path/to/directory | sort -hRead any permission errors; an incomplete scan can underestimate usage. A large directory is not automatically disposable. Databases, container image stores and application queues should be managed through their own tools. Removing files directly from a database directory can damage it.
When inodes are the constraint, a folder full of tiny files can matter more than a large video. Check the affected application's retention settings and whether it is creating files faster than it removes them. Keep required records and backups before cleaning a queue or cache.
Check for deleted files that remain open
A running process can continue holding a file after its directory entry is removed. The blocks remain allocated until the last reference is released. If lsof is available, inspect unlinked open files:
sudo lsof +L1Correlate the file, process and device with the filesystem you are investigating; this command can show files across multiple mounts. A large deleted log may explain why df still reports high usage although du no longer sees that pathname.
Use the application's documented log-reopen or graceful restart procedure during an appropriate maintenance window. Do not kill an unfamiliar process or truncate its file descriptor just to free space. Recheck df after the application releases the file.
A targeted Ubuntu cleanup option
If downloaded APT archives occupy the affected filesystem, inspect their size first:
sudo du -sh /var/cache/apt/archivesIf those cached downloads are expendable, this removes APT's downloaded package archives:
sudo apt cleanIt does not uninstall installed packages. Future installations may need to download the archives again, so retain anything you require for offline work. This step helps only when that cache consumes space on the constrained filesystem. If APT cannot locate a package afterward, use the APT package lookup checklist.
Verify recovery
Repeat both df checks on the original path and retry the original operation. If the application immediately fills the filesystem again, investigate its growth rate and retention policy. In containers, inspect the container's own mounts and any storage limit imposed by the runtime.
In our isolated test, a two-mebibyte memory filesystem produced the error when its blocks filled. A separate run exhausted its 64-inode allowance while free blocks remained. We also observed blocks becoming available after closing a deleted file. These controlled cases explain why the same message needs more than one check.
Sources and verification
Tested September 11, 2026 in an isolated Ubuntu 24.04 container with a bounded 2 MiB tmpfs: block exhaustion, inode exhaustion with free blocks, df reports, mount inspection and deleted-open-file release were reproduced. No production storage was filled or cleaned. Quota and filesystem-specific recovery procedures were not tested.