jdx/mise · error

bootstrap resource '{resource}' requires owner '{owner}', bu

Error message

bootstrap resource '{resource}' requires owner '{owner}', but that user is absent

What it means

While wiring account dependencies for bootstrap resources, the planner checks the computed state of the owner user. If the owner account is explicitly managed as Absent, the resource cannot be created with that owner, so planning fails with this message instead of producing a plan that would apply unsuccessfully at runtime.

Source

Thrown at src/system/resources.rs:640

fn add_account_dependencies(
    plan: &mut BootstrapPlan,
    resource: &ResourceId,
    state: super::managed_files::ManagedState,
    owner: Option<&str>,
    group: Option<&str>,
    user_states: &HashMap<String, super::accounts::AccountState>,
    group_states: &HashMap<String, super::accounts::AccountState>,
) -> Result<()> {
    if state != super::managed_files::ManagedState::Present {
        return Ok(());
    }
    if let Some(owner) = owner {
        match user_states.get(owner) {
            Some(super::accounts::AccountState::Present) => {
                plan.add_dependency(resource, ResourceId::new("user", owner))?;
            }
            Some(super::accounts::AccountState::Absent) => bail!(
                "bootstrap resource '{resource}' requires owner '{owner}', but that user is absent"
            ),
            None => {}
        }
    }
    if let Some(group) = group {
        match group_states.get(group) {
            Some(super::accounts::AccountState::Present) => {
                plan.add_dependency(resource, ResourceId::new("group", group))?;
            }
            Some(super::accounts::AccountState::Absent) => bail!(
                "bootstrap resource '{resource}' requires group '{group}', but that group is absent"
            ),
            None => {}
        }
    }
    Ok(())
}

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Change the owner to an existing/present user, or update the user resource state to Present.
  2. Remove the user-removal declaration if the account should actually exist.
  3. If the whole stack is being torn down, also mark the dependent resources absent so no owner is required.
  4. Fix the owner string if it is a typo for a user that is present.

Example fix

// before
user("deploy", AccountState::Absent);
resource("/srv/app", owner: "deploy");
// after
user("deploy", AccountState::Present);
resource("/srv/app", owner: "deploy");
Defensive patterns

Strategy: validation

Validate before calling

fn owner_ok(owner: &str, user_states: &std::collections::HashMap<String, bool>) -> Result<(), String> {
    match user_states.get(owner) {
        Some(true) => Ok(()),
        Some(false) => Err(format!("owner '{owner}' is declared absent")),
        None => Err(format!("owner '{owner}' is not declared at all")),
    }
}

Prevention

When it happens

Trigger: Calling plan (via add_account_dependencies) for a bootstrap resource whose owner field names a user whose AccountState in user_states is Absent — i.e. a user resource in the same plan declares that account as absent.

Common situations: Setting owner: deploy on a file/service resource while another section removes the 'deploy' user; renaming an account in one place but not the other; inheriting shared config that deletes service accounts still referenced by file owners.

Understand the failure class

Background: "not installed", "pip install", "required for": how missing-dependency errors surface across open-source libraries — this error's family across 34 libraries.

Related errors


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