Configuring File System Quotas for Users on RHEL
File system quotas give administrators a reliable way to control how much disk space each user or group consumes on a Red Hat Enterprise Linux server. When a shared research cluster in Brisbane starts running low on space, the underlying cause is rarely a single runaway process; it is usually a handful of accounts that quietly fill partition after partition. Quotas do not solve the storage problem on their own, but they make the problem visible and prevent any one user from crowding out everyone else.
RHEL ships with a mature quota implementation that integrates with the kernel through the ext4 and xfs modules, and most of the work happens at the terminal rather than through a graphical tool. Before diving into commands, it helps to understand the difference between soft limits, hard limits, and grace periods. For a broader view of day-to-day administration, the Linux and Unix section on Linuxtpoint collects related walkthroughs.
| Feature | Soft Limit | Hard Limit |
|---|---|---|
| Warning issued to user | Yes | No |
| Grace period applies | Yes | No |
| Behaviour when exceeded | Temporary writes allowed | Writes are blocked |
| Best used for | Friendly thresholds | Hard ceilings |
Preparing the Filesystem and Installing Quota Tools
The first step is to confirm that the quota package is present on every host that participates in the policy. On a recent RHEL 9 server in a Sydney data centre, the command is dnf install quota. Once installed, edit /etc/fstab so that the partition carrying home directories carries the usrquota mount flag, then remount it with mount -o remount /home. The kernel will refuse to honour any quota until the mount table reflects this change, so do not skip the remount step.
On xfs filesystems, the option is uquota instead of usrquota, and RHEL recommends leaving the older generic quota tools off the system entirely if xfs is the only filesystem type in use. Universities in Adelaide and Perth that run mixed fleets sometimes keep both ext4 and xfs partitions, which is why the quota package still ships with both code paths enabled by default.
Generating the Quota Database Files
After the filesystem is mounted with the right options, run quotacheck -ugm /home to build the database files aquota.user and aquota.group. The -u flag scans user ownership, -g scans groups, and -m forces a remount so the tool can read a consistent view of the disk. The command can take a long time on large arrays attached to HPC storage in Canberra, so it is worth running it during a quiet period rather than during business hours in AEDT.
Once the files exist, turn the quota system on with quotaon -v /home. From this point forward, every write to that partition is checked against the limits stored in the database. If you ever see "No such file or directory" complaints about aquota.user, the filesystem is probably mounted without the quota option, and rechecking /etc/fstab is the fastest fix before suspecting hardware faults.
Assigning Limits With Edquota and Setquota
Interactive editing of a single user is done through edquota username, which displays the current usage in blocks and inodes and opens a temporary file in the user's preferred editor. The two key columns are soft and hard, both expressed in 1 KB blocks. A reasonable policy on a teaching host in Hobart might be 10 GB soft and 12 GB hard, leaving students enough room to copy course materials without letting a forgotten download fill the disk.
For scripting, setquota -u username 10485760 12582912 0 0 /home applies the same numbers without opening an editor at all. Many Australian higher education IT teams wrap this in a small bash script that runs from a cron job each time a new student account is provisioned, keeping the policy consistent across thousands of accounts. Editors that handle navigation-heavy workflows well, such as the approach described in using emacs bookmarks to jump back to magik debug points, translate nicely to jumping between aquota.user entries when troubleshooting individual users.
Reporting and Monitoring Disk Consumption
Quota reporting belongs in the same automation stack as the rest of system administration. repquota -a /home prints a summary suitable for piping into an awk filter, while warnquota emails users who are over their soft limit. A common pattern on hosted services sold by local providers is to run warnquota from /etc/cron.daily/ and forward the resulting mail through an internal relay so messages reach external students reliably.
Pairing these reports with intrusion-detection coverage such as fail2ban SSH protection gives administrators a fuller picture of what is happening on each host. When a single account suddenly fills its limit, the correlation between quota warnings and failed SSH attempts often points to a misconfigured script rather than malicious activity.
Automating the Workflow Across the Fleet
The real payoff arrives when quota management stops being a one-off task and becomes part of standard provisioning. Wrapping setquota in a function that reads limits from a YAML or CSV file keeps policy changes consistent across a hundred hosts. Keeping /etc/fstab and the provisioning function in version control, recording the rationale behind each value, and testing changes on a single account before rolling them out are simple habits that prevent the policy from drifting over time.
The numbers behind a working quota policy should be remembered as three things: a kernel that knows to check, a filesystem that knows what to enforce, and a script that keeps both in step. Revisit the limits whenever new storage tiers arrive, keep the aquota.user files backed up alongside the rest of /etc, and verify that mount options survive every kernel upgrade. With those three pieces in agreement, quotas become a quiet safeguard that protects users in Sydney, Melbourne, or anywhere else the infrastructure happens to live.