Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / How to Use Linux Server Disk Quotas
Transcript
- Lucas: So we're talking disk quotas today. And I want to start with a real scenario: last month I helped a friend who runs a shared hosting box for a small dev team. They had a hundred gig SSD, maybe a dozen users. One developer accidentally filled the whole disk uploading logs from a test environment. No alert, no warning, just — ssh failed for everyone. Took them four hours to figure out what happened. Luna: Oof. Classic 'who ran the disk full' mystery. And quotas would have prevented that. Lucas: Exactly. Disk quotas let you set hard and soft limits on disk usage per user or per group. When someone hits the soft limit they get a warning, but they can still write. The hard limit is a brick wall. And you can configure grace periods — how long they can exceed the soft limit before it becomes enforced. Luna: I think a lot of sysadmins assume quotas are old-school or unnecessary now that we have containers and cloud storage. But they're still super useful for shared servers, mail servers, even some HPC environments. Lucas: Totally. And the classic Linux quota system — the quota command suite — is battle-tested. It's been around since the early 90s. It's not flashy but it's reliable. So today we'll walk through setting it up on ext4, because that's still the most common filesystem for this kind of thing. Lucas: If today's conversation gives you something you can use in your day-to-day, that's the whole point. And if it was worth a coffee to you, there's a link — buy me a coffee dot com slash fexingo. Keeps the show ad-free and independent. Luna: Yeah, honestly, listener support is what keeps us doing deep dives like this. Appreciate anyone who chips in. Lucas: Alright, back to quotas. First thing: your filesystem needs to be mounted with the 'usrquota' and/or 'grpquota' options. So if you're using ext4, you'd add those to /etc/fstab. Then you remount or reboot. Luna: And there's a step a lot of people miss — you have to create the quota database files. The 'quotacheck' command scans the filesystem and builds aquota.user and aquota.group files at the root of the mount point. Lucas: Right. quotacheck -cugm /target. The -c flag creates the new files, -u is for user quotas, -g for group, -m says don't remount read-only first. Without -m you might need to remount or run from single-user mode. Then you turn quotas on with quotaon. Luna: So now you have the infrastructure. But you still need to actually assign limits. That's where 'edquota' comes in. It opens up the user's current usage in a text editor and you set soft and hard limits in blocks and inodes. Lucas: And blocks are typically one kilobyte on ext4, but you can check with 'dumpe2fs -h' to be sure. A soft limit of 500000 blocks — that's about 500 megabytes. Hard limit of 600000 blocks. Grace period defaults to seven days. You can change that globally in the quota files too. Luna: What about applying the same limits to multiple users? Manually running edquota for each person on a box with two hundred users would be insane. Lucas: Great question. You can use the -p flag to clone from a prototype user. So 'edquota -p prototype_user user1 user2 user3'. Or even loop through a list in a script. Also, there's 'setquota' which is non-interactive — perfect for automation. 'setquota username 500000 600000 0 0 /target' sets soft block, hard block, soft inode, hard inode. Zero means unlimited. Luna: And you can monitor usage with 'repquota', which gives a summary of all users and their current usage versus limits. There's also 'warnquota' which can email users when they're approaching their limits. Lucas: Warnquota is actually a separate utility that reads the quota records and sends emails based on a configuration file, usually /etc/warnquota.conf. You'd set it up as a cron job. But it's not installed by default on many distros — you might need to install the quota-warnquota package on Debian or equivalent. Luna: Let's talk about performance. I've heard that quotas add overhead on every write. Is that still a concern on modern hardware? Lucas: There is some overhead, but it's tiny — we're talking single-digit microseconds per write operation on SSD. On spinning rust it's a bit more, but if you're doing heavy I/O you're probably not running quotas on that filesystem anyway. For most workloads it's negligible. The bigger issue is that quotas are filesystem-specific. They don't work on NFS unless you configure NFS to enforce them on the server side, and then the client sees them as disk full errors. Luna: And that leads to the question: when should you use filesystem quotas versus something like container-level limits or even just monitoring with du and scripts? I think there's a sweet spot for shared user directories, /home partitions, web hosting accounts. Lucas: Right. Containers already have their own limits — like Docker's --storage-opt or Podman's size parameter. But if you're running bare-metal multi-user, quotas are still the simplest. Also, quotas apply per user regardless of what process they're running, which is harder to enforce with containers unless each user has their own container. Luna: One gotcha: if you enable quotas on root filesystem, make sure you also set limits for root. Otherwise system daemons could fill the disk and you won't get warned. Lucas: Good point. Root usually has unlimited by default, but you can set them if you want. Just be careful — you don't want to lock yourself out of writing log files. Also, don't forget to run 'quotacheck' periodically if you have unexpected shutdowns. The quota files can become inconsistent. Most distros have a systemd service for that — quotaon.service triggers quotacheck on boot. Luna: And what about the modern alternative — project quotas? That's ext4's ability to track usage by an arbitrary project ID. Useful for grouping files across users. Lucas: Yeah, project quotas are a separate feature. You mount with 'prjquota', assign a project ID to directories or files with 'chattr -p', then set limits with 'setquota -P'. It's more flexible but also more setup. For typical user-level control, user and group quotas are enough. Luna: One last thing: testing. How do you test that quotas are working without actually filling the disk? You can use 'dd' with a small block size and count — but that's destructive. There's a tool called 'quota_nld' that sends netlink messages? But I usually just check 'repquota' after writing some files as a test user. Lucas: That's the practical way. Create a test user, set a very low soft limit — like 1 megabyte — then try to copy a file larger than that. You'll get a disk quota exceeded error. Then check 'repquota' to confirm the limit was hit. Also, the 'quota' command shows your own usage. So have the test user run 'quota' to see their current usage and limits. Luna: Alright, I think we've covered the essentials: setup, monitoring, and some pitfalls. I'm curious — have you ever deployed quotas in production in a way that backfired? Lucas: Once I set a soft limit too low on a mail server's /var/spool/mail partition. Users got warnings when their mailbox hit 50 megabytes. But with modern email with attachments, that fills up fast. I had to raise the limit and extend the grace period. The lesson: understand your workload before setting limits. Profile storage usage first with something like 'du -sh /home/*'. Luna: Right. And remember that quotas only limit disk space and inodes. They don't limit file count per se — but inode limits effectively do that. Each file uses one inode. So if you set a 1000 inode hard limit, they can have at most 1000 files, regardless of size. Lucas: Exactly. Inode limits are crucial for mail servers where small files pile up. So you'll want to set both block and inode limits. The quota tools make it easy. And with that, I think we've given our listeners a solid foundation. Try it on a test box — it's one of those things that's simple once you've done it once. Luna: And if you hit a snag, the quota documentation is actually good. 'man quota' is your friend. Lucas: Linux Server Admin with Fexingo — we'll be back next episode with another deep dive. Until then, keep your disks tidy.