JuiceMount — for editing video straight off a NAS, built on JuiceFS

[lelanddutcher]

I've been building a project on top of JuiceFS that now public and I'd love to share here:

Repo: https://github.com/lelanddutcher/juicemount
Web: juicemount.com

JuiceMount, a macOS-native layer that turns a JuiceFS volume into a Finder volume tuned for video editing off your own NAS. It's a self-hosted, open-source alternative to LucidLink / Suite / Shade for editors, with JuiceFS doing the heavy lifting underneath.

The short version

I'm a CS grad and a creative, the footage problem every small post shop has is the same. Cloud editing storage (LucidLink, Suite, Shade, etc) streams beautifully but bills you per seat and per terabyte. A NAS over plain SMB is yours and fast on the LAN, but Finder grinds for a full minute opening a big project and there's no offline system at all. Mountian Duck is great but slow even on LAN and moves whole files rather than the sections you use.

JuiceFS is the backend I wanted but with pro features I was used to with expensive solutions.

Files become blocks (the part you'll recognize)

JuiceFS already stores every file as chunks. JuiceMount leans entirely on that. Want three seconds out of the middle of an 8 GB take? About 12 MB of blocks come over the wire, the rest never move, and whatever you scrub pages into a local SSD cache so the next pass is instant. A 100 GB R3D opens and scrubs like it's on the desktop, even over a modest cellular hotspot back to my server.

How it's built on JuiceFS

The editor-facing half is a plain Finder volume. The half that makes it fast sits between Finder and JuiceFS:

• An NFS server on 127.0.0.1, tuned for the way Finder hammers metadata. Your NLE mounts /Volumes/<name>; to macOS it's a genuine NFS volume, the same absolute path on every Mac, so a teammate's .prproj / .drp / .fcpx opens with media already online. Nobody relinks.
• A local SQLite mirror of the metadata. This is the big one. Directory opens that take 3–10 s through the raw FUSE mount complete in 15–120 ms, because Finder never crosses the wire just to list a folder.
• Reads served in priority order: memory buffer, then a direct SSD-cache read that bypasses FUSE entirely, then JuiceFS, then the object store. Only a genuine cache miss crosses the wire, and only for the blocks involved.
• An opt-in write spool. A write is acknowledged the moment it's durable on local SSD, then trickle-uploads to the NAS in the background, SHA-256-verified at every hop, with crash recovery so an interrupted upload re-sends instead of vanishing.
• Pinning and offline. Pin a folder and a prefetcher pulls every byte local with progress. Offline mode serves pinned files at SSD speed and refuses un-pinned reads in milliseconds instead of beachballing Finder on a 30 s NFS timeout. It can even boot fully offline and serve your last-known library.

Underneath all of it, JuiceFS does what it's great at: chunked object layout in MinIO (or any S3-compatible store) with metadata in Redis. The FUSE mount JuiceFS needs lives at a hidden dotfile path the NLE never browses.

Why an NFS loopback instead of FUSE-direct or a File Provider extension

so: Finder metadata performance. Finder hammers metadata harder than anything else, and answering it from a local SQLite mirror behind a Finder-tuned NFS server is what takes a folder open from 3–10 s down to 15–120 ms. The JuiceFS FUSE mount is still there underneath but Resolve or Premiere Pro never touch it.

What	Measured
Cached read through the full NFS path (dd, 200 MiB)	226–571 MB/s, READ p95 481 µs
Fully-cached 200 MiB sequential read	431 MB/s with 4.6 MB total network traffic
Pinned 350 MB read, network off	215+ MB/s sustained
Directory open, 100k+-entry volume	15–120 ms (3–10 s through raw FUSE)
Filename search across ~131k entries	~29 ms
Un-pinned read refusal, offline mode	4–67 ms (vs. a 30 s NFS retry hang)

Credit to the JuiceFS team

JuiceMount exists because JuiceFS solved the hard distributed-filesystem problems (chunked object layout, the Redis metadata engine, cache management) and proved them in production for years. JuiceMount is the macOS experience layer on top: the Finder-tuned NFS re-export, the SQLite metadata cache, pinning and offline gates, the write spool, the menu-bar app, and the server packaging. It drives the stock juicefs binary rather than bundling or forking it. Thank you to the Juicedata team and community: this would not exist without your work.

It's Apache-2.0, self-hosted, currently beta and pre-1.0. Repo: https://github.com/lelanddutcher/juicemount

[jfmatth]

Wow, what a great project, thanks for sharing.

I've used JuiceFS for 'unlimited' NFS in my K8s cluster and it is SOOO fast, using the same ideas that you have (pull out blocks in middle).

Congrats on this project, maybe i'll check it out.

[lelanddutcher]

Yeah that's awesome.

I think a distributed version is on the horizon one day so i can solve on prem + cloud or rather "pseudo tiered" "hybrid cloud" where the things you want lighting fast access to can live in a small provisioned S3 bucket for resiliency and remote use case without you having to manually pick what that data is.