Fix cPanel Disk Usage Warning: Complete Guide 2026

Please, stop emailing me about the same thing over and over. Not all emails – I mean the ones with "Disk Usage Warning" in the subject line. In my years as a NOC engineer, I’ve watched that exact subject hit my inbox hundreds of times. And almost every single time, the root cause never actually got fixed.

That’s what frustrates me. The warning itself isn’t the enemy. The enemy is the habit of ignoring disk usage until everything’s completely full. By the time anyone bothers to check, the disk is wrecked. Mail stacks in the queue, MySQL refuses to write, daily backups fail, and clients’ websites slow to a crawl. Every bit of it was preventable if it had been handled properly from the start.

So this article is not about silencing the warning so your inbox stays quiet. That’s just covering up the symptom, and it’ll come right back. What I want to show you is how to actually fix a cPanel disk usage warning from the root – commands included. Read it all, then bookmark it. Because let’s be honest, you’re probably going to need it again.

What’s Actually Happening When the Warning Shows Up

Let’s break down what happens under the hood. cPanel runs a quota system per account. Every account on the server gets its own disk quota, configured in WHM under Home > Account Functions > Quota Modification. Once usage crosses a certain percentage – typically 80% for server partitions and 90% for individual account quotas – cPanel automatically emails the contact address on file. The email looks something like this:

Subject: Disk Usage Warning - site-lama-client.com (server-01)

Your account has reached 92% of its disk space allowance.
You may not be able to write files until you free up some disk space.

Please review your disk usage and remove any unnecessary files.

Read that middle line slowly: "You may not be able to write files." That’s not an empty threat. That’s a fact. Once the quota hits its limit, the account goes over quota, and the server stops writing new files – including incoming email, login sessions, plugin caches, and whatever your client is uploading right now. Picture a client trying to upload a new product to their online store and it failing over and over with no explanation. Yeah. That.

And if it’s not an account quota that’s full but the root or /home partition itself, the damage is even worse. MySQL can refuse to write, exim’s mail queue piles up, cron jobs fail, cPanel itself throws errors during updates, and the scariest one – system logs stop being readable because there’s no space left. Get to that point and the server goes down, which for a NOC engineer means another night without sleep.

What most people don’t realize: the warning usually shows up long before the disk is actually full. cPanel is patient. But because most people ignore it, a 9 a.m. warning turns into a 9 p.m. outage. The irony is that all of it would have taken thirty minutes of cleanup if someone had known how. That’s exactly why I’m writing this guide.

Before You Clean Anything – Confirm the State of the Disk

Don’t delete blindly. A good NOC engineer collects data before executing anything. The first step is confirming the real state of the disk – both at the system level and at the account level. Trust me, sometimes the number in the warning email doesn’t match reality, and sometimes there’s another partition in worse shape than the one cPanel is complaining about.

Check Partitions and Inodes at the System Level

SSH in, then run these two commands:

df -h
df -i

The first shows disk usage in a human-readable format, the second shows inode usage. The output looks like this:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       100G   92G  8.0G  92% /
/dev/vda2        50G   45G  4.1G  90% /home
tmpfs           3.9G     0  3.9G   0% /dev/shm

Watch the Use% column. Here you can see / is at 92% and /home at 90%. If the root partition is the red one, the usual suspects are logs, local backups in /backup, and package manager caches. If /home is the full one, it’s account files – email, databases, website content.

Here’s the thing people forget: inodes. Your disk can look totally fine and still refuse to write new files if you run out of inodes. Check the IUse% column in the df -i output. If it’s above 90%, you have too many small files – usually cache folders, session files in /tmp, or email. We’ll come back to this.

Check Quotas and Per-Account Usage

Once you know the state of the partitions, zoom in on the account level. In WHM, open Home > Home Directory > Disk Usage, or use quota from the command line:

whmapi1 get_quota_info user=client-a
repquota -a

repquota shows every user’s usage at once, limits included. From here you can instantly see which account is eating the most space. In my experience, on a server hosting multiple clients, there’s almost always one or two accounts that ballooned out of nowhere within a week. That’s a pattern worth investigating, not just a reason to bump their quota.

Find the Real Culprit – What’s Eating Your Space?

Now for the most important part. Once you know which partition is full and which account is the biggest, you need to find the specific file or folder causing the problem. This is where a lot of people give up, because "disk full" feels abstract – nobody’s going to check files one by one. Don’t worry, there are commands for that.

Scan the Biggest Directories per Account

This command shows which folders inside the home directory are the biggest, sorted largest first:

du -sh /home/client-a/* | sort -rh | head -20

The output should look something like this:

12G	/home/client-a/public_html/wp-content
8.1G	/home/client-a/cpbackup
5.4G	/home/client-a/mail
2.2G	/home/client-a/.trash
1.4G	/home/client-a/tmp

Look at that first line: 12G in wp-content. If there’s a WordPress site involved, I’d bet most of those files aren’t essential – they’re stacked-up backup plugin files, plugin logs, and cache. The cpbackup folder is another frequent offender, since it holds old cPanel backups nobody ever cleans.

Hunt for Big Files Across the Whole System

If it’s not just an account quota but the root partition that’s full, you need to search for large files system-wide. This takes a few minutes depending on disk size, but it’s worth it:

find / -xdev -type f -size +500M -exec ls -lh {} ; 2>/dev/null | sort -k5 -rh | head -30

This lists every file above 500MB. Usually this is where we find the wild stuff – an 8GB error log (yes, that really happens), old database dumps, or that video a client dropped in public_html. Yes, that happens too.

Quick Diagnosis Table – Culprit, Location, and Fix

To make this easier, here’s a table I’ve put together from years of handling cPanel servers:

Culprit	Location	Signature	Fix
Old backups	/backup, /home/user/cpbackup	Large .tar.gz files, old dates	Rotate and delete unused backups
Apache logs	/usr/local/apache/logs/	error_log and access_log in GB range	Truncate or set up logrotate
Cache and temp	/tmp, /var/tmp, wp-content/cache	Many small files, high inode count	Clear cache, delete old temp files
Email and attachments	/home/user/mail/	Big mailboxes, stacked attachments	Organize mailboxes, remove old mail
cPanel trash	/home/user/.trash/	Deleted files waiting in trash	Empty trash via WHM
Core dumps	/var/crash, /var/spool/abrt	Large core.* files	Delete after confirming it’s not a new issue
Sessions and small files	/home/user/tmp, /tmp	Thousands of tiny files, inodes maxed	Clear expired sessions

The Cleanup – Safe Steps to Fix a cPanel Disk Usage Warning

Here’s the part we’ve been waiting for. But before we continue, read this. Some of the commands below delete files permanently. Never run a delete command without knowing exactly what you’re deleting. Miss your target and a client’s data is gone – and that’s not an error log you can recover.

Clean Up Old Backups in /backup

/backup is the default storage for server-level cPanel backups. If your backup configuration isn’t rotating, this folder can quietly eat tens of gigabytes. Check what’s inside first:

ls -lah /backup | tail -30

Once you’ve seen what’s there and confirmed the files are old and unneeded, list the backups older than 30 days using a filter so you don’t hit the wrong target:

find /backup -type f -mtime +30 -name "*.tar.gz" -ls

That command only lists files. Look at the list first. When you’re sure, run the delete:

find /backup -type f -mtime +30 -name "*.tar.gz" -delete

Remember – don’t rm without verifying first. Backups newer than 30 days stay safe, and the one you rely on for restore should still be there.

Truncate Huge Logs

The most common culprit among logs is Apache’s error_log. That file can grow to tens of gigabytes when bots are brute-forcing nonstop. It lives in /usr/local/apache/logs/. Check first:

ls -lah /usr/local/apache/logs/error_log
du -sh /usr/local/apache/logs/* | sort -rh | head

If you find a big one, don’t delete the file directly – logs being held open by Apache often don’t actually free space until the service restarts. Safer to use truncate, which empties the contents but keeps the file in place:

truncate -s 0 /usr/local/apache/logs/error_log

Important: truncate wipes the log contents permanently. If you’re mid-investigation of an attack or a bug, copy the relevant lines to another file first. It’s not fun to trace a brute force all night and find the log empty the next morning.

Clear Cache and Temp Files

WordPress cache in wp-content/cache and plugin caches rarely get cleaned. At the system level, /tmp and /var/tmp also fill up with stale process files. For per-account WordPress cache:

du -sh /home/client-a/public_html/wp-content/cache

If it’s large, clear the contents via cPanel File Manager or SSH. For system-level temp, check file ages first:

find /tmp -type f -mtime +7 -ls 2>/dev/null | head -20

That lists temp files older than 7 days. Once the list looks reasonable, swap -ls for -delete:

find /tmp -type f -mtime +7 -delete 2>/dev/null

Files in /tmp are almost always safe to delete because they’re transient by design. Still, make sure no critical process is using them – active sessions, unfinished installers, that kind of thing.

Tidy Up Mailboxes and Trash

Email is the culprit people forget about most. One client sending a 10MB attachment back and forth can stack a mailbox in a couple of months. Check mail usage per account:

du -sh /home/*/mail 2>/dev/null | sort -rh | head -10

Then there’s the cPanel trash in /home/user/.trash/. That’s where files deleted through File Manager sit before being emptied. Check it:

du -sh /home/client-a/.trash
find /home/client-a/.trash -type f | wc -l

If it’s gotten big, empty it via WHM or delete the files after confirming nothing needs saving.

Prevention So the Warning Stops Coming Back

Cleaning is only half the battle. The other half is keeping it from filling up again in two weeks. From my experience, this is the part people skip – and it’s exactly why this warning keeps turning into a recurring story.

First, set up backup rotation. If you use cPanel’s built-in backups, configure retention. In WHM, go to Home > Backup > Backup Configuration, or check the official docs at cPanel’s backup documentation. Don’t keep 30 full backups if the server only hosts a couple of clients. Four to seven backups is more than enough in most cases.

Second, set up a cron job to scan and alert automatically. Something that checks for files above 1GB every week and emails the results. It’s not a burden on the server – one du run a week is nothing. What matters is knowing first, before the client calls first.

Third, make reading metrics a habit. If you manage production servers, checking df -h every morning isn’t extra work, it’s routine. Same as checking the oil before a long drive. It costs nothing and saves you a very bad night.

FAQ About Fixing cPanel Disk Usage Warnings

Related Articles

Once you’re done with the disk, these neighboring topics often come up together:

• Troubleshooting High Load on a cPanel Server: Causes and Fixes
• The Right Way to Handle cPanel Backups and Restores
• Troubleshooting a Stacked cPanel Mail Queue

Conclusion – Don’t Repeat the Same Mistake

So here’s the takeaway. The cPanel disk usage warning isn’t the enemy – it’s an alarm asking to be fixed. The trouble starts the moment that alarm gets ignored, and from there everything can fall apart: email stuck, MySQL can’t write, backups failing, and worst of all, a server going down during business hours.

Fixing a cPanel disk usage warning properly takes three layers: confirm the state first (df, quota, du), clean the root cause (backups, logs, cache, email, trash), then set up prevention so it doesn’t come back (backup rotation, cron monitoring, daily checks). Do all three patiently and this warning won’t be visiting you again.

Please, don’t ignore emails like this. Learn the commands above, save this article, and put it into practice. I’ve seen this exact case repeat far too many times, and I’m sure you don’t want the harsh version. Take it seriously.