What causes "unsupported storage filesystem protocol" in astrid-runtime/astrid?

Rebuild/reinstall the storage provider and kernel from the same version so both speak STORAGE_FILESYSTEM_PROTOCOL_V1

unsupported storage filesystem protocol

Error message

unsupported storage filesystem protocol

What it means

The kernel's storage-mount callback handshake reads a request from the mount provider and checks that it advertises STORAGE_FILESYSTEM_PROTOCOL_V1. Any request framed with a different (or unrecognized) protocol version byte is rejected as InvalidData with this message. It exists so the kernel never misparses frames from an incompatible provider build.

Source

Thrown at crates/astrid-kernel/src/storage_mount.rs:607

        let operation = decode_operation_v2(request.operation)?;
        Ok(Some(CallbackRequest {
            request: StorageFilesystemRequestV1 {
                protocol_version: STORAGE_FILESYSTEM_PROTOCOL_V1,
                request_id: request.request_id,
                lease_token: request.lease_token,
                operation,
            },
            response_version: STORAGE_FILESYSTEM_PROTOCOL_V2,
        }))
    } else if protocol == STORAGE_FILESYSTEM_PROTOCOL_V1 {
        let request = serde_json::from_slice::<StorageFilesystemRequestV1>(&bytes)
            .map_err(io::Error::other)?;
        Ok(Some(CallbackRequest {
            request,
            response_version: STORAGE_FILESYSTEM_PROTOCOL_V1,
        }))
    } else {
        Err(io::Error::new(
            io::ErrorKind::InvalidData,
            "unsupported storage filesystem protocol",
        ))
    }
}

fn decode_operation_v2(
    operation: StorageFilesystemOperationV2,
) -> io::Result<StorageFilesystemOperationV1> {
    Ok(match operation {
        StorageFilesystemOperationV2::VolumeInfo => StorageFilesystemOperationV1::VolumeInfo,
        StorageFilesystemOperationV2::Stat { path } => StorageFilesystemOperationV1::Stat { path },
        StorageFilesystemOperationV2::ReadDirectory { path } => {
            StorageFilesystemOperationV1::ReadDirectory { path }
        },
        StorageFilesystemOperationV2::Read {
            path,
            offset,

View on GitHub (pinned to affd8760f4)

Solutions

Rebuild/reinstall the storage provider and kernel from the same version so both speak STORAGE_FILESYSTEM_PROTOCOL_V1
Check the provider's protocol constant and align it with STORAGE_FILESYSTEM_PROTOCOL_V1 in the kernel
Inspect the bytes the provider writes on connect and fix the client's framing/version field
If you intentionally added a protocol version, add explicit support for it in read_request instead of falling through to the else branch

Example fix

// before (provider)
stream.write_all(&[0x02, version_byte]).await?;
// after
stream.write_all(&STORAGE_FILESYSTEM_PROTOCOL_V1).await?;

Defensive patterns

Strategy: validation

Validate before calling

fn is_supported_protocol(version: &[u8]) -> bool {
    version == STORAGE_FILESYSTEM_PROTOCOL_V1
}
// call before sending/accepting a callback request
assert!(is_supported_protocol(&handshake_bytes), "provider must speak STORAGE_FILESYSTEM_PROTOCOL_V1");

Type guard

fn as_supported_version(v: u8) -> Option<u8> {
    (v == STORAGE_FILESYSTEM_PROTOCOL_V1[0]).then_some(v)
}

Try / catch

match kernel.connect_mount(provider) {
    Ok(mount) => mount,
    Err(e) if e.to_string().contains("unsupported storage filesystem protocol") => {
        eprintln!("provider/kernel version mismatch: rebuild both from the same release");
        std::process::exit(1);
    }
    Err(e) => return Err(e.into()),
}

Prevention

Pin kernel and storage-provider to the same release version
Add a startup version handshake check on the provider side too
Log the advertised protocol version on both ends at connection time

When it happens

Trigger: A storage provider (e.g. an old or third-party FUSE provider) connects to the kernel's callback socket but writes a handshake whose protocol version is not STORAGE_FILESYSTEM_PROTOCOL_V1; read_request, called from handle_connection, fails immediately before any operation is decoded.

Common situations: Version skew: kernel and storage-provider binaries built from different commits; a hand-rolled client poking the callback socket; a provider upgraded to a newer protocol the kernel does not know.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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