bootstrap user '{}' requires group '{group}', but that group

Error message

bootstrap user '{}' requires group '{group}', but that group is absent

What it means

validate_requests cross-checks group references: for every present user, each referenced group (primary via group= and supplementary via groups=) is looked up in the managed groups map; if config explicitly declares that group state = "absent", the configuration is self-contradictory (create/keep a user that needs a group you are deleting) and parsing fails with both names.

Source

Thrown at src/system/accounts.rs:608

    }
}

fn validate_requests(groups: &[GroupRequest], users: &[UserRequest]) -> Result<()> {
    let managed_groups = groups
        .iter()
        .map(|group| (group.name.as_str(), group.state))
        .collect::<IndexMap<_, _>>();
    for user in users
        .iter()
        .filter(|user| user.state == AccountState::Present)
    {
        for group in user
            .group
            .iter()
            .chain(user.groups.iter().flat_map(|groups| groups.iter()))
        {
            match managed_groups.get(group.as_str()) {
                Some(AccountState::Absent) => bail!(
                    "bootstrap user '{}' requires group '{group}', but that group is absent",
                    user.name
                ),
                Some(AccountState::Present) => {}
                None if nix::unistd::Group::from_name(group)?.is_none() => bail!(
                    "bootstrap user '{}' requires undeclared group '{group}'",
                    user.name
                ),
                None => {}
            }
        }
    }
    Ok(())
}

fn inspect_user(name: &str, desired_uid: Option<u32>) -> Result<UserInspection> {
    let Some(user) = nix::unistd::User::from_name(name)? else {
        return match desired_uid {

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

Decide the group's fate: if users need it, set the group state = "present" (or delete its absent entry).
If the group should go, first remove/change the users that reference it (state = "absent" or new group/groups values).
Watch for config layering: check `mise config ls`/layered output for a layer declaring the group absent.

Example fix

# before
[bootstrap.groups.deploy]
state = "absent"
[bootstrap.users.app]
state = "present"
group = "deploy"
# after — either keep the group
[bootstrap.groups.deploy]
state = "present"
# or move the user off it
[bootstrap.users.app]
state = "present"
group = "app"

Defensive patterns

Strategy: validation

Validate before calling

python3 - <<'EOF'
import sys, tomllib
cfg = tomllib.load(open('mise.toml','rb'))
b = cfg.get('bootstrap', {})
managed = {n: g.get('state') for n, g in b.get('groups', {}).items()}
for name, u in b.get('users', {}).items():
    if u.get('state') != 'present':
        continue
    refs = ([u['group']] if 'group' in u else []) + list(u.get('groups', []))
    for g in refs:
        if managed.get(g) == 'absent':
            sys.exit(f"user '{name}' needs group '{g}' but config marks it absent")
EOF

Type guard

def user_groups_not_absent(user: dict, managed_group_states: dict) -> bool:
    refs = ([user['group']] if 'group' in user else []) + list(user.get('groups', []))
    return all(managed_group_states.get(g) != 'absent' for g in refs)

Prevention

When deprovisioning a group, grep the config for users referencing it first.
Keep group lifecycle and its users in the same config file/review.
Check layered configs (`mise config ls`) for a layer that removes a group another layer uses.

When it happens

Trigger: A mise.toml where [bootstrap.groups.deploy] has state = "absent" while some [bootstrap.users.<name>] with state = "present" lists deploy in group = "deploy" or groups = ["deploy"].

Common situations: Deprovisioning a shared group but forgetting the users that depend on it; config layers disagreeing (one layer removes the group, another adds a user to it); renaming a group in one place only.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/1ab3d0fea1b651f6. Report an issue: GitHub.