juicedata/juicefs · error

set %s quota: %w

Error message

set %s quota: %w

What it means

Raised by baseMeta.repairUgUsage (pkg/meta/quota.go:1045) when repairUsage fails after cleanUgUsage succeeded. At this point old uid/gid usage records were already wiped, so this error leaves user/group quota usage in a partially repaired state and must be retried to restore correct UsedInodes/UsedSpace values.

Source

Thrown at pkg/meta/quota.go:1045

			quota.MaxInodes = q.MaxInodes
		}
		if _, err := m.en.doSetQuota(ctx, qtype, id, quota); err != nil {
			return err
		}
	}
	return nil
}

func (m *baseMeta) repairUgUsage(ctx Context, qtype uint32, usageMap map[uint64]*Summary, quotaMap map[uint64]*Quota) error {
	idType := "uid"
	if qtype == GroupQuotaType {
		idType = "gid"
	}
	if err := m.en.cleanUgUsage(ctx, qtype); err != nil {
		return fmt.Errorf("clean %s quotas: %w", idType, err)
	}
	if err := m.repairUsage(ctx, usageMap, quotaMap, qtype); err != nil {
		return fmt.Errorf("set %s quota: %w", idType, err)
	}
	return nil
}

func (m *baseMeta) checkUGUsage(ctx Context, repair bool, quotas map[string]*Quota) error {
	userUsage, groupUsage, err := m.scanGlobalUserGroupUsage(ctx)
	if err != nil {
		return fmt.Errorf("scan global user group usage: %w", err)
	}

	_, userQuotas, groupQuotas, err := m.en.doLoadQuotas(ctx)
	if err != nil {
		return fmt.Errorf("load user/group quotas: %w", err)
	}
	hasErr := m.compareUGUsage(userUsage, userQuotas, UserQuotaType, quotas)
	hasErr = m.compareUGUsage(groupUsage, groupQuotas, GroupQuotaType, quotas) || hasErr

	if !repair {

View on GitHub (pinned to c9a67b23e8)

Solutions

1. Re-run `juicefs quota check --repair` immediately — cleaning is idempotent and the set phase will be retried to a consistent state.
2. Read the wrapped %w error to identify the specific backend write failure and address it (connectivity, disk, permissions).
3. After a successful retry, verify with `juicefs quota list` that uid/gid usage values match actual usage.
4. If repeated failures occur, repair one uid/gid at a time to isolate the failing record.

Example fix

// before: repair aborted mid-way (clean done, set failed)
// after: rerun to completion
$ juicefs quota check --repair /mnt/jfs
$ juicefs quota list  # verify uid/gid usage consistent

// confirm engine writable before starting clean+set
if err := m.en.doSetQuota(ctx, qtype, probeKey, probeQuota); err != nil {
    return fmt.Errorf("engine not writable; skip repair: %w", err)
}

if err := repairUgUsage(ctx, qtype, usageMap, quotaMap); err != nil && strings.Contains(err.Error(), "set ") {
    // clean already happened; rerun so the set phase completes
    return repairUgUsage(ctx, qtype, usageMap, quotaMap)
}

When it happens

Trigger: `juicefs quota check --repair` on user/group quotas where doSetQuota/repairUsage errors while writing repaired usage back (backend write failure, quota set rejected, engine outage mid-repair).

Common situations: Metadata engine failure between the clean and set phases; individual quota set rejected by backend; disk full on SQL engine; connection drop mid-repair.

Related errors

• clean %s quotas: %w
• scan global user group usage: %w
• no quota for inode %d path %s
• quota of %s is inconsistent, please repair it with --repair
• load user/group quotas: %w

AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06). Data as JSON: /api/errors/f35b44da0d81da8f. Report an issue: GitHub.