Trace and Fix Linux Disk Full Errors Killing Websites

If your website suddenly returns 500 errors, fails to upload media, or the host reports “no space left on device,” you are almost certainly dealing with Linux disk space saturation—not a mysterious application bug. This guide walks Australian site owners and small-business operators through remote SSH diagnosis: how to confirm the root partition is full, find unmanaged text logs and leftover temp files, and free space safely without guessing.

Fixwebnode provides direct remote website support for this exact failure mode across Australia. If you need hands-on recovery after you try the steps below, start here: website repair Australia.

Why disk saturation takes websites offline

Linux web stacks (Nginx or Apache, PHP-FPM, MySQL/MariaDB, mail and cron jobs) write constantly to the same root filesystem many VPS and cloud images ship with. When that partition hits 100%, databases cannot write, sessions fail, SSL renewals break, and package updates stall. The first honest check is always capacity—not a blind reboot.

Remote work is normal for this problem: you SSH in, measure free space, locate the largest directories, clear safe log and cache paths, then verify the site responds again. The rest of this post is that runbook, written for production hosts used by individuals, sole traders, and local operators in Australia.

How do I fix a Linux root partition at 100% when my website is out of disk memory?

SSH into the server as a sudo-capable user, run df -h to confirm which mount is full, then use du and log cleanup to free space on the root filesystem before restarting PHP-FPM or Nginx. If deleted files are still held open, identify them with lsof and recycle the holding process. Call a specialist when you cannot free enough space safely, databases refuse to start, or the host is a managed panel you do not fully control.

Common issues that fill the disk under a live website

These problems look similar in the browser (errors, failed saves, broken cron) but have different root causes on the server. Treat them as separate tracks.

• Unmanaged application and web-server text logs — access.log, error.log, PHP slow logs, and rotated copies grow for months until /var is full.
• Deleted files still held open by a process — you removed a multi-gigabyte log, but Nginx, PHP-FPM, or MySQL still holds the inode, so df stays at 100%.
• Upload, cache, and backup sprawl on the web root — old CMS backups, image derivatives, session files, and failed import dumps fill /var/www or /home.
• Inode exhaustion with “free” blocks still showing — millions of tiny files (sessions, email queue fragments, cache shards) exhaust inodes even when df -h looks healthy.

Issue 1 — Root partition full from unmanaged text logs

Classic pressure case: the site worked yesterday; overnight log volume or a noisy plugin filled /var/log. Confirm capacity first, then measure directories, then delete only rotated and aged logs.

Step 1 — SSH and measure mounts

ssh user@your-server-ip
sudo df -h
sudo df -i

Look for Use% at 100% on / or /var. High IUse% with free blocks points to inode problems (Issue 4).

Step 2 — Rank the largest directories

sudo du -xh / --max-depth=1 2>/dev/null | sort -h
sudo du -xh /var --max-depth=2 2>/dev/null | sort -h
sudo du -xh /var/log --max-depth=1 2>/dev/null | sort -h

Step 3 — Inspect and truncate safe log targets

sudo ls -lah /var/log/nginx/ /var/log/apache2/ /var/log/httpd/ 2>/dev/null
sudo ls -lah /var/log/php* /var/log/mysql/ /var/log/journal/ 2>/dev/null
# Truncate active huge logs instead of rm (keeps the open file handle valid)
sudo truncate -s 0 /var/log/nginx/access.log
sudo truncate -s 0 /var/log/nginx/error.log
sudo journalctl --vacuum-size=200M
sudo find /var/log -type f -name "*.gz" -mtime +14 -delete
sudo find /var/log -type f -name "*.log.[0-9]*" -mtime +7 -delete

Step 4 — Verify space and web stack health

sudo df -h /
sudo systemctl reload nginx 2>/dev/null || sudo systemctl reload apache2 2>/dev/null
sudo systemctl status php*-fpm --no-pager 2>/dev/null
curl -I https://your-domain.example

If logs refill within hours, fix logrotate and the noisy application next—do not only truncate forever.

When to call Fixwebnode: you cannot tell which log belongs to a critical service, journal vacuum fails, or the panel (cPanel, Plesk, custom) locks log paths you should not wipe by hand.

Issue 2 — “I deleted the log” but df still shows 100%

Linux does not free blocks until every process closes the file. Truncating is safer than rm for live logs; after a blind rm, you must find deleted-but-open files.

Step 1 — Confirm free space still zero

sudo df -h /
sudo du -xh /var/log --max-depth=1 2>/dev/null | sort -h

If du looks small but df is full, open-deleted files are the usual cause.

Step 2 — List deleted files still held

sudo lsof +L1 2>/dev/null | head -n 50
sudo lsof 2>/dev/null | grep -i deleted | head -n 50

Step 3 — Recycle the holding service (preferred over kill -9)

# Identify the command/PID from lsof, then recycle gracefully
sudo systemctl reload nginx
sudo systemctl reload php8.2-fpm 2>/dev/null || sudo systemctl reload php-fpm
sudo systemctl restart mysql 2>/dev/null || sudo systemctl restart mariadb 2>/dev/null
sudo df -h /

Only restart databases during a short maintenance window; prefer reload for web servers when possible.

Step 4 — Prevent repeat holds

sudo logrotate -f /etc/logrotate.conf
sudo cat /etc/logrotate.d/nginx 2>/dev/null

Ensure rotate + copytruncate or proper postrotate reload exists for your web server package.

When to call Fixwebnode: the holding process is a custom binary, Docker container, or mail queue you do not want to restart without a rollback plan.

Issue 3 — Website uploads, caches, and old backups eating the web root

CMS sites (WordPress and similar), export dumps, and failed plugin upgrades leave multi-gigabyte trees under the document root or home directory. Symptoms: media library uploads fail, “no space left on device” in PHP error logs, cron backups abort mid-run.

Step 1 — Locate oversized site paths

sudo du -xh /var/www /home --max-depth=3 2>/dev/null | sort -h | tail -n 40
sudo find /var/www /home -type f -size +100M -printf "%s %p\n" 2>/dev/null | sort -n | tail -n 30

Step 2 — Clear known-safe temporary and cache locations

# Adjust paths to your document root; examples for common layouts
sudo find /var/www -type d -name cache -prune -print
sudo find /tmp /var/tmp -type f -mtime +3 -user www-data -delete 2>/dev/null
sudo find /var/lib/php/sessions -type f -mtime +7 -delete 2>/dev/null
# WordPress-style: remove old local backup zips you confirmed are off-server
# (only delete files you recognise as backups)
ls -lah /var/www/*/wp-content/uploads 2>/dev/null | head

Step 3 — Move or remove confirmed backup archives (never delete the only copy)

# Example: list candidate archives first
sudo find /var/www /home -type f \( -name "*.sql.gz" -o -name "*backup*.zip" -o -name "*.tar.gz" \) -mtime +14 -ls 2>/dev/null
# After off-server copy verification, remove specific files by full path only

Step 4 — Re-check capacity and application logs

sudo df -h /
sudo tail -n 50 /var/log/nginx/error.log 2>/dev/null
sudo tail -n 50 /var/log/php*-fpm.log 2>/dev/null
curl -I https://your-domain.example

When to call Fixwebnode: the largest path is a live media library you cannot prune without business rules, or object storage migration is required instead of endless local growth.

Issue 4 — Inodes exhausted while df -h still looks “OK”

Writes fail with “No space left on device” even though block usage is not 100%. Session stores, email spool fragments, and cache micro-files are frequent culprits on long-running hosts.

Step 1 — Confirm inode pressure

sudo df -i
sudo df -h

Step 2 — Find directories with huge file counts

sudo find /var /home /tmp -xdev -type d -printf "%i %p\n" 2>/dev/null | head -n 1
# Practical count sweep on hot paths
for d in /var/lib/php/sessions /var/spool /tmp /var/cache /var/www; do
 [ -d "$d" ] || continue
 echo -n "$d "
 sudo find "$d" -xdev -type f 2>/dev/null | wc -l
done

Step 3 — Purge expired sessions and stale cache files

sudo find /var/lib/php/sessions -type f -mtime +2 -delete 2>/dev/null
sudo find /tmp -type f -mtime +2 -delete 2>/dev/null
sudo find /var/cache -type f -mtime +30 -delete 2>/dev/null
sudo df -i /

Step 4 — Harden so it does not return

# Ensure session GC and logrotate are active; example checks
sudo systemctl list-timers | grep -E "logrotate|php|session" || true
sudo grep -R "maxdepth\|rotate\|compress" /etc/logrotate.d/ 2>/dev/null | head

When to call Fixwebnode: inode use stays critical after cleanup, or the flood is coming from malware droppers / mail abuse rather than normal sessions.

When DIY is enough vs when to book Fixwebnode

DIY is reasonable when you have SSH, a recent off-server backup, and df clearly points at logs, tmp, or known backup zips. Stop and book remote help if any of the following are true:

• MySQL/MariaDB will not start after cleanup, or tables report corruption.
• You are on a control panel host and unsure which paths the panel owns.
• Space frees briefly then returns within an hour (runaway writer, compromised site, or broken rotate).
• The only large data is production media or customer uploads you cannot delete by policy.
• You need concurrent fixes: disk recovery, PHP-FPM tuning, and emergency hardening.

Fixwebnode works as a direct specialist provider for remote website and server recovery—not a freelance marketplace. Coverage and remote support options are summarised on the service areas page for operators across Australia.

Book remote help before the next outage window

Disk saturation is mechanical: measure with df -h and df -i, rank paths with du, clear logs and caches safely, recycle processes holding deleted files, then confirm the site answers again. Do that calmly once; automate logrotate and off-server backups so you are not firefighting the same full root partition every month.

If you want a specialist on the session with you—diagnosis, safe cleanup, and post-fix checks—open a conversation with Fixwebnode via https://fixwebnode.com.au/website-repair-australia. Bring SSH access details and a short note of what df showed; that is enough to start remote recovery for individuals, sole traders, and local operators.