What a real mount means for editors, and why it matters

A real mount is storage that shows up in Finder as a volume, with its own icon in the sidebar, a path your software can point at, and behavior that follows the rules every editing app already expects. That is the whole idea, and it is the difference between storage you can edit off and storage you have to fight. An app folder is not a mount. A sync folder is not a mount. Both can hold your footage, but only a real volume lets Premiere, Resolve, and Pro Tools treat remote storage the way they treat the SSD bolted to your desk.

What "mount" actually means #

Mounting is an old, boring, load-bearing idea. To mount a filesystem is to attach it to a directory in the operating system's tree so its contents become reachable as if they were always there (the standard definition, per the Mount (computing) article, checked Jun 2026). On a Mac that attachment point surfaces as a volume in Finder: /Volumes/Footage, an icon in the sidebar, a thing you can right-click and Get Info on. Windows calls the same idea a drive letter. The point of a mount is that the file path is stable and the access rules are the operating system's, not some application's.

Here is the analogy I keep coming back to. A real mount is a power outlet in the wall: every appliance you own already knows how to use it, because the outlet honors a standard. An app that holds your files is more like a wall socket that only the manufacturer's blender can plug into. The blender works great. Everything else needs an adapter, or will not fit. Editing software is a house full of appliances built decades before any given cloud vendor existed, and they all expect the outlet.

That standard has a name on macOS now. As of macOS 15.4 Apple shipped FSKit, a framework that lets a filesystem run entirely in user space, and macFUSE 5.1.0 (released October 30, 2025) added an FSKit backend that mounts volumes without a kernel extension and without rebooting into Recovery Mode (checked Jun 2026). The plumbing matters less than the result: a mount can now present as a genuine Finder volume through supported, future-proof Apple APIs rather than a fragile kext.

An app is not a volume #

Plenty of storage products give you a great app and call it done. You browse footage in their window, you tag it, you hand off review links, and it is genuinely useful. The trouble starts the moment a non-native application needs the bytes. Your NLE wants to point a scratch disk at a path. Your color app wants to conform from original media on disk. Your DAW wants to stream session audio with the timing it expects. None of those tools open the storage vendor's app and ask politely. They open a file path, and if there is no path, there is no media.

Apple's own File Provider change in 2022 made this concrete. Dropbox, Box, and Google Drive moved their content under ~/Library/CloudStorage as folders on your internal disk rather than separate volumes, which means, as TidBITS documented, you can no longer keep those offline copies on an external drive the way you used to (checked Jun 2026; OneDrive worked around it, the others did not). For an editor with terabytes of cache, that is not a detail. It is the difference between a workable rig and a boot drive that fills up by lunch.

A sync folder is not a mount either #

Sync is the more seductive impostor, because a synced folder really is a folder with a real path. Finder shows it, your NLE can point at it, and for a while everything is fine. The catch is what sync does underneath: it moves whole files, and it moves them on its own schedule. Open an online-only file and it downloads in full before you can touch it. Dropbox says exactly that on its own help page: an online-only file automatically downloads when you open it (checked Jun 2026). For a 4 KB document that is invisible. For a 120 GB camera-original clip you wanted to scrub for three seconds, it is a coffee break.

The other half of the problem is conflict. Sync tools are bidirectional by design, and when two people touch the same file the resolution is a copy, not a merge. Nextcloud renames the loser to a "...conflict..." file (Resilio does the same, checked Jun 2026), and Syncthing needs both devices online at once to reconcile at all. An editing project is full of files multiple tools open simultaneously: project databases, render caches, lock files. A conflict copy in the middle of that is not a nuisance, it is a corrupted timeline. A real mount sidesteps the entire category because there is one authoritative copy on the server and the volume reads and writes against it directly, the way a NAS share always has.

Why a mount can stream a block instead of the whole file #

The reason a real mount can do something sync cannot is that it operates at the filesystem level, where reads and writes are addressed by offset. When Resolve asks for three seconds of footage, it asks for a byte range, not a file. A mount that streams can serve exactly those blocks and leave the other 119.99 GB on the server. This is the architecture behind every serious streaming product in the category: LucidLink, by its own description, does byte-range streaming from objects on an as-needed basis with local write-back caching and prefetch (checked Jun 2026).

The open-source plumbing works the same way. JuiceFS, the filesystem JuiceMount is built on, mounts via FUSE and splits files into logical chunks of up to 64 MiB, persisted to object storage as blocks of up to 4 MiB by default, with a metadata engine that maps files to chunks to slices to blocks (JuiceFS cache docs, checked Jun 2026). A scrub touches a handful of those 4 MiB blocks. A whole-file sync tool has no concept of "a handful of blocks"; the file is the unit, so the file is what moves. That single architectural fact is why a mount feels like local storage and a sync folder feels like a download queue. I wrote the long version of this in block-level streaming vs whole-file sync, and the protocol-latency side of it in why your NAS feels slow over a VPN.

What this buys an editor, concretely #

Strip away the architecture and here is what a real mount means at the desk. Your scratch disk and media cache can point at it, because Adobe and Blackmagic both let you set those to any volume with a path. Your project lives at a stable location that does not move when a sync client decides to reorganize. Two editors can open the same shared project off one authoritative copy without spawning conflict files. And a local cache plus a local index means the second time you open a bin or search a library, the answer comes off your own SSD instead of crossing the wire again.

The honest limits are worth stating plainly, because a mount is not magic. Every byte that has not been cached yet still arrives at the speed of the link behind it, so the first scrub of fresh media pays the wire in full just like a share does; a mount wins on the revisits, the listings, and the searches, not on first touch. A mount also does not give you the polished asset browser, AI tagging, and review-and-approve workflow that a managed app like iconik or Shade sells, because those live a layer above the filesystem. If what you need is a media-asset-management front end, a mount is the wrong tool and I would not pretend otherwise. If what you need is for your editing software to treat remote storage like a drive, a real mount is the only shape that does it.

This is where JuiceMount fits and, honestly, where it does not. It exists to make a self-hosted NAS mount as a real Finder volume with a local SSD cache and a local search index, for zero per-seat cost, and that is the entire pitch. It is not a review platform, it does not tag your footage with AI, and it will not replace a SaaS suite for a team that wants those things. It replaces the part where remote storage should just behave like a drive.