Clients

mountOS ships one client per native filesystem interface that users already know. It also ships S3 and WebHDFS surfaces for anything that uses those APIs. All filesystem clients use the same wire protocol, so the mount experience is the same on every platform. A client contacts the global HUB, served by control nodes, once for discovery. It then connects to the owning metadata 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. The same install provides every way an endpoint reaches a volume.

macOS

• FSKit is the native filesystem extension. It is the modern path on macOS 15.4 and later.
• NFS 4.1 and SMB 3 are direct clients, for workloads that already expect those protocols.
• macFUSE is the fallback for older macOS versions.

Linux

• FUSE is the libfuse3 client, the main Linux surface.
• NFS 4.1 / 4.2 is a direct client.
• Kubernetes CSI. mountos kubernetes (alias mountos csi) is the CSI node driver. It registers with Kubernetes as csi.mountos.io. It launches one mountos mount subprocess per staged volume. The driver monitors and recovers a failed or wedged mount subprocess automatically.

Windows

• mountosio is the native mountOS kernel filesystem driver. It gives full POSIX-ish semantics. It is the lowest-latency mountOS client.

S3 and WebHDFS

S3 and WebHDFS are protocol surfaces of the mountos client. Each surface binds to the one volume the client authenticates 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. Pass --gateway to mountos mount instead. It runs the mount and the protocol surfaces in the same process. A volume then serves as a filesystem and an object endpoint at once. CLI tools, SDKs, build systems, and CI jobs authenticate with the same access key and secret key pair the client already holds. They use AWS SigV4 for S3 and mountOS SigV4 for WebHDFS.

The listener binds to loopback (127.0.0.1) by default. To bind a non-loopback address, supply a TLS certificate and a key. --gateway-port accepts three forms: 0 to pick a free port per protocol, a single number for every protocol, or the per-protocol form s3=9000,hdfs=9870. Every running gateway publishes a descriptor JSON file under ~/.mountOS/gateway/. Local tooling can discover the ports it uses from that file.

mountOS provides a Java SDK for native Hadoop tooling, hadoop-mountos (package mountos-hdfs-sdk). It is a Hadoop Compatible FileSystem jar, published as io.mountos:hadoop-mountos. It registers the mountos:// URI scheme. It signs WebHDFS requests.

To use it, do the following:

• Put the jar on the classpath.
• Point fs.mountos.endpoint at the endpoint that mountos gateway --gateway hdfs publishes.
• Set the access key pair in core-site.xml.

With that setup, 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. The mountos event command reads that feed, 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. Server services carry the same feature. Each one binds to a running node's control socket. Run <service> dashboard (with --gui) for an operator view. An operator needs no external monitoring tool.

Admin SDKs

The open-source admin SDK(opens in new tab) is the connector to a deployment's HUB. It communicates with the HUB over HTTPS for account, volume, and key management. It attaches a signed JWT that it manages automatically. Integrate through one of the following:

• The TypeScript (@mountos-io/admin-sdk), Go, or Rust package.
• The REST API directly (api.md).
• A client generated in any language from the API spec (api.yaml).

The repository also ships a SKILL.md file for AI agents. End users do not need the SDK. Operators do. See Admin SDK and dashboard.

Discovery and sessions

A client discovers its volume's metadata servers at the HUB. It uses only its access key. It opens an encrypted session to the owning metadata cluster. It re-syncs the topology periodically. It reports its session details to the HUB. The dashboard's sessions view shows that report.