astrid-runtime/astrid · error

FUSE service status failed [{code}]: {message}

Error message

FUSE service status failed [{code}]: {message}

What it means

This error is raised by the FUSE storage provider's `sync` command (crates/astrid-storage-provider-fuse/src/main.rs:367). After confirming a live lease exists, the provider queries the running FUSE service over its control socket and receives `ControlResponse::Failure { code, message }`, meaning the detached FUSE service itself reported an operational failure when asked for its status. The provider surfaces the service's own error code and message verbatim so the caller can see why the mount is unhealthy.

Source

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

}

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)?;
    let control = live_control_status(client, acting_principal, &record).await?;
    match control {
        ControlResponse::Status { access } if access == record.access => {},
        ControlResponse::Status { access } => {
            bail!("detached FUSE service access {access:?} does not match lease")
        },
        ControlResponse::Done => bail!("FUSE service returned an incompatible status response"),
        ControlResponse::Failure { code, message } => {
            bail!("FUSE service status failed [{code}]: {message}")
        },
    }
    into_success(
        client
            .request(AdminRequestKind::StorageMountSync {
                mount_id: record.mount_id,
            })
            .await?,
    )?;
    Ok(StorageProviderSuccessV1::Synced {
        mount_id: record.mount_id,
    })
}

async fn status(
    client: &mut AdminClient,
    acting_principal: &astrid_core::PrincipalId,
    selector: &StorageMountSelectorV1,

View on GitHub (pinned to affd8760f4)

Solutions

  1. Read the embedded [code] and message to identify the FUSE service-side failure and fix the underlying daemon problem (e.g. re-authenticate backing storage).
  2. Restart the FUSE service for this mount so it re-establishes a healthy state, then retry the sync.
  3. If the daemon is unrecoverable, unmount and re-mount the storage to get a fresh lease and control socket.
  4. Verify the admin client and FUSE service versions match to rule out protocol incompatibilities.

Example fix

// before: retrying sync against a failed daemon
provider.sync(selector).await?;
// after: check status, remount on failure, then sync
match provider.status(selector).await {
    Err(e) if e.to_string().contains("FUSE service status failed") => {
    provider.unmount(selector).await?;
    provider.mount(params).await?;
    provider.sync(selector).await?;
    }
    _ => provider.sync(selector).await?,
}
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-check: only sync when the daemon reports a healthy status
let status = provider.status(&selector).await;
if matches!(&status, Err(e) if e.to_string().contains("FUSE service status failed")) {
    return Err("FUSE service unhealthy; restart daemon before sync".into());
}

Type guard

fn is_fuse_service_failure(err: &anyhow::Error) -> bool {
    err.to_string().starts_with("FUSE service status failed [")
}

Try / catch

match provider.sync(&selector).await {
    Err(e) if is_fuse_service_failure(&e) => {
        // parse code between '[' and ']' and restart the FUSE daemon
        restart_fuse_service(&mount_id).await?;
        provider.sync(&selector).await
    }
    other => other,
}

Prevention

When it happens

Trigger: Calling `sync` (StorageMountSelectorV1) while the mount has a live kernel lease and a registry record, but the detached FUSE service replies `ControlResponse::Failure` on `live_control_status` — e.g. the FUSE daemon hit an internal error serving the mount, lost its backing storage handle, or the control protocol returned an explicit failure code.

Common situations: FUSE daemon partially crashed or was restarted with a stale control socket; backing remote storage credentials expired so the daemon reports failure on status checks; version mismatch between the admin client and the running FUSE service leading the daemon to reject the status request; kernel lease still live but the daemon's mount state is corrupt.

Related errors


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