When every account in WHM » List Accounts shows a quota of “unlimited” or disk usage of 0 MB, the accounts have not actually lost their limits. The kernel is no longer enforcing or reporting filesystem quotas on /home, so cPanel has nothing to show. It happens after a fresh install where the mount options were never set, after a migration to a new volume, after a kernel or OS upgrade that changed how XFS handles quotas, and sometimes simply after a reboot on a server where /etc/fstab was edited by hand. The fix is short, but XFS and ext4 need different handling and getting it wrong can mean a reboot.
Applies to cPanel & WHM on AlmaLinux 9 and 10 (XFS and ext4)
Table of Contents
Short answer: The kernel has stopped enforcing filesystem quotas on /home, so cPanel has nothing to report. Run /scripts/fixquotas; on ext4 it adds usrquota to the mount, remounts and runs quotacheck, while on XFS you must add uquota to /etc/fstab (or rootflags=uquota on the kernel line for an XFS root) and unmount and remount, or reboot, because XFS cannot enable quotas on a live remount. Confirm with quotaon -p /home and repquota -a.
Confirm what the kernel is doing
Start by checking whether quotas are active at all on the filesystem holding /home:
findmnt -no SOURCE,FSTYPE,OPTIONS /home
quotaon -p /home
repquota -a | headIf /home is not a separate mount, run the same commands against /. quotaon -p reports whether user quotas are on or off. If it says off, or if repquota returns nothing, the kernel is not tracking usage. Also confirm cPanel agrees:
whmapi1 accountsummary user=USERNAME | grep -E 'disklimit|diskused'Run fixquotas first
cPanel’s own repair script handles the common cases: it adds the right mount options, remounts, runs quotacheck where the filesystem type requires it, and turns quotas on:
/scripts/fixquotasWatch the output. On ext4 it runs quotacheck -avugm, which walks the whole filesystem and can take a while on a large volume with heavy I/O; do it out of hours. On XFS it usually reports that quotas need a mount option and a remount, which is where the XFS caveat below applies. When it finishes, re-run repquota -a and reload List Accounts. If the numbers are back, you are done apart from verifying the mount is persistent.
ext4: mount options and quotacheck
On ext4, quotas are enabled through mount options and stored in aquota.user at the root of the filesystem. The /etc/fstab entry needs usrquota (and grpquota if you use group quotas, which cPanel does not by default):
UUID=... /home ext4 defaults,usrquota 0 2Then apply without a reboot:
mount -o remount /home
quotacheck -cugm /home
quotaon -v /homeModern ext4 also supports journaled quotas set at tune2fs level (tune2fs -O quota /dev/sdX), which do not need the aquota files or quotacheck. cPanel works with either. A common pitfall on ext4 is a stale aquota.user from a previous filesystem copied over during a migration with rsync; delete it and re-run quotacheck.
XFS: the option must be set at mount time
XFS is the default on AlmaLinux 8, 9 and 10 and it treats quotas differently. The uquota (or usrquota) option cannot be applied by remount; the filesystem must be unmounted and mounted again with the option, or the server rebooted. That is fine for a separate /home, but for a root filesystem it means a reboot, and for an XFS root you also have to pass the option on the kernel command line:
grubby --update-kernel=ALL --args="rootflags=uquota"For a separate /home on XFS, the fstab line is:
UUID=... /home xfs defaults,uquota 0 0Then, out of hours, stop the services that hold files open in /home and remount:
systemctl stop httpd cpanel exim dovecot mariadb
umount /home
mount /home
quotaon -p /home
systemctl start mariadb dovecot exim cpanel httpdIf umount fails with “target is busy”, lsof +D /home | head shows what is still open; usually a PHP-FPM pool or a stuck backup. XFS tracks usage in its metadata, so no quotacheck is needed and quotas are accurate as soon as the mount comes up. If the option was already in fstab but quotas are still off, the mount happened before the option was added, and a remount is all that is missing.
On AlmaLinux 10 with the initcall_blacklist or module hardening applied for the 2026 kernel mitigations, nothing changes for quotas, but check dmesg | grep -i quota after the mount for any complaint from the kernel.
cPanel-side data drift
Occasionally the kernel is fine but cPanel’s cached usage is wrong: an account shows 0 MB while repquota shows gigabytes. cPanel reads the values through quota calls but also caches them for the interface. Refresh both:
/scripts/fixquotas
/usr/local/cpanel/scripts/update_db_cache
/scripts/updateuserdomainsAlso make sure the quota is actually set on the account, not just on the package: whmapi1 editquota user=USERNAME quota=10240 sets a 10 GB limit, and quota=0 is unlimited. Accounts created while quotas were off may have been created with an implicit 0.
Mail and database usage
Two figures in cPanel are not filesystem quotas and confuse the picture. Mailbox quotas are Dovecot’s own, held in /home/USER/etc/DOMAIN/quota, and show correctly even when filesystem quotas are broken. Database usage is included in an account’s total only if WHM » Tweak Settings » Include databases in disk usage calculations is on, and it comes from MariaDB’s data directory, not /home. If a customer’s total does not match du -sh /home/USER, check that setting before assuming quotas are wrong.
Verify
After the fix, all of these should agree for a test account:
quota -u USERNAME
repquota /home | grep USERNAME
whmapi1 accountsummary user=USERNAME | grep -E 'disklimit|diskused'Create a large file as that user to confirm enforcement, and expect a “Disk quota exceeded” error at the limit:
su -s /bin/bash USERNAME -c 'dd if=/dev/zero of=~/quotatest bs=1M count=20000'
rm -f /home/USERNAME/quotatestFinally, reboot at a maintenance window once and re-check quotaon -p /home afterwards. A quota setup that survives a reboot is the only one that counts, and fixquotas is worth a place in your post-migration checklist alongside the steps in migrating cPanel accounts to a new server.
CPanel quotas unlimited at a glance
Official documentation: cPanel & WHM documentation, AlmaLinux wiki, Linux man pages.
Related guides: Replacing cxs: malware scanning with LMD (maldet), ClamAV and ImunifyAV on hosting servers · “cPanel license is invalid”: troubleshooting manage2, IP changes and firewalls · Incident response after a cPanel root-escalation CVE: rotating keys, hunting .sorry, auditing sessions.
Frequently asked questions
Does fixquotas work on XFS without a reboot?
Only if /home is a separate XFS filesystem that you can unmount and remount with the uquota option; an XFS root filesystem needs rootflags=uquota on the kernel command line and a reboot.
How long does quotacheck take on a large ext4 /home?
It scans every inode on the filesystem, so a multi-terabyte volume with millions of files can take from tens of minutes to a few hours under load; run it out of hours, or use journaled quotas via tune2fs to avoid it.
Can I run fixquotas while customer sites are live?
On ext4, yes, though quotacheck adds I/O; on XFS the unmount step requires stopping Apache, Exim, Dovecot, MariaDB and cPanel briefly, so schedule it as a maintenance window.
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
- Supported versions
- cPanel & WHM on AlmaLinux 9 and 10 (XFS and ext4)
- Last full review
- Next review