Shut the Mac Down After the VPN Work, Not Before

Two people shut down the same Mac after work and get different results. One loses an upload that was ninety percent finished; the other closes the lid twenty seconds later with everything committed. The difference is not luck or disk speed. It is the order in which they close the private session, the share, and the tunnel, and whether anything waits for those steps to finish.

The comparison below is between "tunnel first" and "work first", because that single choice explains most of the bad outcomes.

Two shutdown orders, two outcomes

Tunnel first looks tidy: the VPN menu says Disconnect, the icon disappears, and then the user closes documents and shuts down. The problem is that the disconnect may drop the routes and the mounted share before the application has finished writing, and an upload in flight has nowhere to go. The user sees a clean disconnect and assumes the rest is safe. Nothing about an icon disappearing says the application finished. The shutdown then proceeds normally over a network path that no longer carries the traffic the application needed.

Work first is slower by a few seconds and much less eventful. The private operation completes, the share is unmounted deliberately, and only then does the tunnel go away. The shutdown that follows has nothing left to interrupt.

Why the share has to go before the tunnel

A mounted network share is a live dependency, not a folder. The client keeps handles open, the server tracks leases, and a write that is still in the queue belongs to that session. Yanking the tunnel underneath it produces the classic stale mount: the Finder shows the share, any access hangs, and the only cure is to force an unmount and sometimes to log out.

Unmount through the supported action after file activity has stopped. On macOS that is the eject control in the Finder or a deliberate diskutil unmount for the mount point, not a disconnect of the underlying network. Then confirm the share is gone from the sidebar before touching the VPN.

If the share refuses to unmount, something still holds a file open. Find it, close it, and try again. A refusal is information; forcing the unmount converts it into data loss.

Stop the client that owns the session

A VPN session has an owner, and only that owner can stop it cleanly. Tunnelblick connections stop through Tunnelblick. A native configuration stops through the system's own control or the app that manages it. Running a separate OpenVPN binary against a profile with a similar name does not stop the application-managed session, and it can leave two processes disagreeing about who holds the tunnel device.

Watch for automatic recovery. An On Demand rule or a managed profile can start the connection again seconds after a deliberate stop, which looks like the client ignoring the command. That behaviour is policy, not a bug, and it needs to be resolved with whoever owns the policy rather than fought with a helper that keeps disconnecting.

Some clients separate "disconnect requested" from "teardown complete". If the workflow waits for completion, read the client's own state and give it a bounded deadline. An arbitrary one-second sleep is not a wait, and killing every process with a VPN-sounding name is not a teardown.

Leave the operating system's shutdown alone

The final step should be an ordinary shutdown: Apple menu, keyboard shortcut, or a scheduled shutdown command. That path lets applications save, asks the user about unsaved work, and unmounts volumes in the expected order. It is also the path whose failures are reported in a way someone can debug.

Forcing the power off skips all of that. It is the right tool when the machine is genuinely wedged, and the wrong tool as a routine way to beat a deadline. A forced shutdown that discards an upload is not faster than waiting; it just moves the cost to the next morning.

Apple's shutdown guidance draws that line and describes the forced case separately. Read it as a reason to fix the ordering rather than as permission to make force-quitting part of the daily routine.

Build the deadline into the plan

If the Mac must be off at a fixed time, start the preparation while the user session is still alive. Waiting until the last minute to run cleanup is how an MFA prompt, an unfinished write, or a stubborn mount turns into an incident. Give the sequence a start time, not just an end time.

Decide what happens when a step exceeds its budget. The options are to notify the user, to cancel the shutdown, or to follow another approved procedure. Silently escalating "cleanup took too long" into a forced power-off is the one option that guarantees the outcome everybody was trying to avoid.

Written down, the rule is short: finish the private work, close the dependent session, stop the tunnel through its owner, then shut down normally. Four steps, in that order, with a deadline attached to each.