JuiceFS --subdir is a client-side chroot: an untrusted client picks its own root
In JuiceFS Community Edition every check runs in the client, so we put a trusted server in front.
Our mount hosts ran AI agent code we did not write, so we checked whether JuiceFS Community Edition could isolate tenants. This describes JuiceFS CE and its CSI driver as of July 2026.
The short answer
--subdiris a client-side chroot. A JuiceFS CE mount needs the metadata URL, and metadata access implies the object storage credentials for the whole filesystem. Quotas and POSIX ACLs are also client library code.- The CSI driver shares one mount pod between PVs that differ only by
subPath, so one whole-filesystem credential serves many tenants. - We put a trusted server in front. Agents spoke mTLS to it with certificates valid for 1 hour. It held the only JuiceFS mount and confined each connection to that agent's path prefix. We retired it on 2026-09-06.
Options for untrusted clients
| Option | What it offers | Why it did not fit |
|---|---|---|
| One filesystem per agent | Per-tenant isolation | One metadata engine and mount pod each; an 8-vCPU node fits about 7 default mount pods |
| S3 Gateway IAM (v1.2+) | Server-side IAM | Agents need rename, append, mmap and locks |
| Enterprise Edition access tokens | Subdirectory restrictions, reported | We have not operated it |
When the answer changes
- Trusted mount hosts: if you control every mount host, the CE design is coherent for its trust model.
- Cost of our design: a custom FUSE client and a server hop on every file operation.
- Limits of this post: the Enterprise Edition comparison comes from Juicedata's published materials. We make no security-guarantee claims. The gateway is retired, and agents now run in Firecracker microVMs.
The full post has the certificate design and the notes from running it.