Every network mount disconnects eventually. Wi-Fi drops, a switch reboots, a laptop sleeps with the lid half closed, a VPN renegotiates. The question is not whether it happens. The question is what your editor was doing at that exact moment, because the answer changes a lot.
We build a mount, so read the last section as the vendor talking. Everything before it applies to any network storage you point an editor at.
Three states, three different outcomes
An editing application interacts with media in three ways, and each one fails differently.
Idle reference. The clip is in the project, listed in the bin, and nothing is reading it right now. A dropout here costs you almost nothing. The file goes offline, the editor marks it, and when the mount returns the reference resolves again. This is the common case and it is why people think dropouts are harmless.
Active read. The playhead is over the clip and the application is streaming frames off the disk. A dropout here stalls playback. Most editors recover, though some will show a frame of garbage or drop to a lower resolution first.
Open write handle. The application has a file open for writing. Autosave, cache, a render in progress, or the project file itself if it lives on the mount. This is the one that costs you work.
The write case is the one to care about
When a write handle is severed mid-operation, the file on the other end is in whatever state the last completed write left it. That may be a valid file. It may be a truncated one.
The specific danger is a project file stored on the mount. Editors write project files by a sequence of operations, and an interruption partway through can leave a file that opens with missing sequences, or does not open at all.
The mitigation is boring and it works: keep the project file on local disk. Media on the mount, project local. Then a dropout costs you a stall rather than a project.
This is also why autosave to a network location is a worse idea than it looks. Autosave exists to protect you from a crash. Pointing it at a resource that can vanish means the safety net shares a failure mode with the thing it is protecting you from.
Why "it reconnected" is not the same as "it recovered"
macOS will often re-establish a mount on its own. The volume reappears in the Finder at the same path and everything looks restored.
The application may not agree. A process that held a file handle across the disconnect can be left holding a stale one that points at nothing. The path is valid, the file is there, and that specific handle is dead. This is the situation where the Finder shows your media and the editor insists it is offline.
The fix is almost always to relink or to restart the application, not to remount again. If your editor claims media is offline while you can see the files, believe the editor. It knows something about its own handles that the Finder does not.
Protocol changes the shape of the failure
SMB and NFS behave differently when the far end goes away, and it is worth knowing which you are on.
SMB tends to fail fast. Operations return errors, the application finds out, and you get an offline marker relatively quickly.
NFS with default mount options tends to block. The operation waits for the server to come back, and the application waits with it. This is where a beachball that never resolves comes from. It is not a hang in the usual sense, it is a read that is still politely waiting.
Neither is wrong. Fail-fast is better for interactive work because the application can respond. Blocking is better for batch work where you would rather wait than lose the job.
What to check before your next long session
- Project file on local disk, not on the mount.
- Autosave pointed at local disk.
- Cache and scratch on local disk. Everything that gets written frequently should be on the disk that cannot disappear.
- Know which protocol you are on and whether it blocks or fails fast.
- Save before you walk away, because sleep is a disconnect.
That list is free and it removes most of the damage a dropout can do. None of it requires changing your storage.
Where a mount helps, and where it does not
Vendor section, as promised.
A mount cannot stop your network dropping. Anyone claiming otherwise is selling something. What it can do is narrow the blast radius: read media over the mount, keep everything written frequently on local disk, and a disconnect becomes an interruption rather than a loss.
That is the honest claim. The bigger wins from a real mount are elsewhere, in not waiting for downloads and not keeping three copies of a project in sync, and we have written about those in what a real mount means and block streaming versus whole-file sync.
Resilience is not the reason to change your storage. It is a thing you configure correctly whatever storage you are on.