Troubleshooting cPanel / WHM Email Monitoring

cPanel Disk Full: Safe Cleanup of Logs, Backups and Mail

A safe order of operations for reclaiming space on a cPanel server that has hit 100%, covering the fastest wins in logs, backups, the Exim queue, cPanel's own caches and package cache, and how to find the account-level growth that caused it.

Published 29 Sep 2026Updated 7 Oct 2026 7 min read By srvScripts team

A full root or /home partition on a cPanel server breaks things in cascading order: MariaDB stops accepting writes, Exim freezes the queue, sessions cannot be written so logins fail, and eventually cpsrvd itself refuses to start. Reclaiming space fast matters, but so does not deleting the wrong thing while in a hurry. The steps below are ordered from safest and fastest to more involved, and they finish with finding the growth so it does not recur next week.

Short answer: Run df -h, df -i and a one-level du -xh to see which filesystem and directory are full, then truncate oversized logs, prune whole dated sets under /backup, purge spam from the Exim queue with exim -Mrm, and clear dnf and temp caches. Check lsof +L1 for deleted files still held open, restart MariaDB and Exim, and set an 85% disk alert so the next growth becomes a ticket instead of an outage.

Find where the space went

Do not start deleting until you know which filesystem is full and what is on it:

df -h
df -i
du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -15

df -i matters because a partition can be “full” with free bytes if inodes are exhausted; millions of small session or cache files do that. The -x flag on du keeps it on one filesystem so /home does not distort the root figures. On most cPanel servers the answers are one of /var/log, /backup, /var/spool/exim, /usr/local/cpanel/logs, /var/cache, /home/*/mail, or a single account’s public_html.

For a per-account view, our cPanel disk usage report script is faster than du across /home, and whmapi1 listaccts | grep -E 'user|diskused' gives a quick sorted list.

Logs: the fastest win

Logs are safe to truncate, never rm them while a process holds the file open. The usual suspects on cPanel:

du -sh /var/log/* /etc/apache2/logs/* /usr/local/cpanel/logs/* 2>/dev/null | sort -rh | head
: > /var/log/messages
: > /etc/apache2/logs/error_log
: > /usr/local/cpanel/logs/error_log

A multi-gigabyte Apache error_log is a site emitting PHP warnings thousands of times a second; truncate it, then find the site in the last lines before you do so. A large /var/log/maillog or exim_mainlog is an outbound mail problem; a large /var/log/lfd.log is CSF being chatty about a port scan. For domlogs, see the web log retention guide for the permanent fix; for right now, truncate the largest with : > /etc/apache2/logs/domlogs/example.com.

Also check journald, which is capped by default but not always:

journalctl --disk-usage
journalctl --vacuum-size=200M

Backups on the same disk

/backup (the default cPanel backup directory) on the root or /home filesystem is the most common reason a server fills up predictably at 01:00. Inspect what is kept:

du -sh /backup/* /backup/*/* 2>/dev/null | sort -rh | head
ls /backup/daily /backup/weekly /backup/monthly 2>/dev/null

If the retention in WHM » Backup Configuration is more than the disk can hold, reduce it and let the next run prune, or delete the oldest dated directory manually. Remove only complete dated directories, never individual account archives inside a set, or the restore interface shows partial results. If backups are also going to a remote destination and the local copy is not required, set “Retain backups in the default backup directory” off. Legacy /backup/cpbackup/ from the old backup system can be removed entirely if the new system has been in use for a while.

The Exim queue and mail

A queue with tens of thousands of messages is both a disk and a reputation problem:

exim -bpc
du -sh /var/spool/exim/input

If it is a spam run, identify the source first (the outgoing spam guide and the Exim queue report script do this), then purge messages from that sender:

exim -bp | grep -B1 'compromised@example.com' | grep -oE '^[ ]*[0-9A-Za-z-]{23}' | xargs -r exim -Mrm

Frozen bounces to nonexistent addresses can be dropped wholesale with exim -bpr | grep frozen | awk '{print $3}' | xargs -r exim -Mrm.

Mailbox growth is a slower burn: du -sh /home/*/mail | sort -rh | head shows accounts with years of unread mail in .Trash or .spam. cPanel can auto-purge those folders via WHM » Mailbox Retention (or the per-account setting in cPanel » Email Disk Usage on older builds).

cPanel caches, package caches and temp

Several directories are safe to clear and regenerate:

dnf clean all
rm -rf /var/cache/dnf/*
/scripts/cleanupmysqlprivs >/dev/null 2>&1
rm -rf /usr/local/cpanel/3rdparty/mailman/archives/private/*/database 2>/dev/null
find /tmp /var/tmp -type f -mtime +7 -delete

/var/cpanel/updatelogs and /usr/local/cpanel/logs/cpbackup accumulate one log per run; keep a month and delete the rest. The EasyApache 4 profile and RPM caches under /var/cache/ and old kernels (dnf remove --oldinstallonly) recover a surprising amount on long-lived servers. Be careful with /var/cpanel/version and /var/cpanel/users; they look like caches and are not.

Inodes exhausted

If df -i shows 100%, find the directory with the file storm:

find / -xdev -type d -size +1M 2>/dev/null | head
find /home -xdev -type d -size +2M 2>/dev/null

A directory whose entry is over a megabyte contains tens of thousands of files. Typical sources are PHP session directories, a cache plugin writing per-URL files, .spam folders, and compromised sites dropping thousands of doorway pages. Clear the cache or session directory and tell the customer; a doorway-page dump means the account needs a malware scan before anything else.

A common pitfall: space that does not come back after deleting a file is being held by a running process. List them and restart the owner, or truncate via the file descriptor:

lsof +L1 | head
: > /proc/PID/fd/FD

Verify and keep it running

Confirm with df -h and df -i, then restart anything that was blocked: /scripts/restartsrv_mysql, /scripts/restartsrv_exim, and check systemctl --failed. Set a disk alert at 85% in WHM » Contact Manager and in your external monitoring, put /backup on its own volume or a remote destination, and schedule the disk usage report weekly so account growth is a ticket rather than an outage.

CPanel disk full at a glance

cPanel Disk Full summary card: Run df -h, df -i and a one-level du -xh to see which filesystem and directory are full, then truncate oversized logs… — In short: Run df -h, df -i and a one-level du -xh to see which filesystem and directory are full, then truncate oversized logs, prune whole dated sets under /backup, purge spam from the Exim queue with exim -Mrm, and clear dnf and temp caches.

Official documentation: cPanel & WHM documentation, Linux man pages.

Frequently asked questions

Does truncating Apache and Exim logs on cPanel break anything?

No. Truncating with : > file keeps the file and its open descriptor intact, so Apache and Exim carry on writing; deleting the file instead would hold the space until the process restarts and leave the daemon logging to nowhere.

How long does cleaning up a full cPanel disk take?

Log truncation and cache clearing free space within a minute or two; pruning backups and purging a large Exim queue take longer, typically ten to thirty minutes, and locating the account responsible for the growth is the part that deserves the rest of the hour.

Can I undo this?

Truncated logs and purged queue messages cannot be recovered, and deleted backup sets are gone unless a remote copy exists, so keep the last lines of any large error log before truncating and delete only the oldest complete backup directories.

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by: srvScripts editorial team
Last full review: 3 Oct 2026
Next review: 1 Apr 2027
Sources: docs.cpanel.net