detached FUSE service readiness access {access:?} does not m

Error message

detached FUSE service readiness access {access:?} does not match its lease

What it means

This error means the detached FUSE service answered a readiness probe with a `ControlResponse::Status` whose `access` does not equal the `StorageProviderAccessV1` from the lease being served. The library requires the live service to report exactly the access configuration the lease prescribed; any mismatch means the mount could enforce the wrong permissions. It is thrown from the readiness validation helper in main.rs:340.

Source

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

        mountpoint::lazy_unmount(&launch.mountpoint),
        || {
            cleanup_service_artifacts(
                control_path,
                &launch.mountpoint,
                launch.auto_created_mountpoint,
            )
        },
    )
}

fn require_ready_control_response(
    response: ControlResponse,
    expected_access: StorageProviderAccessV1,
) -> Result<()> {
    match response {
        ControlResponse::Status { access } if access == expected_access => Ok(()),
        ControlResponse::Status { access } => {
            bail!("detached FUSE service readiness access {access:?} does not match its lease")
        },
        ControlResponse::Failure { code, message } => {
            bail!("detached FUSE service readiness failed [{code}]: {message}")
        },
        ControlResponse::Done => {
            bail!("detached FUSE service returned an incompatible readiness response")
        },
    }
}

async fn sync(
    client: &mut AdminClient,
    acting_principal: &astrid_core::PrincipalId,
    selector: &StorageMountSelectorV1,
) -> Result<StorageProviderSuccessV1> {
    let record = registry::resolve_record(selector)?;
    let status = require_live_lease(client, acting_principal, &record).await?;
    validate_record(&record, &status)?;

View on GitHub (pinned to affd8760f4)

Solutions

Stop the stale detached service (cleanup_service_artifacts) and start a fresh one from the current lease.
Compare the lease's access fields with what the service was started with and correct the mismatch.
Delete leftover control sockets/mountpoints from previous runs so an old service cannot answer readiness probes.
Verify no serde representation drift (same crate version on both sides) makes equal accesses compare unequal.

Example fix

// before
let svc = reuse_existing_service(&sock)?;
validate_readiness(status, &lease.access)?;
// after
cleanup_service_artifacts(&sock, &mp)?;
let svc = start_detached_service(&lease)?;
validate_readiness(status, &lease.access)?;

Defensive patterns

Strategy: try-catch

Type guard

fn matches_lease(status: &ControlResponse, access: &StorageProviderAccessV1) -> bool {
    matches!(status, ControlResponse::Status { access: a } if a == access)
}

Try / catch

match validate_readiness(resp, &lease.access) {
    Err(e) if e.to_string().contains("does not match its lease") => {
        cleanup_service_artifacts(&sock, &mp)?;
        // restart service from current lease
    }
    r => r?,
}

Prevention

Clean up stale control sockets and services before starting a new mount
Start the service from the same lease object you validate against
Keep serde structs identical across client and service versions

When it happens

Trigger: Calling the readiness check with a `ControlResponse::Status` whose embedded access differs from `expected_access` — e.g. read-only vs read-write, different owner, or different lease token.

Common situations: A stale service from a previous mount still holding the control socket; the service was started with different access parameters than the current lease; lease/access structs differing by field ordering or an updated type after a version change.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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