managed system files require group '{group}', but that boots

Error message

managed system files require group '{group}', but that bootstrap group is absent

What it means

This error is thrown when a managed-file plan references a system group, the group exists in the account requests, but its declared state is Absent (i.e. the same run plans to remove it). Managed system files require their owning group to exist, so the library refuses to converge files owned by a group it is simultaneously deleting. It is a precondition check in the group resolution path of managed_files.rs.

Source

Thrown at src/system/managed_files.rs:880

                Some(request)
                    if allow_pending_accounts
                        && request.plan().action == ResourceAction::Unknown =>
                {
                    bail!(
                        "managed system files require owner '{owner}', but that bootstrap user cannot be safely converged"
                    )
                }
                Some(_) if allow_pending_accounts => {}
                Some(_) | None => {
                    resolve_user(owner)?;
                }
            }
        }
        if let Some(group) = group {
            match accounts
                .and_then(|accounts| accounts.groups.iter().find(|request| request.name == group))
            {
                Some(request) if request.state == super::accounts::AccountState::Absent => bail!(
                    "managed system files require group '{group}', but that bootstrap group is absent"
                ),
                Some(request)
                    if allow_pending_accounts
                        && request.plan().action == ResourceAction::Unknown =>
                {
                    bail!(
                        "managed system files require group '{group}', but that bootstrap group cannot be safely converged"
                    )
                }
                Some(_) if allow_pending_accounts => {}
                Some(_) | None => {
                    resolve_group(group)?;
                }
            }
        }
    }
    Ok(())

View on GitHub (pinned to afd2eddd3a)

Solutions

Remove or change the Absent state for that group in the AccountRequests, or stop referencing it as the file's `group`.
Point the managed file entries at a group that is present (state not Absent) in the account requests.
Split the run: remove the group only after files no longer depend on it.

Example fix

// before
AccountRequest { name: "deploy", state: AccountState::Absent }
FileEntry { path: "/etc/app.conf", group: Some("deploy"), .. }

// after
AccountRequest { name: "deploy", state: AccountState::Present }
FileEntry { path: "/etc/app.conf", group: Some("deploy"), .. }

Defensive patterns

Strategy: validation

Validate before calling

let absent: Vec<_> = files.iter().filter_map(|f| f.group.as_ref()).filter(|g| accounts.groups.iter().any(|r| &r.name == *g && r.state == AccountState::Absent)).collect();
if !absent.is_empty() { return Err(format!("groups declared absent but referenced by files: {absent:?}")); }

Type guard

fn group_is_present(name: &str, accounts: &AccountRequests) -> bool {
    accounts.groups.iter().find(|r| r.name == name)
        .map_or(true, |r| r.state != AccountState::Absent)
}

Prevention

Cross-check group references in file entries against account request states at config load
Never mark a group Absent in the same run that manages files owned by it
Add a config lint that detects absent groups still used as file owners

When it happens

Trigger: Calling the managed-files planning API with a file/directory entry whose `group` matches an entry in the AccountRequests groups list that has state == AccountState::Absent. Passes `allow_pending_accounts` is irrelevant here because Absent is an explicit request, not an unknown/pending plan.

Common situations: A config declares both a group to be removed and files owned by that group; a refactored config deleted a group that is still referenced by file entries; bootstrap account requests generated from another module mark the group absent while file management still references it.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/1eb864702841e7b4. Report an issue: GitHub.