Self-hosted sync (Resilio, Syncthing, Nextcloud) vs a real mount

If you already run Resilio, Syncthing, or Nextcloud on your NAS, the temptation is obvious: you are paying nothing per seat, the box is in the closet, so why pay LucidLink $27 per member per month (checked June 2026) for what looks like the same thing? The honest answer is that sync and streaming solve different problems. A sync tool copies whole files to every machine and keeps them matched. A streaming mount fetches only the bytes an app actually reads, on demand, with nothing duplicated. For documents and finished deliverables, sync is great and free. For a 4-person team scrubbing 200 GB of multicam off the same NAS, the sync model breaks in specific, predictable ways. This post is about those failure modes, and where the free tool you already have is genuinely the right call.

Sync copies the file. A mount streams the bytes. #

Here is the one distinction everything else hangs on. Syncthing, the free open-source peer-to-peer tool, divides each file into blocks, hashes them, requests the missing ones from a peer, writes them to a temporary copy, and only moves that copy into place once every block has arrived and verified (per the Syncthing docs, checked June 2026). That is clever and bandwidth-efficient, but the result is the same: a complete local copy of the whole file sitting on your disk before you can open it. Resilio Sync works the same way by default, replicating the full contents of a folder to every device. Nextcloud's desktop client does too, unless you turn on Virtual Files.

A real mount inverts that. When you double-click a 90 GB ProRes file on a streaming volume, nothing downloads. The editor asks for the few megabytes around the playhead, the mount fetches exactly those blocks from the NAS or cloud, caches them on local SSD, and hands them to the app. LucidLink describes its Filespaces this way: files are broken up block-by-block and "streamed to users on demand," sending only the data the application needs (lucidlink.com, checked June 2026). The analogy I use: sync is mailing someone the entire cookbook so they can read one recipe. Streaming is reading them the page over the phone while they cook. If you only ever need a few pages of a very large book, the difference is enormous. We dig into this further in block-level streaming versus whole-file sync and what a real mount actually means for editors.

Failure mode one: the disk math doesn't survive a real library #

Whole-file sync means every editor's laptop has to hold every file they want to touch. That is fine for a shared-docs folder. It falls apart the moment your media library is bigger than a laptop SSD, which for video is almost immediately. A single feature's worth of camera originals can run several terabytes. Syncthing will happily try to replicate all of it to a 1 TB MacBook, fill the disk, and stall.

The vendors know this, so both Resilio and Nextcloud bolted on a placeholder mode. Resilio's Selective Sync creates 0-byte .rsls placeholder files that "represent the files in the share without the file content itself," and you double-click to fetch one (Resilio Help Center, checked June 2026). Nextcloud's Virtual Files do the same: files appear in Finder but download on demand. This narrows the gap, but read the mechanism carefully. Both download the whole file on access, not the bytes you need. Open a 90 GB master to grab one shot and you wait for all 90 GB, then it sits on your disk taking up space until you evict it. A streaming mount never materializes the whole file at all; it pages in the blocks under the playhead and discards them from cache later. Placeholders fix the "my disk is full" problem halfway. They do nothing for the next one.

Failure mode two: scrubbing a timeline is the wrong shape for sync #

Editing is not one big download. It is thousands of tiny, latency-sensitive reads: scrub the playhead, the app seeks into the middle of a clip and reads a few frames; jump to a marker, it reads somewhere else; render the timeline, it reads from a dozen files at once. Sync tools are built for the opposite traffic pattern: get the whole file from A to B once, then leave it alone. They have no concept of "open a file partway through and read only what the app touches," because to a sync engine an open file is just a thing to copy in full and watch for changes.

So with placeholder-based selective sync, the first scrub into an un-fetched clip blocks while the entire clip downloads. With full sync, you have already paid that cost up front and filled your disk. Neither gives you what a mount gives you: seek anywhere in a 90 GB file and get frames back in the time it takes to fetch a few blocks, because the volume understands partial reads. This is the same latency-versus-bandwidth trap that makes a NAS feel sluggish over a tunnel. Gigabit fiber does not help if every seek is a round trip. We cover the network side of that in why your NAS feels slow over a VPN.

Failure mode three: two editors, one project, and the conflict file #

This is the one that costs you a day. Sync tools have no central authority over a file while it is open. If two people edit overlapping work, the engine cannot merge them; it picks a winner by heuristic and renames the loser. Syncthing's documentation is candid about this: when it detects a conflict it guesses the canonical version using modification dates, and if the times are equal it keeps the file from the device whose ID has the larger first 63 bits, renaming the other with a .sync-conflict-<date>-<time>.<ext> suffix (Syncthing docs, checked June 2026). For a text note, you reconcile two copies. For a Premiere or Resolve project database that two assistants both had open, you get a silently forked project and a confusing duplicate, and you find out when someone's afternoon of work is missing.

A real shared volume sidesteps this because there is one copy of the file on the NAS and the filesystem mediates access, the same way a local drive does. The mount is a window onto that single source of truth, not N independent copies racing to agree. If your whole workflow is one editor at a time, this failure mode never fires and sync is fine. The day you add a second editor to the same project, it becomes the reason you switch. For the team-collaboration angle specifically, see the LucidLink alternatives roundup.

Where sync genuinely wins: offline and pure replication #

I am not here to bury the sync tools, because for a real set of jobs they are the better answer and they are free or nearly so. The standout is offline. Because sync keeps a full local copy, a synced folder works perfectly with the network unplugged: editing on a plane, on location with no signal, in a facility with a flaky uplink. A streaming mount is the opposite. LucidLink "requires a high-speed, low-latency internet connection," and losing connectivity can make the whole filespace inaccessible until you reconnect (per comparison reporting and Resilio's own LucidLink writeup, checked June 2026). That is the unavoidable cost of not keeping local copies.

Sync also wins as pure site-to-site replication: keeping two NAS boxes in two cities byte-for-byte identical, mirroring to a backup, or pushing finished deliverables to an archive tier. That is exactly the job whole-file sync was built for, and many shops correctly run both, a streaming mount for live editing and Resilio or Syncthing for replication and offline kits. If your need is "make these two folders match," reach for the free tool. If your need is "edit a library too big to copy, with more than one person," that is a mount.

Where a self-hosted mount fits, and where it does not #

JuiceMount exists for the bottom two rows of that table: you already own the NAS, you want block-level streaming and a real Finder volume for a small team, and you do not want a per-seat cloud bill. It is the streaming model from this post pointed at hardware you control, with a local SSD cache so scrubbing stays snappy. Where it does not fit: if you genuinely live offline, a full-copy sync tool is the more honest tool, and a mount will frustrate you. And if all you need is to keep two folders identical, you do not need a mount at all; Syncthing does that for free and does it well. The mount earns its keep specifically when the library is too big to copy and more than one person touches it at once. For where this lands against the hosted services, see JuiceMount versus the SaaS suites.