astrid-runtime/astrid · error

read FUSE volume metadata: {error:?}

Error message

read FUSE volume metadata: {error:?}

What it means

start_session reads VolumeInfo via the FUSE filesystem callback before mounting; if that metadata read fails the session cannot be configured, and the underlying error is wrapped with this context. It indicates the FUSE callback layer failed to supply volume metadata (name, owner, capacity).

Source

Thrown at crates/astrid-storage-provider-fuse/src/filesystem.rs:43

use volume_info::VolumeInfo;

// Astrid is the authority and may be changed through another principal view or
// native client. Do not let the kernel serve stale lengths or bytes from an
// earlier callback result.
const ATTRIBUTE_TTL: Duration = Duration::ZERO;

/// Start a real kernel FUSE session for one admitted lease.
pub(crate) type FuseBackgroundSession = fuser::BackgroundSession;

/// Mount the filesystem and return the owner-owned background session.
pub(crate) fn start_session(
    lease: StorageMountLeaseV1,
    mountpoint: &Path,
) -> Result<FuseBackgroundSession> {
    let access = lease.access;
    let filesystem = AstridFuseFilesystem::new(lease);
    let info = VolumeInfo::read(&filesystem.callback)
        .map_err(|error| anyhow::anyhow!("read FUSE volume metadata: {error:?}"))?;
    let mount_option = match access {
        StorageProviderAccessV1::ReadOnly => MountOption::RO,
        StorageProviderAccessV1::ReadWrite => MountOption::RW,
    };
    let mut config = Config::default();
    config.mount_options = vec![
        MountOption::FSName(info.volume_name),
        MountOption::Subtype("astrid".to_owned()),
        mount_option,
        MountOption::DefaultPermissions,
        MountOption::NoDev,
        MountOption::NoSuid,
        MountOption::NoExec,
    ];
    config.acl = SessionACL::Owner;
    config.n_threads = Some(1);
    config.clone_fd = false;
    let session = Session::new(filesystem, mountpoint, &config)

View on GitHub (pinned to affd8760f4)

Solutions

  1. Inspect the wrapped {error:?} detail to find the underlying VolumeInfo::read failure.
  2. Verify the fuser crate version matches the one the filesystem callback was written against.
  3. Check that StorageMountLeaseV1 carries the fields the metadata callback requires (mount id, access mode, principal).

Example fix

// before
let info = VolumeInfo::read(&filesystem.callback)?;
// after
let info = VolumeInfo::read(&filesystem.callback)
    .map_err(|e| anyhow::anyhow!("read FUSE volume metadata: {e:?}"))?;
Defensive patterns

Strategy: try-catch

Validate before calling

// preflight: ensure the lease carries the fields the metadata callback needs
assert!(!lease.mount_id.is_empty(), "lease must have a mount id");

Try / catch

match start_session(lease, &mountpoint).await {
    Ok(session) => run(session).await,
    Err(e) => {
        // {error:?} includes the underlying VolumeInfo::read cause
        eprintln!("FUSE session failed: {e:#}");
        cleanup_partial_mount(&mountpoint);
    }
}

Prevention

When it happens

Trigger: Calling start_session (from linux_native_fuse_mount_supports_all_required_operations) where VolumeInfo::read(&filesystem.callback) returns Err — e.g. the callback's metadata implementation fails or panics internally.

Common situations: Bugs or version mismatches in the fuser VolumeInfo plumbing; a lease missing fields the callback needs to synthesize metadata; running an unsupported fuser version on the test host.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


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