CyberPanel disk full: how to find what's eating space and clean it safely

A full disk is the most common root cause behind "random" failures on a VPS: MariaDB refuses writes, OpenLiteSpeed cannot create its PID file, a package update writes a corrupt binary, the panel's Python venv breaks. It is also the easiest problem to make worse with a reckless rm -rf. Here is the careful way.

Space or inodes?

df -h /
df -i /

Two different problems. Out of space means big files. Out of inodes with space left means millions of tiny files, usually PHP sessions, mail queue items, cache fragments or a runaway log directory. For inodes, du will mislead you; count files instead:

for d in /var /home /tmp /usr/local/lsws /usr/local/CyberCP; do printf "%-24s " $d; find $d -xdev -type f 2>/dev/null | wc -l; done

Find what is using it

du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
find / -xdev -type f -size +200M -printf "%s %p\n" 2>/dev/null | sort -rn | head -20

On CyberPanel servers the usual suspects, in order:

• /var/log/journal — systemd journal without a size cap.
• /usr/local/lsws/logs/ and /home/*/logs/ — OpenLiteSpeed and per-site access/error logs that were never rotated.
• /home/backup, /home/*/backup — CyberPanel backups accumulating.
• /var/lib/mysql — binary logs (mysql-bin.*) left on by default, or a huge ibdata1.
• /var/cache/apt, /var/cache/dnf, /root/.cache/pip — package and pip caches.
• /usr/local/lsws/cachedata and /home/*/lscache — page cache.
• /boot — old kernels.
• /tmp, /var/tmp — temp files and crashed upload fragments.

Deleted files that still take space

If you already deleted something and df did not move, a process is still holding the file open:

lsof -nP +L1 | awk 'NR>1{print $1, $7, $9}' | sort -k2 -rn | head

Restart the owning service to release the blocks: systemctl restart rsyslog for syslog, systemctl restart lsws for web logs. Avoid restarting MariaDB for this unless you have to; truncate its log instead. This is also why the rest of this guide truncates live logs rather than deleting them.

Safe to clean in one go

These do not touch your sites, databases or configuration and can be run together:

# systemd journal: keep 7 days / 200 MB
journalctl --vacuum-time=7d --vacuum-size=200M

# package manager cache
apt-get clean            # Ubuntu
dnf clean all            # AlmaLinux / Rocky

# rotated/archived logs older than 7 days
find /var/log /usr/local/lsws/logs /home/*/logs -type f \
  \( -name "*.gz" -o -name "*.[0-9]" -o -name "*.old" \) -mtime +7 -delete

# large ACTIVE logs: empty them, do not delete them
find /var/log /usr/local/lsws/logs /home/*/logs -type f -name "*.log" -size +100M \
  -exec truncate -s 0 {} \;

# temp files older than a week
find /tmp /var/tmp -xdev -type f -atime +7 -delete

# pip cache (system and the panel venv)
rm -rf /root/.cache/pip; /usr/local/CyberCP/bin/pip cache purge 2>/dev/null

# OpenLiteSpeed / LSCache page cache (rebuilt automatically)
find /usr/local/lsws/cachedata /home/*/lscache -mindepth 1 -delete 2>/dev/null
chown -R nobody:nogroup /usr/local/lsws/cachedata   # AlmaLinux: nobody:nobody

# core dumps
rm -f /core.* /var/lib/systemd/coredump/* 2>/dev/null

Then stop the journal and logs from growing back:

sed -i 's/^#\?SystemMaxUse=.*/SystemMaxUse=200M/' /etc/systemd/journald.conf
systemctl restart systemd-journald

and check that logrotate covers /usr/local/lsws/logs and /home/*/logs; CyberPanel ships a rotation config, but hand-added vhosts sometimes miss it.

MariaDB binary logs

If /var/lib/mysql/mysql-bin.* is large and you are not using replication, purge from inside MariaDB, never with rm:

mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;"
# and cap them: expire_logs_days=3 (or binlog_expire_logs_seconds) in the MariaDB config

Clean only with confirmation

These free a lot of space but each one deserves a look first.

• Old kernels — keep the running one and one spare. Ubuntu: apt-get autoremove --purge. AlmaLinux: dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q). Check uname -r is not in the removal list.
• Old CyberPanel backups — list them with their dates before deleting: find /home/backup /home/*/backup -name "*.tar.gz" -mtime +30 -ls. Make sure newer backups exist, ideally off-server.
• Docker — docker system df, then docker system prune -a only if you know nothing in there is needed.

Never touch

• /var/lib/mysql except through MariaDB itself.
• /home/*/public_html and anything under a user's home that is not a log or a backup you have reviewed.
• /usr/local/lsws/conf, /usr/local/CyberCP, /etc.
• The running kernel and /boot in general.
• Any log modified in the last 24 hours with rm; truncate it if you must.

After cleaning, re-run df -h / and df -i /, then restart whatever was failing because of the full disk. If something was reinstalled while the disk was full, consider reinstalling it again now that there is room, since the earlier copy may be corrupt.