Set User and Group Disk Quotas with edquota in Linux

Learn how to configure user and group block and inode quotas with edquota, set grace periods, verify enforcement, and troubleshoot Linux filesystem quotas.

A disk quota is a filesystem policy that constrains how much storage space and how many filesystem objects a user or group can consume. Quotas are useful on shared servers, home directories, mail systems, and other multi-user filesystems.

This lesson focuses on edquota, the administrative command used to edit quota records for users, groups, and filesystem grace periods. The target filesystem must already have quota support enabled and quota accounting initialized before limits can be edited or enforced. Enabling and initializing quota support is a separate storage-administration task.

How Disk Quotas Measure Consumption

Quota systems normally track two different resources:

• Blocks: accounting units for file data and therefore a limit on storage capacity. Quota tools commonly display blocks in 1 KiB units, but administrators should verify the behavior of the local quota tools and filesystem.
• Inodes: filesystem metadata structures representing files, directories, and other filesystem objects. An inode quota limits the number of objects rather than their total data size.

A user can have plenty of unused block quota but still be unable to create a file after reaching an inode limit. Conversely, a user can have unused inodes but be unable to enlarge a file after reaching a block limit.

Editing a User Quota with edquota

Run edquota with the account name to open that user's editable quota record:

edquota bob

The command normally opens the record in the administrator's configured text editor. The record contains one section for each quota-enabled filesystem on which the account has a quota record. Edit the appropriate values, save the file, and exit the editor. Saving the edited record applies the configured limits.

For example, on the quota-enabled filesystem containing Bob's files, a record might contain values conceptually like these:

Filesystem     blocks    soft    hard    inodes    soft    hard
/dev/example   0         6       10      0         0       0

In this example, the block soft limit is 6 and the block hard limit is 10 in the units displayed by the local quota tools. The inode limits remain unlimited. Do not blindly copy these deliberately small values to a production filesystem; they are useful for controlled testing.

Fields in an edquota Record

A limit value of 0 represents unlimited use for that resource. Thus, zero in both inode-limit columns leaves inode consumption unrestricted, while nonzero block limits still constrain data-block usage.

Soft Limits, Hard Limits, and Enforcement

A soft quota is a threshold that may be exceeded during an active grace period. It is intended to give an account time to reduce usage without immediately interrupting work. A hard quota is an immediate ceiling: once the relevant allocation would exceed it, the filesystem can deny the allocation.

Block limits relate to file data capacity. Inode limits relate to the number of files and directories. A failed write or file creation does not always mean the whole filesystem is full: a quota hard limit may have been reached even when system-wide free space remains.

Setting Quota Grace Periods

Use edquota -t to open the grace-period settings:

edquota -t

The editor displays grace periods for quota-enabled filesystems. Set meaningful durations for block soft-limit overages and inode soft-limit overages according to operational policy. For example, a storage service might allow a short period for temporary build files, while a collaborative data filesystem might allow a longer period for users to clean up.

Grace periods apply by filesystem. They are not independently configured for each user. A user can have different soft and hard limits from another user, but the filesystem's policy determines how long a soft-limit overage may remain active.

Editing Group Quotas

A group quota associates resource limits with a Unix group rather than one account. Open a group's quota record with the -g option:

edquota -g users

The group record uses the same core concepts as a user record: current block usage, block soft and hard limits, current inode usage, and inode soft and hard limits. Set the appropriate values, save the record, and then verify the group report.

Group limits control resources charged to the group. They can affect users who belong to that group when their activity is accounted against it. Effective behavior also depends on the filesystem's quota model and the account's group membership. A group quota does not automatically replace an individual user's quota; a user or one of the user's groups may reach its own limiting quota first.

edquota Command Options

Verify Quota Changes

After saving a user record, display the user's current usage and limits:

quota -u bob

For a group, use:

quota -g users

To produce a report across quota-enabled filesystems, where supported, run:

repquota -a

Check the filesystem or device column, current usage, both soft limits, both hard limits, and any grace-period status. A report should show that the intended filesystem—not merely a similarly named mount point—contains the changed values.

Controlled Enforcement Test

1. Choose a noncritical test account and a controlled location on the quota-enabled filesystem.
2. Assign a deliberately small block hard limit, such as the example value of 10 displayed quota units, and leave production accounts untouched.
3. Use the test account to create or enlarge files gradually until the hard threshold is reached.
4. Confirm that a further storage allocation is denied rather than allowing usage beyond the hard limit.
5. If inode limits are configured, separately create many small files and confirm inode behavior as well.
6. Remove the test data and restore the intended policy after testing.

Troubleshooting

No Expected Filesystem in the edquota Record

If edquota does not show the expected filesystem, the filesystem may not have quota support enabled, quota accounting files or metadata may not have been initialized, or the target path may be on a different filesystem.

• Confirm which filesystem contains the user's files.
• Review mount and quota configuration.
• Use quota reporting tools to identify filesystems that are actively tracked.

Writing Continues After a Soft Limit Is Crossed

This can be normal while the grace period is active. It can also happen when the operation does not increase the limited resource—for example, a test that consumes inodes does not necessarily consume many blocks—or when the limit was edited on another filesystem.

• Inspect current usage and all limits.
• Review the filesystem's grace-period values.
• Determine whether the test consumes blocks or inodes.
• Confirm the filesystem shown in the quota record.

File Creation Fails Despite Apparent Free Disk Space

Compare quota output with filesystem-wide free-space output. The account or group may have reached a block hard limit or an inode hard limit. Check both block and inode columns; system-wide free space does not override a per-user or per-group quota.

Group Changes Do Not Appear to Affect Users

• Verify that the account is a member of the intended group.
• Review both user and group quota reports because another quota may be the effective limiting factor.
• Verify that the group record was edited for the filesystem containing the users' data.

Exam-Relevant Notes

• edquota USER_NAME edits a user quota, while edquota -g GROUP_NAME edits a group quota.
• edquota -t changes filesystem-level grace periods, not separate per-user grace periods.
• Blocks limit data capacity; inodes limit the number of filesystem objects.
• A soft limit may be exceeded during its grace period; a hard limit is an immediate ceiling.
• A zero quota limit means unlimited use for that resource.
• Quota support must be enabled and initialized before quota records can be meaningfully edited and enforced.

For related administration work, see Linux quota configuration and reporting.