astrid-runtime/astrid · error

mount was issued to another acting principal

Error message

mount was issued to another acting principal

What it means

unmount() resolves the mount record for the selector and compares its requested_by principal against the acting principal. Only the principal that originally requested the mount may unmount it; any other caller is rejected.

Source

Thrown at crates/astrid-storage-provider-winfsp/src/main.rs:272

) {
    let _ = client
        .request(AdminRequestKind::StorageMountRevoke {
            mount_id: lease.mount_id,
        })
        .await;
    if auto_created {
        let _ = std::fs::remove_dir(mountpoint);
    }
}

async fn unmount(
    client: &mut AdminClient,
    acting_principal: &PrincipalId,
    selector: &StorageMountSelectorV1,
) -> Result<StorageProviderSuccessV1> {
    let record = resolve_record(selector)?;
    if &record.requested_by != acting_principal {
        bail!("mount was issued to another acting principal");
    }
    let lease_is_live = unmount_status(
        client
            .request(AdminRequestKind::StorageMountStatus {
                mount_id: record.mount_id,
            })
            .await?,
    )?;
    native_unmount(&record.control_path).await?;
    if lease_is_live {
        into_success(
            client
                .request(AdminRequestKind::StorageMountRevoke {
                    mount_id: record.mount_id,
                })
                .await?,
        )?;
    }

View on GitHub (pinned to affd8760f4)

Solutions

1. Re-run the unmount as the same principal recorded in the mount record's requested_by field.
2. Have the owning principal unmount, or re-issue the mount under the intended principal.
3. Check which principal created the mount (via mount status/admin API) before attempting teardown.
4. Fix scripts/tests that hardcode a different principal than the mounting one.

Example fix

// before: teardown under the wrong principal
unmount(client, &other_principal, &selector).await?;
// after: use the recorded owner
let record = resolve_record(&selector)?;
unmount(client, &record.requested_by, &selector).await?;

// Before unmounting, confirm ownership:
let record = resolve_record(&selector)?;
if &record.requested_by != acting_principal {
    return Err(anyhow!("only {} may unmount this mount", record.requested_by));
}

// Rust
fn can_unmount(record: &MountRecord, principal: &PrincipalId) -> bool {
    &record.requested_by == principal
}

// Caller
match unmount(client, principal, &selector).await {
    Err(e) if e.to_string().contains("issued to another acting principal") => {
        // switch to the owning principal or ask the owner to unmount
    }
    other => other?,
}

When it happens

Trigger: Calling execute(unmount) with an acting_principal that differs from the requested_by recorded on the resolved StorageMountSelectorV1 record — e.g. an admin or another service account attempting to tear down a mount owned by a different user.

Common situations: Running the unmount under a different service account or user than the one that mounted; credential/identity changes between mount and unmount (re-login, switched principal IDs); scripts assuming any local admin can unmount.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

• stale mount recovery belongs to another acting principal
• mountpoint is already registered: {}
• mountpoint was concurrently registered: {}
• kernel refused storage mount: {error}
• kernel refused storage unmount authorization: {error}

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/40feaf57d0ff18cd. Report an issue: GitHub.