Check the failing mount
Measure blocks and inodes on the filesystem containing the failed write, inside the guest. Another mount's free space does not rule out exhaustion.
A 'No space left on device' error may reflect exhausted blocks or inodes, a full temporary mount or a quota. Check the affected guest filesystem; plan size or provider graphs cannot identify it. This read-only diagnosis is for authorised Linux admins or managed customers gathering evidence, not a cue to delete files or resize disks.
Use the console if SSH is unavailable, according to your service permissions. Record the exact failing operation, pathname and time. A failed write to one mount can coexist with free space on another.
Read blocks and inodes
On a GNU/Linux guest where the command is available, df -h /path/to/existing/directory reports space for the filesystem containing that path; df -i /path/to/existing/directory reports inode usage. Replace the example with an existing directory on the filesystem used by the failing application write. Record Filesystem, Mounted on, Available and Use% from the first output, and IFree/IUse% from the second. A high inode percentage can explain write failures even with free bytes. The GNU df manual describes both views.
Check the path inside the guest, not on your local computer or just the VPS panel. If a container or separate volume is involved, ask the operator which mount actually holds the failing data. A remote filesystem error may need its own owner.
Illustrative reading: if the affected upload mount has free gigabytes but zero free inodes, investigate excessive file creation on that mount; deleting an unrelated backup elsewhere cannot fix it.
Locate pressure without deleting evidence
If blocks are full, the authorised operator can inspect large directories and recent growth with supported read-only tools. If inodes are full, look for an unexpectedly high file count. Check logs, caches, uploads, backups and database storage as candidates, but verify retention and ownership before removal. If df shows free space while the application still says full, check quotas, read-only remounts, the actual write path and application-specific limits.
Do not truncate logs, remove database files, clear unknown caches or delete the newest backup during an incident. A package update or database restart may require additional working space and can worsen a full filesystem.
A full-looking path may be constrained by a quota or read-only mount even when df reports space; check those separately.
Why disk space stays used after deleting a file
If df says a filesystem is nearly full but du cannot account for the space, one possible cause is a file that was unlinked while a process still has it open. The directory entry has gone, so a directory scan cannot find the file, but Linux keeps its storage until the final open file descriptor closes. This can happen when a large log is deleted while its service continues writing to it. Filesystem metadata, permissions or scanning a different mount can also explain a gap; a mismatch alone does not prove an open deleted file.
To compare whole-filesystem use, run df -h /path/to/existing/directory and note its Mounted on value. If GNU du is installed, an authorised operator can then run sudo du -xsh /actual/mountpoint, replacing the example with that mount point. This full-mount scan can take time and requires permission to read its directories; check that it completed. A scan of only one subdirectory cannot be compared directly with df for the entire filesystem. The -x option keeps GNU du from crossing into other filesystems.
Where you have administrator authority and lsof is installed, ask the authorised operator to run sudo lsof -nP +aL1 /actual/mountpoint using the same mount point. This asks lsof to select unlinked open files on that filesystem. A listed process and deleted path are evidence to investigate, not permission to terminate it. Output can be limited by permissions, and not every system has lsof.
Identify the service owner and its supported way to close or reopen the file, such as its documented log-reopen procedure or an approved, workload-safe service restart. Confirm the effect and authority first. Do not kill a process, truncate /proc/<pid>/fd/*, or restart a database or production service blindly: doing so can lose data or cause an outage. After the responsible process closes the file, check df again on the same filesystem. If no file is reported, do not assume the diagnosis; recheck the mount, permissions, completed du scan, quotas and filesystem-specific accounting, then escalate with the readings and timestamps.
Use a reviewed cleanup or expansion plan
Have the owner identify data that may safely be archived or removed, confirm a usable backup and define expected recovered space. Clean one known target, re-run df -h and df -i on the same path, then test the failed application write. If capacity is genuinely insufficient, ask the provider whether plan storage and the guest partition/filesystem can both be expanded; a larger virtual disk alone may not increase guest filesystem capacity.
If the VPS becomes unstable or cannot boot, preserve the observations and escalate. Provide filesystem and mount names, usage figures, error and timestamp, avoiding private directory contents. Managed customers should not run root cleanup commands on a provider baseline without authorisation.
Common questions
Can inode exhaustion happen with free GB? Yes; check df -i.
Why does df show more used space than du? They measure different things. A deleted file still open in a process is one possible cause; compare the same filesystem and have an authorised operator check with lsof where available.
Should I restart the process holding a deleted file? Only its service owner should choose a supported, safe close or restart procedure after checking workload impact.
Does a bigger plan immediately fix the guest? Not necessarily; partitions or filesystems may need authorised expansion.
Should I delete log files first? Identify ownership, retention and the cause before changing them.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.