SMB share after a VPN drop: a recovery checklist
Stop writing, restore the real server path, and treat a failed save as unknown rather than lost. Open handles do not survive a new VPN session.
Your save hangs, the tunnel drops, and thirty seconds later the VPN is connected again while the Finder window spins on an empty share. Everything looks like it should be working. The tunnel is up, the network is up, and the volume is not. Work through this in order, because reconnecting while an application still believes it holds an open handle is how an uncertain write becomes a lost one.
Start by stopping work on the share rather than by reconnecting it. That feels passive and it is the step that protects your data.
Stop writing before you reconnect
Close anything actively trying to write, and save what you can to a local location through the application's own save or recovery path. Do not start a large copy, do not let a sync client keep retrying forever, and do not accept a prompt that offers to replace the server copy with your local one. That third instruction is the one that costs data, because a timed-out save is neither confirmed nor necessarily absent, and overwriting the server file removes the only evidence of what actually happened.
If the application shows two versions of the same document, leave both in place for now. Choosing a winner by filename or timestamp is guesswork dressed as a decision.
Restore the path, then prove it
Reconnect the intended VPN and finish its authentication, then confirm that the file server's name resolves and that the SMB service answers over the tunnel. A status of connected describes the tunnel only, so treat that as the beginning of the check rather than the end of it.
Confirm name resolution and reachability for the file server through the tunnel.
Give the existing mount a minute before creating another one; a second volume with an identical label is harder to reason about than a slow recovery.
If the volume stays away, connect deliberately with Go, then Connect to Server, and the server's known address such as
smb://files.corp.example/team.Sign in with the file-server account, which is a separate credential decision from the VPN login, and confirm the document state in the application before continuing.
Apple's Finder connection guide documents the explicit-address method, which is the reliable path here. A volume name sitting in the sidebar is a cached label, not evidence that the previous connection is still usable.
Why a fresh session cannot promise open handles
SMB does have mechanisms for surviving a temporary disconnect, and both are conditional. Durable opens can be reconnected inside a time window negotiated between client and server, while persistent opens require stricter capabilities on both sides. A Mac client and a file server agreeing to mount a share says nothing about whether either mechanism was negotiated for the files you had open.
The specification is equally clear about failure: when recovery does not succeed, the handle is invalidated and the client is expected to treat the file as closed. An application that was mid-write at that moment has no valid handle to continue from, even though the share is browsable again and the file looks intact in Finder.
That is why the reappearing volume is a necessary step and not a sufficient one. Editors, database-style applications and anything holding an exclusive lock may need their own connection reopened, and the only trustworthy report of document state comes from the application rather than from the file listing.
Do not force the mount to look tidy
Force-unmounting the volume or killing filesystem helpers to clear a stuck sidebar is tempting and usually counterproductive. A stuck state often reflects a real pending operation, and pulling the mount out from under it does not deliver the application's data anywhere safe. It also makes the next investigation harder, because the error the user saw has been cleared from the screen. Record the exact error the application reported and the time of the disconnect, since that timestamp is what lets you match your report against the server's logs.
If the share stays busy, use the file-service or Mac support procedure instead of escalating force. Preserving the evidence is worth more than a clean sidebar.
Before the next planned drop
Finish saves, close dependent files and eject the share normally before disconnecting a VPN on purpose. That sequence is cheap and removes this entire class of question.
For work that hits outages often, change the working model rather than the mount: keep a local copy and synchronise through an application-supported mechanism, so a dropped tunnel costs you a sync interval instead of an uncertain write. A mount script cannot preserve arbitrary open-file transactions, and no amount of tuning will make it try.