Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

quotaon@<mount>.service fails with 'File exists' on non-root ext4 filesystems that already have the on-disk quota feature

Open
  • Is something wrong?
#197 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
15/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
linux, python
Domain
devops, operating-systems

Research direction

Start with e_fstab.py's check_quota_features() and mask_redundant_quotaon_units(), then inspect commit 5bb7f7e and its merged result 5444a89. The issue reports the fix as released in 7.4.17, so done means verifying that the non-root unit is masked without regressing external aquota handling; no implementation remains.

Written by the indexing model from the issue text.

Description

Description

After a fresh linuxmuster-setup run, [email protected] fails at every boot:

× [email protected] - Enable File System Quotas
    Active: failed (Result: exit-code)
    Process: 976 ExecStart=/usr/sbin/quotaon -ug /srv (code=exited, status=2)

quotaon[976]: quotaon: using . on /dev/sdb1 [/srv]: File exists
quotaon[976]: quotaon: using . on /dev/sdb1 [/srv]: File exists
systemd[1]: [email protected]: Main process exited, code=exited, status=2/INVALIDARGUMENT
systemd[1]: Failed to start [email protected] - Enable File System Quotas.

Root cause

/srv (/dev/sdb1) came out of curtin/mke2fs with the modern ext4 on-disk
quota feature (tune2fs -O quota) already enabled - confirmed from the
customer's setup log:

#### Checking quota feature on /dev/sda2 ....................... Enabled! ####
#### Checking quota feature on /dev/sdb1 ....................... Enabled! ####

Both root (/dev/sda2) and /srv (/dev/sdb1) already had the feature
active before linuxmuster-setup ever ran, so e_fstab.py's
check_quota_features() never called enable_ext4_quota() for either.

Once the on-disk feature is active, the kernel auto-activates quota
tracking as soon as the filesystem is mounted - before any quotaon call
runs. e_fstab.py's own mask_redundant_quotaon_units() already handled
this for root (masking quotaon-root.service/quotaon.service), but
assumed root was the only filesystem that could ever have the on-disk
feature ("it's the only filesystem that ever gets the on-disk feature
here"). That assumption doesn't hold on installers/images whose mke2fs
defaults already bake the quota feature into every ext4 filesystem, not
just root - so systemd's own generated [email protected] unit is left
unmasked and keeps trying (and failing) to turn on what the kernel already
turned on, at every boot.

Fix

Fixed by 5bb7f7e (fix/quotaon-nonroot-ondisk-quota, merged in 5444a89):

mask_redundant_quotaon_units() now takes the ext4_mounts list and, for
every non-root mount whose device already has the on-disk quota
feature (checked via tune2fs -l), masks that mount's specific
quotaon@<escaped-mount>.service instance (name resolved via
systemd-escape --path). Mounts still on the older external
aquota.user/aquota.group mechanism are left untouched, since those
genuinely need quotaon to run after every boot.

Released in 7.4.17.

Remediation for already-affected installs

The fix only takes effect on the next full linuxmuster-setup run, which
isn't something to ask a customer to redo just for this. Manual
workaround for an already-provisioned server:

# quota is already active kernel-side regardless of the failed unit
quotaon -p -u /srv
quotaon -p -g /srv
repquota /srv

sudo systemctl mask [email protected]
sudo systemctl reset-failed [email protected]

🤖 Generated with Claude Code

Dominant language
Python
Stars
13
Forks
9
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from linuxmuster/linuxmuster-base7

All issues in linuxmuster/linuxmuster-base7

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.