DirectAdmin Disk Usage at 100%? Find and Clear It Fast
A disk at 100% is not gradual, everything that writes to it starts failing at once: mail queues, backups, log files, even DirectAdmin's own interface.
A DirectAdmin server hitting 100% disk usage does not fail gracefully. Mail delivery stops mid-message, backups fail partway through leaving corrupt archives, MySQL can refuse writes entirely, and DirectAdmin's own admin interface can become unresponsive since it needs to write session and log data too. The priority is finding what is actually consuming the space fast, not guessing from account sizes alone.
Check DirectAdmin's own usage accounting first
Before reaching for generic Linux disk tools, check whether DirectAdmin's own numbers are even current. DirectAdmin tracks per-account usage through a setting called realtime_quota in /usr/local/directadmin/conf/directadmin.conf, which controls how that figure gets calculated: 2 uses live kernel-level quotactl calls, 1 uses a slower binary-based calculation, and 0 updates usage only on a nightly tally. On a server set to 0, the admin panel and User Usage figures can be up to a day stale, which alone explains a lot of confusing disk-full incidents where the numbers just do not add up.
echo "action=quotatally&value=all" >> /usr/local/directadmin/data/task.queueFor a single account instead of the whole server, target it directly: echo "action=quotatally&value=USERNAME&type=user" >> /usr/local/directadmin/data/task.queue. Either command gets picked up by DirectAdmin's task queue processor (dataskq) within moments, not on the next scheduled cycle. If the recalculation itself fails silently, check /var/log/directadmin/errortaskq.log for the reason before assuming the new number is accurate.
Then confirm what is full at the filesystem level
With DirectAdmin's own numbers ruled out or refreshed, move to the filesystem directly. A server can have plenty of free space on one partition while another (commonly / or /home) is completely full.
df -hIf df and a manual du calculation disagree significantly at this level, that is a separate, filesystem-level issue from anything DirectAdmin's accounting would show.
lsof +L1A non-empty result here means a process (very often a log rotation gone wrong, or a crashed application still holding a large file handle) has a deleted file still consuming space because something has not released its file descriptor. Restarting that specific process, not deleting more files, is the actual fix in this case.
Find the largest consumers
With that ruled out or confirmed, find out where the space is actually going, starting broad and narrowing down.
du -h --max-depth=1 /home/ 2>/dev/null | sort -rh | head -20This ranks accounts by size fast. For the top offenders, go one level deeper to find the specific culprit inside that account.
du -h --max-depth=2 /home/USERNAME/ 2>/dev/null | sort -rh | head -20| Common location | Typical cause |
|---|---|
public_html/wp-content/uploads/ | Unoptimized media, or a compromised account being used as file storage |
logs/ inside the account | Verbose error logging left enabled long-term, or an attack generating massive access logs |
.trash/ or DirectAdmin's own backup retention folders | Old backups or deleted files retained far longer than intended |
A MySQL data directory under /var/lib/mysql | A runaway table, often from unbounded logging into a database table, or an unoptimized InnoDB file that never shrinks automatically |
Check the usual server-level suspects too
Do not stop at hosted account content, server-level logs and system files are a common cause that a per-account scan will miss entirely.
du -sh /var/log/*
du -sh /var/cache/*A mail log (/var/log/maillog or /var/log/exim_mainlog) that has grown to gigabytes is common on a server that has dealt with a spam incident or a sustained attack, since every rejected connection attempt gets logged too. Package manager caches (apt, yum/dnf) can also grow surprisingly large on a server that has not been cleaned in a long time.
apt-get clean # Debian/Ubuntu
dnf clean all # AlmaLinux/Rocky/CentOSClear space safely, in the right order
-
1
Restart any process holding deleted file handles
If
lsof +L1showed anything significant, restart that specific service to actually release the space rather than deleting more files first. -
2
Rotate and compress oversized logs rather than deleting them outright
logrotate -f /etc/logrotate.confforces an immediate rotation, or manually gzip a specific oversized log if you need the historical content retained but compressed. -
3
Clean confirmed-safe caches and old backups
Package manager caches and backup retention older than your actual policy requires are the safest space to reclaim first, with the least risk of breaking anything.
-
4
Address the specific account only after the above
If a single account's content is the genuine cause, contact the account owner before deleting anything that might be legitimate data rather than assuming it is safe to remove.
Working through this checklist correctly under time pressure, with mail and backups already failing, is exactly when it is easiest to trust a stale DirectAdmin number or delete the wrong thing. BashPilot forces a live quota recalculation, cross-checks it against actual filesystem usage, and confirms what is safe to clear before removing anything.
Finding the cause of a sudden disk fill
That gap is expected, DirectAdmin's totals only cover what it attributes to accounts. Forced a fresh quota tally and checked the filesystem directly: /var/log/exim_mainlog has grown to 41GB from a spam incident 4 days ago, well outside anything DirectAdmin tracks.
| Check | Result |
|---|---|
| DirectAdmin account totals (after fresh tally) | 62%, accurate |
| Actual filesystem usage (df) | 100% |
| /var/log/exim_mainlog | 41GB |
Rotating exim_mainlog and confirming exim is writing to the new file before removing the old one. Rechecking free space afterward before declaring this resolved.
logrotate -f /etc/logrotate.d/exim4
df -h /Try this on one of your own servers.
Start free trialVerify the fix actually holds
Freeing space once does not confirm the underlying cause is addressed, especially if logging or backup retention is what caused it originally.
df -h /
watch -n 3600 'df -h / >> /var/log/disk-trend.log'If usage climbs back toward capacity within days rather than the weeks or months it took to get there originally, the actual cause (an attack still ongoing, a log rotation still misconfigured, a runaway database table) was not fully resolved, only the symptom was.
Prevent it happening again
- Set a disk usage alert well below 100%, at 80% or 85%, so you have time to investigate calmly instead of reacting to mail and backups already failing.
- Confirm logrotate is actually running successfully on a schedule, a silently failing rotation is one of the most common root causes of a slow, unnoticed fill.
- Move backup retention offsite or to separate storage rather than keeping months of local backups on the same disk the live server depends on.
