Clients

mountOS ships one client per native filesystem interface users already know, plus S3 and WebHDFS surfaces for anything that speaks those APIs. All filesystem clients talk the same wire protocol, so the experience of a mount is the same on every platform. A client hits the global HUB (appserv) once for discovery, then pins to the owning region cluster for the session.

The client binary on every platform is mountos. One binary implements the OS filesystem backends, the S3 and WebHDFS protocol surfaces, and the Kubernetes CSI node driver, so every way an endpoint reaches a volume comes from the same install.

macOS

• FSKit. Native filesystem extension, the modern path on macOS 15.4 and up.
• NFS 4.1 and SMB 3. Direct clients, for workloads that already expect those protocols.
• macFUSE. Fallback for older macOS versions.

Linux

• FUSE. The libfuse3 client, the main Linux surface.
• NFS 4.1 / 4.2. A direct client.
• Kubernetes CSI. mountos kubernetes (alias mountos csi) is the CSI node driver, registered as csi.mountos.io. It launches one mountos mount subprocess per staged volume, so a wedged mount is stopped, recovered by pid, or hot upgraded on its own.

Windows

• mountosio. The native mountOS kernel filesystem driver, full POSIX-ish semantics, the lowest-latency surface.

S3 and WebHDFS

S3 and WebHDFS are protocol surfaces of the mountos client, bound to the one volume the client is authenticated for. There is no multi-tenant gateway fleet to deploy.

mountos gateway --gateway s3,hdfs -a <access-key-id> -s

mountos gateway serves the volume with no filesystem mount. Passing --gateway to mountos mount instead runs the mount and the protocol surfaces from the same process, so a volume is a filesystem and an object endpoint at once. CLI tools, SDKs, build systems, and CI jobs authenticate with the same access-key / secret-key pair the client already holds, AWS SigV4 for S3 and mountOS SigV4 for WebHDFS.

The listener binds loopback (127.0.0.1) by default, and binding a non-loopback address requires a TLS certificate and key. --gateway-port accepts 0 to pick a free port per protocol, a single number applied to every protocol, or the per-protocol form s3=9000,hdfs=9870. Every running gateway publishes a descriptor JSON under ~/.mountOS/gateway/, so local tooling can discover the ports it landed on.

For native Hadoop tooling there is a Java SDK, hadoop-mountos (the mountos-hdfs-sdk), a Hadoop Compatible FileSystem jar published as io.mountos:hadoop-mountos that registers the mountos:// URI scheme and signs WebHDFS requests. With the jar on the classpath, fs.mountos.endpoint pointed at the endpoint mountos gateway --gateway hdfs publishes, and the access-key pair set in core-site.xml, distcp, Spark, Hive, and Trino read and write mountOS through their usual paths.

Change events

Every general volume can keep an ordered feed of its changes, and the mountos event command reads it, as a stream on stdout or as a local REST API. Indexers, sync tools, and AI agents follow a volume without walking the tree. See Change events.

Live dashboard

Every mount ships a built-in dashboard. mountOS Dashboard <mount-path> opens a live terminal UI for that mount, with throughput, cache, open files, and session detail. Pass --gui for the same view in a local browser instead. The server services carry the same affordance, bound to a running node's control socket: <service> dashboard (with --gui) for an operator view, no external monitoring required.

Admin SDKs

The open-source admin SDK(opens in new tab) is the connector to a deployment's HUB. It talks to the HUB over HTTPS for account, volume, and key management, attaching a signed JWT it manages automatically. Integrate through the TypeScript (@mountos-io/admin-sdk), Go, or Rust package, call the REST API directly (api.md), or generate a client in any language from the API spec (api.yaml). The repo also ships a drop-in agent SKILL.md. End users do not need it. Operators do. See Admin SDK and dashboard.

Discovery and sessions

A client discovers its volume's metadata servers at the HUB with nothing but its access key. It opens an encrypted session to the owning cluster, re-syncs the topology periodically, and reports its session details to the HUB. That report is what the dashboard's sessions view shows.