If an Ubuntu VPS reports No space left on device, check the filesystem used by the failing application before deleting anything. The cause may be exhausted disk capacity, too many small files, or storage still held by a running process after a file was deleted.
This guide walks through diagnosis and targeted cleanup for a server hosting websites, databases, or background workers. The commands assume SSH access and permission to administer the server. Substitute your application's paths where needed. Read the cleanup conditions before running commands that remove cached files or old logs.
Quick diagnosis: disk space, inodes, or another filesystem?
Start with the error message and the path it mentions. An upload failing under /var/www and a backup failing on a separate mounted volume may need different fixes.
| What you find | What to investigate |
|---|---|
| Little or no available space on the affected filesystem | Large directories, logs, backups, uploads, and container storage. |
| Inode usage is full while disk capacity remains | Directories containing very large numbers of small files. |
| Filesystem usage is much higher than visible directory usage | Deleted open files, inaccessible directories, and filesystem-specific accounting. |
| The host looks healthy but a container fails | The container's actual mount, writable layer, temporary filesystem, and applicable limits. |
1. Check the filesystem that cannot accept writes
df -hT
df -iThe first command reports filesystem capacity, type, and mount points. The second reports inode usage. Inodes hold file metadata; on filesystems with a fixed inode pool, new files can fail even when some data space remains. These options are documented in the GNU df reference.
For a specific location, pass an existing directory on the failing path:
df -hT /var/www
df -i /var/wwwUse the nearest existing parent if the failed file was never created. Read the Avail and IFree columns alongside the percentages. Check the relevant mount rather than assuming every application writes to the root filesystem.
For example, a backup volume can be full while the operating-system disk has room. Clearing a package cache on the root disk would not help that backup volume.
2. Find the directories using the space
When the root filesystem is affected, start with a directory-level view:
sudo du -xhd1 / | sort -hThen inspect the largest relevant branch. If the first result points to /var:
sudo du -xhd1 /var | sort -hThe -x flag keeps the scan on one filesystem, -h makes sizes readable, and -d1 limits displayed directory depth. A shallow display still scans the files underneath it, so large directory trees can take time and add disk load. See the GNU du reference.
If a separate mount is full, start the scan at that mount instead. Keep narrowing the path until you can identify the owner and purpose of the data. A directory name alone is not enough reason to remove its contents.
- Logs: identify the noisy service and its rotation policy.
- Backups: check retention and verify a usable copy on another system.
- Uploads: treat them as application data with an owner.
- Database storage: use the database's maintenance tools; do not remove internal files manually.
3. Check for inode exhaustion
If df -i shows that inodes are exhausted, looking only for the largest files can miss the cause. Inspect counts by directory on the affected filesystem:
sudo du --inodes -x --max-depth=1 /var | sort -nReplace /var with the relevant mount or directory. Drill into the largest count using the same approach. Application caches, expired sessions, temporary exports, and mail queues are useful places to investigate when their counts are unexpectedly high.
Choose the cleanup through the application that owns the files. Expiring stale sessions, for example, requires understanding the application's session lifetime. Removing an entire session directory can sign out active users; removing a mail queue can discard undelivered messages.
After cleanup, check inode availability again. Also find out why the retention job failed or why file creation accelerated.
4. Explain a large difference between df and du
A file can lose its directory entry while a process still holds it open. In that case, deleting the name does not necessarily return the occupied space immediately. If lsof is installed, inspect unlinked open files:
sudo lsof +L1Look at the process, file type, device, and size information. Focus on large regular files on the affected filesystem; do not add every row together as if each were a separate disk allocation. The lsof tutorial explains how open, unlinked files retain storage until their open references are released.
For a deleted log, use the service's documented log-reopen or rotation procedure. A controlled service restart may be necessary if no suitable reopen operation exists. Plan for its effect on requests or jobs, then check whether space returns.
If this does not explain the gap, investigate mount boundaries, scan errors, snapshots, and filesystem-specific storage accounting. A difference between the tools is a clue, not proof of a single cause.
5. Reclaim space with a targeted cleanup
Remove downloaded package archives when they are expendable
Check the APT archive cache first:
sudo du -sh /var/cache/apt/archivesIf it occupies useful space on the affected filesystem and you do not need those packages for offline reinstalls, clear the downloaded archives:
sudo apt-get cleanThis removes retrieved package files, not the installed applications. It differs from autoremove, which removes packages. See the Ubuntu apt-get manual.
Reduce archived journal logs only within your retention policy
Measure system journal usage:
sudo journalctl --disk-usageIf your policy permits discarding journal history older than 14 days, preserve any required evidence elsewhere first, then use this example:
sudo journalctl --rotate --vacuum-time=14dThis permanently removes eligible archived journal files. The rotation makes active files available for archiving before the vacuum step. Vacuuming acts on archived journals, while the usage report includes active files too. The journalctl manual describes the distinction. Fourteen days is an example, not a universal retention recommendation.
Inspect Docker storage before choosing anything to prune
On a Docker host, inspect storage through Docker:
sudo docker system df -vThe Docker disk-usage reference explains this report. Review image, container, volume, and build-cache ownership before cleanup. An object being unused by a running workload does not mean it has no future value: a volume may contain data needed for recovery. Follow the Docker pruning documentation for the specific object type. Do not manually clear Docker's storage directory.
6. Verify application recovery and stop the growth
Re-run the capacity and inode checks against the same path. Then exercise the operation that failed: a test upload, deployment, background job, or application write. Available space alone does not confirm that every affected service recovered.
If Nginx still returns an upstream error, continue with our Ubuntu Nginx 502 troubleshooting guide. For background processing, check the Laravel queues and scheduler checklist before replaying failed jobs.
Prevent the same incident by assigning retention rules to the source of growth:
- Check log rotation and fix repeated application errors that generate excessive output.
- Set journal storage limits appropriate to the server and your retention needs.
- Verify that backup and temporary-file retention jobs actually run.
- Monitor both capacity and inode availability on each important filesystem.
- Leave room for temporary growth during deployments, exports, and backups.
For ordinary file logs, inspect the rotation configuration without changing logs:
sudo logrotate --debug /etc/logrotate.confDebug mode makes no log or state-file changes, as the logrotate manual explains. For persistent journals, review SystemMaxUse and SystemKeepFree in the journald configuration reference. Choose limits that fit your workload instead of copying an arbitrary size.
Frequently asked questions
Why does Ubuntu say no space is left when gigabytes are free?
Check inode availability and the exact filesystem used by the failing write. Also inspect container or temporary mounts if the application runs in an isolated environment. Keep the exact error text: quota, permission, and read-only filesystem errors need their own diagnosis.
Should I resize the VPS disk?
Expansion can help when legitimate data has outgrown the available capacity. First identify the growth. A larger virtual disk may also require partition, volume, or filesystem expansion; follow the provider's procedure for your layout. Resizing alone does not repair a runaway log or broken retention job.
Can I delete old database backups?
Only after verifying which recovery points you need and that usable copies exist elsewhere. Keep backup retention tied to a restore plan. Our PostgreSQL backup guide covers that operational workflow.
Include storage checks in VPS management
When evaluating a VPS control panel, check whether your operating workflow makes storage growth, retention failures, and recovery easy to inspect. Keep a clear owner for each application, database, and backup directory.
Review the Core Panel documentation and validate your workflow on an isolated non-production server. Core Panel is currently classified as pre-production.
