astrid-runtime/astrid · error

stale mount recovery belongs to another acting principal

Error message

stale mount recovery belongs to another acting principal

What it means

authorize_stale_cleanup() governs unmounting mounts whose kernel lease is no longer live. Stale recovery is only allowed by the same principal that originally requested the mount; a different acting principal is refused, preventing users from tearing down each other's stale mounts.

Source

Thrown at crates/astrid-storage-provider-fskit/src/main.rs:284

        )?;
    }
    update_registry(|registry| {
        registry.mounts.remove(&path_key(&record.mountpoint));
        Ok(())
    })?;
    cleanup_created_mountpoint(&record.mountpoint, record.auto_created_mountpoint)?;
    Ok(StorageProviderSuccessV1::Unmounted {
        mount_id: record.mount_id,
    })
}

fn authorize_stale_cleanup(
    lease_is_live: bool,
    requested_by: &astrid_core::PrincipalId,
    acting_principal: &astrid_core::PrincipalId,
) -> Result<()> {
    if !lease_is_live && requested_by != acting_principal {
        bail!("stale mount recovery belongs to another acting principal");
    }
    Ok(())
}

fn lease_from_response(body: AdminResponseBody) -> Result<StorageMountLeaseV1> {
    match body {
        AdminResponseBody::StorageMountLease(lease) => Ok(*lease),
        AdminResponseBody::Error(error) => bail!("kernel refused storage mount: {error}"),
        _ => bail!("kernel returned an unexpected storage mount response"),
    }
}

fn into_success(body: AdminResponseBody) -> Result<serde_json::Value> {
    match body {
        AdminResponseBody::Success(value) => Ok(value),
        AdminResponseBody::Error(error) => {
            bail!("kernel refused storage lifecycle request: {error}")
        },

View on GitHub (pinned to affd8760f4)

Solutions

1. Perform the stale unmount using the same PrincipalId that originally requested the mount
2. Have the original owner run the cleanup, or use an administrative mechanism intended for cross-principal recovery
3. Verify the acting principal configuration (identity file/token) matches the original requester

Example fix

// before
unmount_as(current_principal, "/mnt/share")?; // principal differs from requester
// after
unmount_as(original_requester_principal, "/mnt/share")?;

// rust
anyhow::ensure!(
    acting_principal == record.requested_by,
    "stale recovery requires the original requesting principal"
);

When it happens

Trigger: Calling unmount() for a mount whose lease is dead (lease_is_live == false) while acting_principal != requested_by on the stored MountRecord.

Common situations: An admin or service account attempts to clean up a stale mount created by another user; credential rotation changed the effective principal id between mount and cleanup; scripting cleanup across machines under a shared account with different principal ids.

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

• manifest exceeds its installed capability approval: {details
• capsule '{}' changed after authority review (approved {}, fo
• symlink {} resolves outside the capsule source root ({}); re
• directory symlink {} not allowed in capsule source tree (ref
• materialized capsule manifest exceeds durable authority appr

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