astrid-runtime/astrid · error

mount was issued to another acting principal

Error message

mount was issued to another acting principal

What it means

Raised by the `unmount` command (crates/astrid-storage-provider-fuse/src/main.rs:416). The registry record for the selected mount stores the `requested_by` principal that originally issued the mount; if the acting principal performing the unmount differs from that owner, the provider refuses. This is a single-owner guard preventing one principal from tearing down another principal's mount.

Source

Thrown at crates/astrid-storage-provider-fuse/src/main.rs:416

            bail!("FUSE service status failed [{code}]: {message}")
        },
    }
    Ok(StorageProviderSuccessV1::Status {
        mount_id: record.mount_id,
        mountpoint: record.mountpoint,
        access: record.access,
        dirty: lease_status.dirty,
    })
}

async fn unmount(
    client: &mut AdminClient,
    acting_principal: &astrid_core::PrincipalId,
    selector: &StorageMountSelectorV1,
) -> Result<StorageProviderSuccessV1> {
    let record = registry::resolve_record(selector)?;
    if &record.requested_by != acting_principal {
        bail!("mount was issued to another acting principal");
    }
    let live = if let Some(status) = kernel_lease_status(client, &record.mount_id).await? {
        if status.mountpoint != record.mountpoint || status.access != record.access {
            bail!("kernel lease metadata does not match the FUSE provider registry");
        }
        true
    } else {
        cleanup_stale_record(client, acting_principal, &record).await?;
        false
    };
    if live {
        let control_result = control_unmount(&record.control_path, acting_principal);
        if let Err(error) = control_result {
            eprintln!(
                "falling back to stale FUSE cleanup after control unmount failure: {error:#}"
            );
            cleanup_stale_record(client, acting_principal, &record).await?;
        } else {

View on GitHub (pinned to affd8760f4)

Solutions

1. Run the unmount under the same principal that originally issued the mount (check `record.requested_by`).
2. If ownership must transfer, have the original owner unmount, then re-mount under the new principal.
3. If the original principal is gone, remove the stale registry record via the cleanup path (stale-record cleanup) and re-create the mount under the current principal.
4. Verify the CLI's authenticated identity/credentials match the expected owner before retrying.

Example fix

// before: unmounting with the wrong principal
let p = PrincipalId::from("svc-backup");
provider.unmount(&p, &selector).await?; // panics with 'issued to another acting principal'
// after: use the owning principal
let owner = registry_record(&selector)?.requested_by;
provider.unmount(&owner, &selector).await?;

// verify ownership before attempting unmount
let record = registry::resolve_record(&selector)?;
if &record.requested_by != &acting_principal {
    return Err(format!(
        "mount {} owned by {:?}; current principal {:?} cannot unmount",
        record.mount_id, record.requested_by, acting_principal
    ).into());
}

fn is_mount_owner(record: &MountRecord, principal: &astrid_core::PrincipalId) -> bool {
    &record.requested_by == principal
}

match provider.unmount(&principal, &selector).await {
    Err(e) if e.to_string().contains("issued to another acting principal") => {
        // fall back to the recorded owner
        let owner = registry::resolve_record(&selector)?.requested_by;
        provider.unmount(&owner, &selector).await
    }
    other => other,
}

When it happens

Trigger: Calling `unmount` with a StorageMountSelectorV1 whose resolved record has `record.requested_by != acting_principal` — i.e. a different admin principal identity than the one that created the mount.

Common situations: Team environments where a second operator tries to unmount a colleague's mount; running the CLI under a different account/service identity than the one that mounted; automation credentials rotated so the new principal no longer matches the recorded owner; copied registry records retaining the original owner.

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

• mountpoint must be owned by the current OS user: {}
• mountpoint ancestor is writable without sticky protection: {
• FUSE mount completed but is absent from the Linux mount tabl
• FUSE service status failed [{code}]: {message}
• detached FUSE service failed: {message}

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