📊 Managing Disk Quotas on Linux with AI Assistance

The classic shared-server outage: one user’s runaway log or forgotten core dump fills /home, and now nobody can log in, write a session file, or run a job. Disk quotas are the boring, decades-old answer to this, and the reason people skip them is that the tooling is genuinely confusing — there are two completely different quota systems depending on whether you’re on ext4 or XFS, the mount options differ, and the commands have cryptic flags. This is a perfect spot to lean on an AI assistant as a fast junior engineer: it knows which quota system applies to your filesystem and translates the flag soup, while I verify and apply the limits as the human in the loop. Here’s how I set them up.

Knowing which quota system you have

The very first question — and the one people get wrong — is which filesystem you’re on, because ext4 and XFS handle quotas differently.

findmnt /home
df -T /home

If it’s xfs, quotas are enabled via mount options and managed with xfs_quota. If it’s ext4, you use the quota package and quotaon. Paste the df -T output into an AI and ask which quota toolchain applies; getting this right up front saves you from running ext4 commands against an XFS filesystem and wondering why nothing works.

Enabling quotas on ext4

For ext4, quotas are turned on by remounting with the right options, then initializing the accounting database.

# In /etc/fstab, add usrquota,grpquota to the /home options, then:
sudo mount -o remount /home
sudo quotacheck -cugm /home
sudo quotaon -v /home

quotacheck builds the accounting files, quotaon activates enforcement. When the remount fails or quotacheck complains, hand the error to the AI — it’s good at spotting that you need the usrquota option in fstab versus an outdated quota option that silently does nothing.

Pro Tip: Always set a soft limit below the hard limit with a grace period. The soft limit warns and starts a countdown; the hard limit is an absolute wall. Giving users a grace period turns “I’m suddenly locked out” into “I got a warning and cleaned up,” which is a far better operational experience.

Setting limits the modern way

setquota applies limits non-interactively, which is what you want for scripting and reproducibility.

# soft 5G, hard 6G for user jdoe on /home (values in KB blocks)
sudo setquota -u jdoe 5242880 6291456 0 0 /home
sudo edquota -t                 # set the grace period

The four numbers (block soft, block hard, inode soft, inode hard) are easy to mix up. Describe what you want in plain English — “soft 5GB, hard 6GB, no inode limit for user jdoe” — and let the AI produce the exact setquota line with the KB math done correctly. I keep these quota prompts in a shared prompt library so limits are set consistently across servers.

XFS quotas are a different animal

On XFS, you don’t run quotaon; you enable quotas at mount time and manage them through xfs_quota.

# fstab option: uquota,gquota — then manage with:
sudo xfs_quota -x -c 'limit bsoft=5g bhard=6g jdoe' /home
sudo xfs_quota -x -c 'report -h' /home

The -x expert mode and the -c command syntax are unintuitive, and the unit suffixes (5g) work here but not in ext4’s setquota. This inconsistency between the two systems is exactly what an AI copilot smooths over — ask it for “the xfs_quota equivalent of this setquota command” and it translates cleanly.

Reporting and finding the offenders

When the disk is filling, you need to see who’s over before you start deleting.

sudo repquota -s /home          # ext4 summary
sudo xfs_quota -x -c 'report -h' /home   # xfs summary

These reports are tabular and easy to skim, but on a busy server with hundreds of users they’re long. Paste the report into the AI and ask it to list the top five users by usage and flag anyone over their soft limit. It’s a quick filter that points you at the right account.

Verifying enforcement actually works

Don’t assume a limit is enforced just because you set it. Prove it as the user.

sudo -u jdoe bash -c 'dd if=/dev/zero of=~/bigfile bs=1M count=7000'

If quotas work, this fails when it crosses the hard limit. Clean up the test file afterward. The AI helped you build the limits; this confirms the kernel actually enforces them.

Project quotas: limiting a directory, not a user

A newer and often better model, especially on XFS, is the project quota — it caps a directory tree regardless of who owns the files inside. This is ideal for per-tenant or per-application directories on shared storage.

# XFS project quota: tie a project ID to a path, then limit it
echo '42:/srv/tenants/acme' | sudo tee -a /etc/projects
echo 'acme:42' | sudo tee -a /etc/projid
sudo xfs_quota -x -c 'project -s acme' /srv
sudo xfs_quota -x -c 'limit -p bhard=50g acme' /srv

The two config files map a name to an ID to a path, and then you limit the project. This is fiddly enough that I always have the AI generate the full sequence from a plain description (“cap /srv/tenants/acme at 50GB as an XFS project quota”). It gets the /etc/projects and /etc/projid format right and orders the project -s setup before the limit, which is a step people forget.

Pro Tip: Reach for project quotas instead of user quotas whenever the thing you actually want to limit is a directory, not a person — multi-tenant app data, per-customer upload folders, CI workspaces. User quotas can’t express “this folder gets 50GB no matter who writes to it,” and project quotas do it cleanly.

Monitoring quota usage proactively

Quotas only help if you notice people approaching them before they hit the wall. A periodic report you can alert on closes that loop.

sudo repquota -a | awk '$4 > 0 && $3 > $4*0.9'

That surfaces accounts over 90% of their soft limit. Ask the AI to wrap this into a script that emits a warning line per near-limit user, suitable for piping into your alerting. Read the generated script before scheduling it — confirm it only reports and doesn’t modify quotas. Wiring this into the monitoring-alerts dashboard turns “surprise lockout” into “we saw it coming a week out.”

Keeping it safe

The safety rules hold even for something as benign-seeming as quotas. The AI translates the toolchain and drafts the commands, but you verify which filesystem you’re on before running anything, you test enforcement on a non-critical account first, and the AI never runs quotaon, setquota, or xfs_quota against your servers — and it never gets credentials. It is a fast junior engineer fluent in two confusing quota systems; the human applies the limits and confirms them. Mis-setting a quota can lock real users out of a shared box, so a human signs off on production limits. For tracking these changes, our code-review dashboard keeps the quota config diff and its reasoning together.

Conclusion

Disk quotas prevent a whole class of “one user took down the server” outages, and the only real barrier — the split between ext4 and XFS tooling — is exactly what an AI copilot erases. Identify the filesystem, enable accounting, set soft and hard limits with a grace period, report on the offenders, and verify enforcement. The AI translates the flags; the human owns the limits and execution. More guides in the Linux admin category, and the Linux admin prompt pack includes the quota-setting prompts I use on shared hosts.