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

Source: https://srvscripts.com/guides/cpanel-disk-full-cleanup/
Updated: 2026-10-07
Publisher: srvScripts (https://srvscripts.com/)

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.

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.

**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](/scripts/cpanel-disk-usage-report/) 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](/guides/cpanel-apache-log-retention/) 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](/guides/find-source-of-outgoing-spam-cpanel/) and the [Exim queue report script](/scripts/exim-mail-queue-report/) 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](/scripts/cpanel-disk-usage-report/) weekly so account growth is a ticket rather than an outage.

## CPanel disk full at a glance

**Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [“cPanel license is invalid”: troubleshooting manage2, IP changes and firewalls](https://srvscripts.com/guides/cpanel-license-is-invalid/) · [cPanel 2026 pricing and licensing explained: Solo, Admin, Pro, Premier and WP Squared](https://srvscripts.com/guides/cpanel-pricing-2026-licensing/) · [Account quotas show “unlimited”: fixquotas and XFS/ext4 quota repair on cPanel](https://srvscripts.com/guides/cpanel-quotas-unlimited-fixquotas/).

**See also:** [/tmp Full on cPanel: Find What Fills It and Clean Up Safely](/guides/cpanel-tmp-full-cleanup/)

## 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.