Configuring Disk Quotas for Users on a Linux Server

Disk quotas: how a single process can fill up a server

Disk quotas are not just "hygiene" but protection against a specific class of incidents.

All it takes is one process — a log collector, a cache agent, a script with debugging enabled, or a stuck report exporter — writing to a shared partition, and disk utilization begins to grow unnoticed: monitoring graphs look flat until the moment free space is down to a matter of minutes.

Partition overflow does not hit the service that writes the most. First, logs stop growing, so the cause is not visible; then task queues and data ingestion stall, and after the service stops, the application returns write errors even though the process is alive.

Diagnostics take twice as long: first you have to free up space, then figure out who filled the partition and with what.

A threshold on the graph of "less than ten percent free" does not save you: less time passes between the notification and the partition filling up than the on-call engineer needs to investigate.

Quotas flip the logic — the limit is placed on a specific account or group, separately by volume and by number of inodes.

This is how XFS and ext4 do it: the soft limit signals and gives time to react, while the hard one simply prevents further writes, keeping the partition alive for everyone else.

We explain how this is addressed: what limits to set for service and human accounts, where the boundary between quotas and rotation lies, and what to do when the limit has already been reached.

What space limits deliver: measurable effects

Without a space limit, a volume with logs, build artifacts, and caches grows according to the fastest scenario present on it. Overflow arrives at an inconvenient moment, diagnostics take hours, and cleanup and service restarts are done manually under pressure.

This works on two thresholds: a soft limit with a grace period warns the directory owner, while a hard one blocks writes for a specific user. Then there is utilization reporting by users and directories, and a notification that fires before space runs out.

XFS maintains quotas at project level — convenient when the budget is needed not by a person but by a service.

The effect is not "order on disk" but controlled failure: the application gets a write error at its limit rather than bringing down the entire node.

Free space remains for the system and for services that must not stop, and growth of provisioned volume is aligned with actual consumption.

Disk quota options: comparison of modes and limits

Quota modes differ not so much in the limit value as in how the system reacts when it is reached.

The same limit on a partition with home directories and on a partition with working logs yields different results: in one place it is a warning with time to spare, in another it is a build interrupted mid-write. Below are the options and conditions under which each is appropriate.

Volume and object count limits are set independently, so modes are combined on one volume: the soft limit is set noticeably below the hard one, and the grace period is sufficient to handle the load. Next we discuss how this is configured and verified.

Implementation procedure: from audit to policy handover

We structure the work so that thresholds come from the actual consumption picture, not from partition size. Each stage ends with an artifact that can be verified and handed over to the on-call shift.

1. Utilization audit. We collect a snapshot by partitions and accounts: where large data resides, who grows faster than others, how much logs and temporary files occupy.

   We look at both volume and object count: a directory of small files will exhaust the resource before space runs out.

2. Allocation scheme. We categorize partitions by purpose: home directories, working data, service and temporary areas. For each group, we decide what to limit — volume, object count, or both parameters at once.

3. Threshold configuration. We set a soft and hard limit and a grace period: soft warns and gives time to remove excess, hard stops writing. We apply the baseline profile to new accounts, and exceptions to builds and repositories with predictable growth.

4. Trigger verification. We test on a separate account: at the soft limit a warning arrives, at the hard limit writing stops, and already written data remains intact.

5. Alerts and reporting. Over-limit reports and free space metrics go to the monitoring system — the administrator learns about the problem from an alert, not from a failed service.

6. Policy handover. We provide the partition scheme, threshold values, procedure for granting exceptions, and on-call instructions, including removing the limit when restoring from backup.

Thresholds are adjusted without repartitioning, so limits are revised selectively rather than repeating the entire audit.

Deliverable package: configurations, schemes, and policies

The work ends not with quotas enabled but with a package that your team can use to change limits, troubleshoot incidents, and plan volume expansion on its own.

We document everything in your repository and in the documentation alongside the rest of the infrastructure, so artifacts do not end up in a separate folder on someone's laptop.

• Quota configurations: mount options usrquota, grpquota, or prjquota, soft and hard limit values, separate inode threshold — as ready-made fragments for your configuration files.
• Data placement scheme: what is moved to a separate volume, where home directories are, where build temporary files and logs are, and which limit applies to each partition.
• Limit table by roles and groups: how much is allocated to developers, service accounts, build agents, and backup storage — and the rationale for each threshold.
• Maintenance policy: how often utilization reports are generated, how limit changes are approved, and at what volume fill rate expansion is triggered.
• On-call instructions: step-by-step troubleshooting for "the partition is out of space" — how to find the consumer within minutes, temporarily raise the threshold, and restore the value.
• Utilization report: export by users and groups with top consumers and trends, using the same script that runs on schedule.
• Set of scripts and jobs: enabling quotas, generating reports, notification when the soft threshold is exceeded — in version control, with edit history.
• Rollback procedure: how to remove limits without data loss, and what to check in logs if a service does not start after quotas are enabled.

We test the package on your staging environment: we run over-limit scenarios and review them together with the on-call shift — after that, maintaining the limits does not require our involvement.

Case study: how we stopped uncontrolled partition growth

In one project with a high-load backend, the root partition and /var regularly went above 90%: application logs were not rotated, build directories accumulated artifacts, and debug database copies settled in /tmp.

Once a week, the on-call engineer searched for the largest consumers with du and cleaned files manually, but a few days later space ran out again — partition growth was not a one-off failure but a steady trend.

What we changed: /var/log, /home, /srv, and build directories were moved to separate volumes, and per-user and per-group quotas were enabled — a soft limit with a one-week grace period and a hard ceiling after which writing simply does not go through.

We separately limited the number of inodes; otherwise, a single process with a million small files occupies the partition without showing noticeable volume.

Log rotation was tied to size and retention period, build directories got a timer that deletes artifacts older than a few days, and metric collection via Prometheus added quota visibility: you can see who is approaching the limit before the user notices.

A notification at 80% utilization with a growth-rate forecast replaced reacting to an incident with preparing for it.

There were no incidents due to remaining space during the observed period, and manual cleanup ceased to be a regular duty: space frees itself before the on-call engineer opens a terminal.

With the same load profile, the partition stays one-third free, and rolling back to the previous state is no longer needed.

What to do if the partition is already full and services do not start

A full partition by itself rarely brings down a service — failure comes through details: the application cannot create a temporary file, append to a log, or open a socket, and the service does not start with an unclear return code. So first we determine what exactly occupies the partition, and only then clean up.

Files deleted in a directory but held open by processes will not free space: it is released only after the service is restarted, and cleaning the directory again is useless.

Temporary directories are cleaned by file age, not entirely — active operations last minutes, and deleting a fresh file interrupts them mid-way.

We enable limits immediately after freeing space, with two thresholds: soft — warning and time to clean up, hard — stop writing. We set a limit on both volume and file count: a directory with many small files exhausts the partition before it is exhausted by volume.

To prevent recurrence, we keep user data on a separate partition, limit logs by size with rotation, and track fill percentage with alerts at two thresholds. Then overflow of one user's directory stops their tasks rather than the startup of all services.

Technical concerns before starting work

Quotas change not so much disk layout as working habits: before implementation, exports, logs, and intermediate copies were written "however they turned out"; after, writing stops when the hard limit is exhausted.

Therefore we set a soft limit with a grace period for clearing backlogs, and set the hard one with headroom for peak tasks and configure an advance warning to the owner before write failures occur.

Then three questions remain that most often stall the decision: whether complaints from employees will flood in, whether backup will break, and what to do with services that the limit hinders by their very nature.

Is this compatible with backup?

Copying from a superuser account is not limited by quotas, so full backup and restore proceed as usual. We check something else: that snapshots and exports do not go into the service user's quota and that the target storage retains headroom. We document these paths separately in the policy.

What about system services and exceptions?

Mail, database, logs, and web server write under their own accounts, and a shared limit for them is a bad idea: a write failure in the log will result in lost events.

We put such accounts into a separate policy: either an increased limit or quotas disabled, with directory growth controlled by monitoring.

Can it be rolled back if the policy interferes with work?

Yes. Enabling and removing quotas does not require repartitioning: mounting with quota support, applying the policy to groups, checking against the report. If the limit interferes, it is disabled selectively for a specific group or user, and the data itself is not affected.

Let's discuss the task and come back with an estimate and plan

The estimate for disk quotas depends on how storage is structured in your case: sometimes it is enough to enable quotas on an existing partition, while in others repartitioning and migration without service downtime are needed.

Describe the current picture across your servers — we will come back with an estimate and a plan that includes the limit placement scheme, work procedure, and implementation timeline.

What would be useful to tell us or send:

• Partition and mount point scheme: where quotas are already enabled and where space is consumed uncontrollably.
• List of accounts and groups — limits are assigned to a group, not manually to each user.
• Which services write to disk: home directories, mail, backups, working datasets — so that the quota does not stop a necessary process.
• What has already happened: partition overflow, write failure, downtime — and how they were detected.
• Requirements for consumption control: who receives a notification and at what threshold, and whether a regular report is needed.
• Acceptable maintenance window: whether the partition can be remounted or whether it must be done without service downtime.

Let's discuss the task in detail: our engineers will prepare a quota scheme with separate thresholds for groups, an implementation procedure — from one user group to all — and realistic timelines. After the plan is approved, we start work.