astrid-runtime/astrid · error

kernel refused storage mount: {error}

Error message

kernel refused storage mount: {error}

What it means

After sending StorageMountIssue to the admin service, lease_from_response() expects an AdminResponseBody::StorageMountLease. If the kernel answers with AdminResponseBody::Error, the mount request was refused and the kernel's error is re-raised with this message; any other body variant is a separate unexpected-response error.

Source

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

                .await?,
        )?;
    }
    update_registry(|registry| {
        registry.mounts.remove(&path_key(&record.mountpoint)?);
        Ok(())
    })?;
    if record.auto_created_mountpoint {
        let _ = std::fs::remove_dir(&record.mountpoint);
    }
    Ok(StorageProviderSuccessV1::Unmounted {
        mount_id: record.mount_id,
    })
}

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}")
        },
        _ => bail!("kernel returned an unexpected storage lifecycle response"),
    }
}

fn unmount_status(body: AdminResponseBody) -> Result<bool> {
    match body {
        AdminResponseBody::Success(_) => Ok(true),
        AdminResponseBody::Error(error)

View on GitHub (pinned to affd8760f4)

Solutions

  1. Inspect the {error} detail embedded in the message — it carries the kernel's actual refusal reason.
  2. Verify the view exists and the acting principal holds the access rights in StorageProviderAccessV1.
  3. Check kernel-side mount quotas/policy limits and free capacity if exhausted.
  4. Re-authenticate / refresh credentials if the error indicates an authorization failure, then retry the mount.

Example fix

// before: mount failure aborts launch with raw kernel error
let lease = lease_from_response(client.request(AdminRequestKind::StorageMountIssue { .. }).await?)?;
// after: surface the kernel error and fall back
let lease = match lease_from_response(body) {
    Ok(l) => l,
    Err(e) => {
        log::error!("kernel refused mount: {e}");
        return Err(anyhow!("cannot mount view: {e}; check principal access and quota"));
    },
};
Defensive patterns

Strategy: try-catch

Validate before calling

// Before issuing the mount, check the view is reachable and access is valid via an admin status call where available.

Type guard

// Rust
fn lease_of(body: &AdminResponseBody) -> Option<&StorageMountLeaseV1> {
    match body {
        AdminResponseBody::StorageMountLease(l) => Some(l),
        _ => None,
    }
}

Try / catch

// Caller
match mount(client, view, access, requested).await {
    Err(e) if e.to_string().starts_with("kernel refused storage mount") => {
        // parse the kernel error detail; fix access/quota and retry
    }
    other => other?,
}

Prevention

When it happens

Trigger: mount() calls lease_from_response() on the StorageMountIssue reply and the kernel returned AdminResponseBody::Error — e.g. the view/access is invalid, the principal lacks mount permission, capacity/quota is exhausted, or the lease cannot be granted.

Common situations: Requesting a mount for a view that no longer exists or the principal cannot access; kernel-side quota or policy refusing new mounts; admin service degraded and replying with generic kernel errors; stale access credentials embedded in StorageProviderAccessV1.

Related errors

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