VPS Disk Space Troubleshooting Tutorial (2026): Find and Fix “No space left on device” Without Downtime

Disk-full incidents rarely give you a friendly warning. One minute the WordPress dashboard works. The next, uploads fail, PHP can’t write session files, and your mail queue starts piling up.

This VPS disk space troubleshooting tutorial shows you how to confirm what’s actually “full” (bytes vs inodes vs a specific mount). You’ll then reclaim space safely and reduce the odds of the same outage in 2026.

The workflow below fits Ubuntu 24.04/26.04 LTS, Debian 12/13, AlmaLinux 9/10, Rocky Linux, and most VPS images. It also applies to dedicated servers. The numbers are just larger.

Before you delete anything: confirm what “full” means

“No space left on device” usually maps to one of three issues:

• The filesystem is full (bytes used is ~100%).
• Inodes are exhausted (too many small files—often cache/tmp/spam).
• A specific partition is full (common with separate /var, /tmp, or a small /boot).

Start with these two commands:

# Filesystem usage (bytes)
df -h

# Inode usage (file count capacity)
df -ih

Scan for:

• Use% at 95–100% on a mount you depend on (often / or /var).
• IUse% at 95–100% (inode exhaustion).
• A small partition like /boot hitting 100% after kernel updates.

Operational tip: if your panel (cPanel/Plesk) is sluggish or timing out, run triage over SSH.

If you haven’t locked down admin access yet, set up a jump host first.

HostMyCode’s guide is here: SSH jump host setup guide.

Quick safety net: free 200–500 MB fast (without guessing)

If the server is pinned at 100%, basic services can’t write logs or temp files. Create a little headroom first. Then investigate properly.

1. Clear package caches (safe and reversible).

   # Ubuntu/Debian
   sudo apt-get clean
   sudo apt-get autoremove --purge -y
   
   # AlmaLinux/Rocky
   sudo dnf clean all
   sudo dnf autoremove -y

2. Trim journal logs (keep the last 2 days).

   sudo journalctl --disk-usage
   sudo journalctl --vacuum-time=2d

3. Remove obviously safe temp artifacts (only if they’re huge).

   sudo du -sh /tmp /var/tmp 2>/dev/null
   # If you see multi-GB build artifacts or abandoned temp files:
   sudo find /tmp /var/tmp -type f -mtime +3 -delete

Once you’re back under ~90–92%, most services behave normally again. You can then troubleshoot without everything falling over.

VPS disk space troubleshooting tutorial: pinpoint the directory that exploded

Next, find where the growth happened. Use du with human output and sorting.

Run it on the mount that’s full.

# If / is full
sudo du -xhd1 / 2>/dev/null | sort -h

# If /var is full (very common for hosting)
sudo du -xhd1 /var 2>/dev/null | sort -h

On a typical hosting VPS, you’ll often see patterns like these:

• /var/log grows, but it shouldn’t live in the tens of GB.
• /var/lib grows with Docker, databases, mail, or panel services.
• /home grows with sites, media, and backups.

After you find the biggest top-level directory, drill down one level at a time:

sudo du -xhd1 /var/log 2>/dev/null | sort -h

If you want an interactive view and don’t mind installing a small tool:

# Ubuntu/Debian
sudo apt-get update && sudo apt-get install -y ncdu

# AlmaLinux/Rocky
sudo dnf install -y ncdu

sudo ncdu -x /var

Hosting fit: if you run multiple sites and growth is steady, pair a slightly larger disk with basic monitoring.

A HostMyCode VPS gives you clean Linux images and room to scale storage before “disk full” becomes a fire drill.

High-impact culprits (and safe fixes) on hosting servers

The goal isn’t random deletion. Remove the right data, in the right place, without breaking sites or losing mail.

1) Log files that never rotate

Start by listing the biggest log files:

sudo find /var/log -type f -printf '%s %p\n' 2>/dev/null | sort -n | tail -n 30

If one or two files are multi-GB, treat it as two problems.

First, stop the growth. Then reclaim space.

• Don’t delete a log a process is actively writing. Truncate it:

  # Example: truncate a huge log safely
  sudo truncate -s 0 /var/log/nginx/access.log

• Force logrotate (after you sanity-check the config):

  sudo logrotate -d /etc/logrotate.conf
  sudo logrotate -f /etc/logrotate.conf

Frequent offenders on hosting servers:

• /var/log/nginx/access.log, /var/log/apache2/access.log (bot floods).
• /var/log/php*-fpm.log (fatal loops, permission errors).
• /var/log/maillog or /var/log/mail.log (spam, retry storms).

If bots are driving log volume and bandwidth, rate limit at the edge. For Nginx, see: Nginx rate limiting tutorial.

2) Email queues and mail logs (Postfix/Exim)

Mail incidents usually consume disk in two places: the queue directory and the logs.

On cPanel, Exim queue bloat often shows up alongside spam. On Postfix, queue growth typically lives under /var/spool/postfix.

Postfix queue size check:

sudo postqueue -p | tail -n 20
sudo du -sh /var/spool/postfix 2>/dev/null

If the queue is huge, fix the root cause before you flush anything. Otherwise it will just refill.

Use logs to confirm whether you’re dealing with auth failures, relay misconfig, or outbound spam.

Two relevant guides:

• Mail queue troubleshooting tutorial
• cPanel outbound spam cleanup tutorial

Space reclaim note: deleting queue files blindly can lose mail and damage deliverability.

If you must reduce pressure fast, target older deferred mail only after you’ve confirmed why it’s deferred.

3) WordPress cache, backups, and “mystery ZIPs” under uploads

On WordPress VPS hosting, disk growth is often self-inflicted:

• Backup plugins writing daily full-site archives into wp-content/uploads.
• Cache plugins storing multi-GB page caches.
• Staging copies that never get cleaned up.

Find big directories inside a site:

# Replace path to your vhost/docroot
cd /var/www/example.com || cd /home/*/public_html
sudo du -h --max-depth=2 wp-content 2>/dev/null | sort -h | tail -n 25

Safer cleanup patterns:

• Move old backup archives off-server (object storage or another VPS) and keep only the most recent 1–2 locally.
• Clear page cache from the plugin UI during low traffic, not by deleting random directories.
• Remove abandoned staging directories after you’ve merged changes.

If you don’t already have a tested restore plan, don’t “clean” backups yet. First prove restores work.

Use this runbook-driven approach: VPS backup verification tutorial.

4) Docker and container images on a hosting VPS

If you run Docker, image layers and stopped containers can quietly consume tens of GB.

docker system df
docker ps -a

Safe cleanup (removes unused data):

# Removes stopped containers, unused networks, dangling images, build cache
docker system prune -f

# If you want to remove unused images as well (be sure you can re-pull/rebuild)
docker system prune -a -f

Don’t run this mid-deploy. Schedule it, and only after you know images can be rebuilt or re-pulled cleanly.

5) Inode exhaustion (the “disk isn’t full” trap)

If df -h shows free space but df -ih shows 100% inode usage, you’re out of file entries.

The fix is deleting lots of small files, not hunting for one giant file.

Find inode-heavy directories:

sudo for d in /var/* /tmp /home/*; do echo "--- $d"; sudo find "$d" -xdev -type f 2>/dev/null | wc -l; done | sort -n | tail -n 40

Typical inode hogs:

• Cache directories (wp-content/cache, framework caches).
• Session directories (/var/lib/php/sessions or similar).
• Maildir spam floods in /home/*/mail on cPanel servers.

Fix the cause first (cache retention, bot traffic, spam). Then delete older files.

For PHP sessions, you can usually remove stale sessions older than 2–7 days:

# Example path varies by distro/PHP SAPI
sudo find /var/lib/php/sessions -type f -mtime +7 -delete

Recover space held by deleted files (open file handles)

Sometimes you delete a large file and df barely moves. A process may still have the file open.

The space only returns after the process closes it.

Find deleted-but-open files:

sudo lsof +L1 | head -n 50
sudo lsof +L1 | awk '{print $1, $2, $7, $9}' | sort -k3 -n | tail -n 20

The usual suspects are web servers, PHP-FPM, and mail services.

The clean fix is restarting the specific service holding the file:

# Examples (choose what matches your system)
sudo systemctl restart nginx
sudo systemctl restart apache2
sudo systemctl restart php8.3-fpm
sudo systemctl restart postfix

Avoid rebooting unless you have to. It works, but it’s the loudest option.

Special case: /boot is full after kernel updates

Many VPS images ship with a small /boot (often 512MB–1GB). After enough kernel updates, it fills up and blocks future updates.

Check installed kernels:

# Ubuntu/Debian
dpkg -l 'linux-image-*' | awk '/^ii/{print $2}'

# RHEL-family
rpm -q kernel

Remove old kernels, keeping the current and one previous version:

# Ubuntu/Debian: identify old kernel versions first, then purge
uname -r
sudo apt-get purge -y linux-image-OLDVERSION linux-headers-OLDVERSION
sudo apt-get autoremove --purge -y

If you’re not sure what’s safe to remove, don’t guess.

Take a snapshot first (if available), or schedule a short maintenance window.

Prevention: set disk alerts before you hit 100%

Disk-full incidents don’t come out of nowhere. You want alerts at 70–80% so you fix trends instead of outages.

At minimum, alert on:

• Filesystem usage: warn at 75%, critical at 90%.
• Inodes: warn at 70%, critical at 85%.
• Top directory growth: daily trend checks for /var and your web root.

If you want a straightforward, hosting-focused monitoring setup (uptime + resource alerts + basic log checks), follow: Server monitoring tutorial.

Hardening your server against disk-filling attacks

Not every spike is “normal growth.” Abuse can fill disks fast.

Common triggers include bot floods, brute force, spam, and error loops that outpace log rotation.

• Stop brute force at the firewall, especially on shared-style VPS hosting or reseller setups. If you run cPanel, use CSF with sane rules: cPanel CSF firewall setup tutorial.

• Cap or tune access logs for noisy paths. On Nginx, you can disable logging for health checks and static noise. Do it deliberately so you don’t lose visibility during incidents.

• Keep email authentication aligned to reduce inbound/outbound abuse patterns. SPF/DKIM/DMARC and rDNS affect deliverability, but they also reduce operational chaos. If mail matters on your server, see: email authentication setup tutorial.

Operational checklist: a repeatable “disk full” runbook

Use this when the alert hits and you don’t have time to improvise.

1. Confirm the failure mode: df -h and df -ih.
2. Get breathing room: package cache clean, trim journald, review /tmp.
3. Identify the mount culprit: du -xhd1 on the full mount.
4. Fix the cause: bot flood, mail spam, log loop, runaway backups, Docker bloat.
5. Reclaim space safely: truncate active logs, prune caches, offload backups, remove unused images.
6. Check for deleted-but-open files: lsof +L1 then restart the owning service.
7. Verify recovery: write tests (create a temp file), check key services, confirm panel login.
8. Prevent recurrence: alerts at 75/90%, adjust retention/rotation, document what happened.

FAQ: disk space fixes that won’t bite you later

Should I delete /var/log to free space quickly?

No. Truncate specific huge logs and then fix rotation. Deleting log directories breaks services and complicates debugging. Use truncate -s 0 on the biggest files and run logrotate.

Why didn’t disk space free up after I deleted a big file?

A process may still hold the file open. Run lsof +L1 to find deleted-but-open files, then restart the owning service.

What’s the safest first cleanup on Ubuntu/Debian?

apt-get clean plus trimming journald with journalctl --vacuum-time=2d typically frees space without touching application data.

How do I prevent WordPress backups from filling my VPS?

Keep only 1–2 recent archives locally, push older backups off-server, and test restores. If you need a restore-first process, follow HostMyCode’s backup verification tutorial and make it a monthly task.

Summary: fix today’s outage, then stop the next one

Disk-full events feel messy when you treat them like a mystery. Confirm whether you’re out of bytes, inodes, or a single partition.

Once you know that, you can usually find the culprit in minutes. You can also clean up without breaking sites.

For hosting that needs consistent resources and predictable operations, run your workloads on a HostMyCode VPS, set alerts at 75/90%, and keep log and backup retention explicit. That alone prevents most “No space left on device” incidents from reaching customers.