When a VPS reports “No space left on device”, identify the affected filesystem and check both available bytes and inodes. A filesystem can stop accepting new files while gigabytes remain available. A deleted file can also continue using space while a process keeps it open.
Start with the inspection commands below before choosing a cleanup or expansion procedure. Database files, active logs and container volumes are not interchangeable reserves of disposable space. Recovery needs an understood intervention, application checks and a correction to the growth pattern that caused the incident.
What this guide helps you do
- Distinguish exhausted bytes, exhausted inodes and the wrong filesystem.
- Identify large directories and deleted files that remain open.
- Plan controlled recovery and prevent the same storage failure recurring.
Operators of a Linux VPS investigating failed writes or storage warnings. Examples use GNU tools; lsof and systemd must be available for their respective checks.
Before you start- The exact error and the path where a write fails.
- Knowledge of active services and available independent backups.
- Permission to inspect relevant directories and processes; record missing visibility.
1. Find the filesystem that serves the failing path
df -hT / /var /var/lib
df -i / /var /var/lib
findmnt -T /var/lib -o TARGET,SOURCE,FSTYPE,OPTIONSReplace these example paths with the application location. Several paths can refer to the same filesystem, so do not add their figures together. A separate data volume may be full while the root filesystem still has room. findmnt associates a path with the mount that contains it.
Keep the exact error message. “Read-only file system” or recurring I/O errors need a different investigation from ordinary space exhaustion. If a filesystem became read-only because of a fault, removing random files is not a remedy. Record the state and coordinate further intervention with the responsible administrator.
2. Separate space, inodes and other limits
| Observation | Possible explanation | Next check |
|---|---|---|
| Very few available bytes | File contents and filesystem data occupy the space. | Inspect directories on that filesystem. |
| Almost all inodes used | Very large numbers of files or directories. | Identify their location and producer. |
| df much higher than du | Open deleted files, restricted access or different measurement scopes. | Check scope and permissions, then open files. |
| df looks normal but writes fail | A quota, container limit, different volume or permission error. | Verify the error and actual destination. |
Inodes describe filesystem objects. Large numbers of tiny cache or session files can exhaust them without much content. Available statistics vary by filesystem. Reserved space, metadata, snapshots and access restrictions can also explain differences; df and du should not be expected to match exactly in every situation.
3. Narrow the search to an appropriate directory
Choose the relevant query from your initial finding. Use /var only if the affected path is there. The -x option avoids descending into other filesystems. Continue into the directory that explains the growth instead of repeatedly scanning the entire server.
du -x -h --max-depth=1 /vardu -x --inodes --max-depth=1 /varThese commands remove nothing, but traversing many files can add I/O load. --max-depth limits displayed depth, not all the work below those directories. Run the appropriate query deliberately, considering current storage pressure. Restricted directory access leaves incomplete results.
Associate the large area with its owner: database, uploads, logs, package cache or temporary exports. Size alone does not show that data is disposable. Avoid creating another archive on the same full filesystem as an attempted backup; use an appropriate independent destination.
4. Look for deleted files that processes still hold
lsof -nP +L1The +L1 selection finds open files with a link count below one. For example, a service may still hold an old log whose directory entry has been removed. Space is released only after the remaining open references close. Your permissions determine how much of other users’ process activity you can inspect.
Check the process, file type and filesystem. Repeated entries may describe the same file; do not sum their sizes blindly. A service-specific log reopen or controlled restart can release references, but that is a separate operational change. Follow the service documentation and plan for interruptions. Deleting the same filename again does not fix the underlying open reference.
5. Choose a controlled way to restore working space
First protect new application data. An agreed write pause or pausing a nonessential producer may prevent more failed operations. Establish how much working space recovery needs and which independent backup is available. Avoid changing several unfamiliar areas together; preserve enough evidence to understand the cause.
| Area | Controlled approach |
|---|---|
| Application logs | Confirm ownership and retention, then follow documented rotation. |
| Temporary exports or caches | Confirm completion and disposability before approved maintenance. |
| Database or container volume | Use application-aware maintenance; do not remove internal files indiscriminately. |
| Permanently growing application data | Plan appropriate expansion or relocation with a backup and rollback path. |
A larger virtual disk does not automatically enlarge every partition and filesystem configuration. Check the complete sequence before changing it. If Journald appears significant, the following command reports its occupied space, including active and archived journals. It performs no cleanup.
journalctl --disk-usage6. Verify the application as well as free space
After the approved intervention, check available bytes and inodes on the same filesystem again. Observe whether space stays available or immediately shrinks. If an open file was responsible, also check the affected process and its current logging behavior.
Free space alone does not establish application health. Check database status, errors and queues using the appropriate tools. Failed uploads or partially completed business operations may need separate handling. Restore writes in a controlled way and avoid blindly replaying payments or jobs.
7. Set growth and retention rules
- Monitor available bytes and inodes separately, with an owner for alerts.
- Allow working space for updates, temporary exports and expected growth.
- Define retention and rotation for logs, caches and temporary data.
- Keep independent backups and allow for recovery rehearsal space.
Choose alert thresholds from growth rate and response time instead of a universal percentage. A slow-growing archive and a sudden logging loop need different responses. Record the cause, approved intervention and resulting measurements so the next capacity decision reflects real data growth.
Review scope
The editorial team reviewed the linked primary documentation on 1 October 2026. The Bash examples were checked for syntax with bash -n only. They were not executed on a production VPS, and no complete diagnosis or recovery exercise was tested. Check the commands against your distribution, permissions and application before using them.
Official references
Check the project’s current documentation for version and configuration details.
- GNU Coreutils: df manual (new tab)
Filesystem usage, filesystem types and inode statistics.
- GNU Coreutils: du (new tab)
Directory usage, inode counts, output depth and filesystem boundaries.
- lsof: official manual (new tab)
+L1 selects open files with no remaining directory link.
- util-linux: findmnt manual (new tab)
Associate an application path with its mounted filesystem.
- systemd: journalctl manual (new tab)
--disk-usage reports active and archived journal files without removing them.