# cPanel Quotas Unlimited: fixquotas Repair Source: https://srvscripts.com/guides/cpanel-quotas-unlimited-fixquotas/ Updated: 2026-10-03 Publisher: srvScripts (https://srvscripts.com/) 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. In short: The kernel has stopped enforcing filesystem quotas on /home, so cPanel has nothing to report. **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 | head ``` If `/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/fixquotas ``` Watch 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 2 ``` Then apply without a reboot: ``` mount -o remount /home quotacheck -cugm /home quotaon -v /home ``` Modern 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 0 ``` Then, 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 httpd ``` If `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/updateuserdomains ``` Also 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/quotatest ``` Finally, 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](/guides/migrate-cpanel-accounts-new-server/). ## CPanel quotas unlimited at a glance **Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [AlmaLinux wiki](https://wiki.almalinux.org/), [Linux man pages](https://man7.org/linux/man-pages/). **Related guides:** [Replacing cxs: malware scanning with LMD (maldet), ClamAV and ImunifyAV on hosting servers](https://srvscripts.com/guides/cxs-replacement-malware-scanning/) · [“cPanel license is invalid”: troubleshooting manage2, IP changes and firewalls](https://srvscripts.com/guides/cpanel-license-is-invalid/) · [Incident response after a cPanel root-escalation CVE: rotating keys, hunting .sorry, auditing sessions](https://srvscripts.com/guides/cpanel-root-escalation-incident-response/). ## 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.