VMware ESXi and vSphere Cluster Management

Linux Disk Quotas: User and Group Space and Inode Limits

Learn how Linux disk quotas limit user and group disk space and inode usage, including soft limits, hard limits, grace periods, setup, monitoring, and troubleshooting.

What Linux Disk Quotas Do

A disk quota is a filesystem mechanism that tracks and restricts storage resource use by a user or group. Quotas prevent one account or project from consuming all available storage and affecting other users, services, or system operation.

Unlike a general disk-capacity setting, a quota is applied to a particular mounted filesystem. For example, a quota configured on /data does not automatically limit the same user’s usage on /home, another partition, or another mounted filesystem. Each filesystem that needs independent limits must be configured separately.

Quotas are resource controls, not replacements for file permissions, ACLs, backups, monitoring, or capacity planning. A user may have permission to write to a directory but still be refused because the applicable quota has been reached.

User Quotas and Group Quotas

A user quota applies to one Unix user account. It limits the blocks and inodes attributed to that user on a filesystem.

A group quota limits aggregate usage associated with a Unix group. This is useful for a shared project, research team, department, or service group. If several members store files associated with the project group, their combined usage can count toward the group allocation.

Where the filesystem and implementation support it, user and group quotas can coexist. A write may therefore be subject to an individual user limit, a group limit, and filesystem-wide capacity at the same time. The most restrictive applicable condition determines whether an allocation succeeds.

Block Quotas and Inode Quotas

A block quota, also called a usage quota, limits disk-space consumption. Tools may display usage in filesystem blocks, KiB, MiB, or GiB. Always check the local tool’s unit conventions before entering a limit.

An inode quota limits the number of filesystem objects attributed to a user or group. Inodes store metadata such as ownership, permissions, timestamps, and pointers to file data. In practice, an inode quota is commonly experienced as a file-count limit.

These resources are different. A workload containing a few large files can exhaust a block quota while using relatively few inodes. A workload containing millions of tiny files can exhaust an inode quota while still leaving substantial disk space unused.

Quota type: Block or usage quota. Resource controlled: Disk-space allocation. Typical symptom: Writes or file extensions fail after the block limit is enforced. Typical workload: Backups, media, virtual-machine images, and large datasets.

Quota type: Inode or file quota. Resource controlled: Number of inodes or files. Typical symptom: New file creation fails even when free disk space remains. Typical workload: Mail queues, caches, source trees, build artifacts, and temporary-file workloads.

Soft Limits, Hard Limits, and Grace Periods

A hard limit is an absolute ceiling. Once a user or group reaches the applicable hard block limit, additional block allocation is denied. Once the hard inode limit is reached, creating additional files or other inodes is denied.

A soft limit is a warning threshold that may be exceeded temporarily. Crossing it starts or updates a grace period. The user receives warnings through quota reports and may continue allocating resource for the permitted period.

If the grace period expires while usage remains above the soft limit, further allocation is blocked until usage falls below the relevant soft limit. The grace period applies separately to block and inode usage in implementations that support separate timers.

Usage state: Below the soft limit. Grace timer: Not active. Can allocate? Yes, subject to the hard limit and filesystem capacity. Action: Normal monitoring.

Usage state: Above the soft limit but below the hard limit. Grace timer: Running. Can allocate? Usually yes until the timer expires or the hard limit is reached. Action: Reduce usage before the deadline.

Usage state: At the hard limit. Grace timer: Not relevant to further allocation. Can allocate? No additional blocks or inodes of that type. Action: Remove or move data, or obtain an authorized limit change.

Usage state: Above the soft limit after grace expiry. Grace timer: Expired. Can allocate? Further affected allocation is blocked until usage is below the soft limit. Action: Reduce usage or obtain an authorized policy change.

Grace periods are policy settings. Administrators can view and adjust them using the quota administration tools appropriate to the implementation. Traditional quota systems commonly expose grace information through repquota and allow editing through edquota -t; verify the exact syntax and units on the local system. XFS commonly uses xfs_quota for reporting and administration.

Prerequisites and Mount Configuration

Before enabling quotas, identify the filesystem device, mount point, filesystem type, and current mount options. Safe inspection commands include:

findmnt /data
findmnt -no SOURCE,FSTYPE,OPTIONS,TARGET /data
lsblk -f
df -h /data
df -i /data

The kernel, filesystem implementation, and quota tools must support quota accounting. Quota behavior is activated with filesystem mount options. On traditional ext-family configurations, options commonly include usrquota for users and grpquota for groups. XFS uses filesystem-specific forms commonly written as uquota and gquota, although supported syntax can vary by distribution and version.

Persistent settings are normally placed in /etc/fstab. Do not copy a device name or mount point from an example without confirming the local layout. Preserve a recoverable copy of the file and use change control before editing production mount configuration.

# Illustrative pattern only; verify the existing device, filesystem, and options first
<device>  /data  <filesystem-type>  <existing-options>,usrquota,grpquota  0  2

For an already mounted filesystem, a remount may apply changed options when supported:

mount -o remount /data
findmnt -no SOURCE,FSTYPE,OPTIONS,TARGET /data

A reboot or controlled unmount and mount may be required. A remount does not by itself initialize traditional quota accounting or assign limits.

Initializing Accounting and Enabling Enforcement

Quota accounting means tracking blocks and inodes used by quota subjects. Quota enforcement means actively denying allocations that violate the configured limits.

Traditional quota implementations commonly require a scan after quota support is mounted. quotacheck examines the filesystem and creates or refreshes quota data files. The exact options depend on whether user or group quotas are being checked and on local operational procedures.

# Review local documentation and maintenance requirements first
man quotacheck
quotacheck --help

Some quota-checking workflows require low filesystem activity, disabled quotas, a read-only mount, or temporary unavailability. Follow the procedure for the filesystem and distribution rather than blindly running a scan on a busy production filesystem.

After accounting data exists, traditional implementations commonly use quotaon to enable user and group quotas:

quotaon -v /data
quotaon -ugv /data
quotaon -p /data

quotaoff disables accounting or enforcement and should be used intentionally because it removes the protection quotas provide. XFS generally manages quota state and limits through xfs_quota, so do not assume that a traditional quota-file workflow applies to XFS.

Quota metadata or database files are administrative data, not ordinary user data. Do not manually delete them. Use the filesystem’s quota tools to rebuild or change them.

Assigning User and Group Limits

Quota limits normally include four values for each resource: block soft, block hard, inode soft, and inode hard. The soft limit should not exceed the hard limit. A zero or unlimited value has tool-specific meaning, so confirm it in the local manual before using it to clear a limit.

Interactive Configuration with edquota

On traditional quota implementations, edquota opens a quota record for editing. The displayed block unit may not be the unit you expect; read the header carefully.

edquota -u alice
edquota -g project
edquota -t

The first command edits user alice, the second edits group project, and the third edits grace periods. Use the local filesystem’s supported utility for XFS or another filesystem-specific implementation.

Scriptable Configuration with setquota

setquota is useful for repeatable provisioning and automation. A common traditional form supplies block soft, block hard, inode soft, and inode hard values:

setquota -u alice <block-soft> <block-hard> <inode-soft> <inode-hard> /data
setquota -g project <block-soft> <block-hard> <inode-soft> <inode-hard> /data

Do not assume that placeholders represent GiB. Some tools expect filesystem blocks or KiB, and command-line options differ between implementations. Use man setquota, calculate conversions explicitly, and verify the result with a report. Test automation with a noncritical account first.

For example, a user might receive a 3 GiB block soft limit and a 5 GiB block hard limit. Crossing 3 GiB starts the grace period; reaching 5 GiB blocks additional block allocation. If the grace period expires, the user must reduce usage below 3 GiB before affected writes are accepted again.

Monitoring and Reporting

Users can commonly inspect their own quota with:

quota
quota -s
quota -v

Administrators can produce filesystem-wide reports with repquota:

repquota -a
repquota -ug /data
repquota -s /data

Options vary. Check whether the report is showing users, groups, blocks, inodes, grace status, and the selected filesystem. Review both current usage and limits: a user may be close to a hard limit without yet being over a soft limit, or may have an expired grace period.

Useful checks during routine review include:

• Users above a soft block or inode limit.
• Users approaching a hard block or inode limit.
• Expired block or inode grace periods.
• Groups whose combined project usage is increasing unexpectedly.
• Filesystem-wide free blocks and free inodes.

Command: quota. Purpose: Show a user’s quota usage and limits. Typical user: User or administrator. Caution: Interpret block and inode columns separately.

Command: repquota. Purpose: Produce user or group summaries. Typical user: Administrator. Caution: Select the correct filesystem and understand grace indicators.

Command: edquota. Purpose: Interactively edit limits or grace periods. Typical user: Administrator. Caution: Confirm units and keep soft limits at or below hard limits.

Command: setquota. Purpose: Assign limits noninteractively. Typical user: Administrator or automation. Caution: Validate argument order and units.

Command: quotacheck. Purpose: Scan usage and build traditional quota data. Typical user: Administrator. Caution: Follow safe mount and activity requirements.

Command: quotaon/quotaoff. Purpose: Enable or disable traditional quota operation. Typical user: Administrator. Caution: Disabling enforcement is an intentional service-impacting change.

Command: df -h/df -i. Purpose: Show filesystem block and inode availability. Typical user: User or administrator. Caution: These are filesystem-wide figures, not per-user quota reports.

Command: xfs_quota. Purpose: Manage and report XFS quotas. Typical user: Administrator. Caution: XFS syntax and workflow differ from traditional quota tools.

How Enforcement Affects Applications

When a block quota is enforced, writing new data, extending an existing file, copying a file, or allocating metadata that requires blocks can fail. Applications may report ENOSPC, meaning “no space left on device,” even when df -h shows free filesystem space. In this context, the apparent lack of space can be the user’s or group’s quota, not the entire filesystem.

When an inode quota is enforced, creating a new regular file, directory, link, or other inode can fail. Existing files may still be readable, and an existing file may sometimes be modified if the operation does not require a new inode and has available block quota. A user can therefore have plenty of free disk space but be unable to create an empty file.

Typical responses are to delete or move unnecessary data, reduce the number of small files, wait for an administrator-approved adjustment, or raise an authorized limit. Do not solve an inode problem merely by adding disk capacity: a filesystem with no free inodes, or a user with an inode quota, needs an inode-focused remedy.

Practical Examples

Many Small Files and an Inode Limit

Give a test account ample block capacity but a modest inode soft and hard limit. Create small files in a test directory and monitor both reports:

quota -s testuser
repquota -u /data
df -h /data
df -i /data

As the file count grows, inode usage rises even if block usage remains low. At the hard inode limit, new file creation fails while free disk blocks may remain.

Group Quota for Shared Project Storage

Suppose users alice and bob contribute files to group project on /data. An individual user report shows each member’s usage, while the group report shows aggregate usage attributed to the group:

repquota -u /data
repquota -g /data

Use group ownership and directory-management policies consistently so that the group allocation represents the intended project data. A group quota does not replace directory permissions.

Persistent Enablement Workflow

1. Identify the filesystem, type, mount point, and current options with findmnt.
2. Back up and edit the relevant /etc/fstab entry with filesystem-appropriate user and group quota options.
3. Remount or schedule a controlled restart of the mount.
4. Verify the active options and quota status.
5. Initialize traditional accounting with the appropriate quotacheck procedure, if required.
6. Enable quotas with quotaon, or use the filesystem-specific XFS procedure.
7. Assign limits and confirm them with user and group reports.

Diagnosing Quota Problems

Start with three separate questions: Is the filesystem out of blocks? Is it out of inodes? Is the affected user or group over quota?

df -h /data
df -i /data
quota -v affected-user
repquota -ug /data
findmnt -no SOURCE,FSTYPE,OPTIONS,TARGET /data

Observed condition: df -h shows free space but writes fail. Likely cause: Block hard limit or expired block grace period. Verification: Check user/group block usage and grace status. Resolution: Remove or move data, or change the authorized quota.

Observed condition: Empty-file creation fails while disk space remains. Likely cause: Hard inode quota or filesystem-wide inode exhaustion. Verification: Check quota inode columns and df -i. Resolution: Reduce file count, adjust the inode quota, or address filesystem inode exhaustion.

Observed condition: Quota reports show no limits. Likely cause: Missing mount options, uninitialized accounting, disabled enforcement, or wrong filesystem target. Verification: Inspect findmnt, quota status, and the selected mount point. Resolution: Correct configuration, initialize accounting, enable quotas, and recheck.

Observed condition: Settings disappear after reboot. Likely cause: Options were applied only temporarily or the wrong boot-time mount source is being used. Verification: Compare active options with /etc/fstab and other mount configuration. Resolution: Correct the persistent configuration and validate through a controlled reboot.

Using debugfs Safely

debugfs is an advanced debugging utility for ext-family filesystems. It can inspect filesystem metadata and allocation information when ordinary reports are insufficient, but it is not a general quota-management interface. Prefer read-only inspection:

debugfs -R 'stats' /dev/<confirmed-device>

Confirm the device with findmnt before using any debugging command. Never guess the device name. Avoid write operations unless performing approved expert recovery work with appropriate backups and a maintenance plan; careless debugfs changes can damage the filesystem.

Operational Safety and Maintenance

• Test mount options, accounting, limits, grace periods, and failure behavior on a nonproduction filesystem or representative test account.
• Back up /etc/fstab and use change control for filesystem administration.
• Confirm that the selected filesystem is the one where data is actually stored; bind mounts and nested mounts can complicate diagnosis.
• Schedule quota scans and mount-state changes according to the filesystem’s operational requirements.
• Review block and inode reports routinely, including grace-period policy and approaching limits.
• Document whether zero means unlimited, disabled, or cleared for each local quota tool.
• Repeat quota configuration for every filesystem that needs independent limits.

Summary

Linux quotas control filesystem resource usage for users and groups. Block quotas protect disk capacity; inode quotas protect the supply of filesystem objects. Soft limits provide a warning threshold and grace period, while hard limits are absolute ceilings. Correct administration requires identifying the mounted filesystem, enabling appropriate mount options, initializing accounting where necessary, assigning limits with verified units, enabling enforcement, and validating results with both quota reports and filesystem-wide checks.

For a focused reference, see Linux disk quotas.