Should the user session own the SSHFS mount over VPN?

Mounting a shared folder after the VPN comes up involves two identities that are easy to conflate: the component allowed to configure the network, and the account allowed to log in to the file server. They are rarely the same. A root-owned VPN hook is a poor place to start a desktop user's SSHFS mount, because it has neither the user's agent nor the intended mount ownership. Getting ownership right first makes the trigger simple.

Two identities, two separate permissions

The VPN client needs privileges to change routes and interfaces. The SSHFS mount needs an SSH identity the file server accepts and a FUSE mount owned by the account that will read the files. One script running as root satisfies the first requirement and quietly breaks the second.

Mounting as root leaves the files outside the desktop session and possibly without access to the agent holding the user's key. The mount exists, the user cannot write through it, and the failure looks like a server-side permissions problem. That misdiagnosis costs an afternoon and a ticket to the storage team.

Decide which account owns the mount before writing any automation, because that choice determines where the trigger lives and which credentials it can reach.

Establish a user-owned mount by hand first

Start from a signed-in user with an empty mountpoint, an authorized SSH account and a working path to the server through the tunnel. A manual mount establishes the baseline that any automation has to reproduce.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

The names are examples, so substitute the host and export path your server actually offers. Verify the host key through the approved process on that first connection. Note that a VPN account password is not automatically the storage account's credential, which is a common source of failed attempts.

Run it as a regular user with a mountpoint that user owns. Only the mounting account reaches the files by default, and allow_other widens that boundary to every local user. That is a deliberate widening of access, not a workaround for automation.

Make the trigger act in the same session context

Let the supported VPN event integration ask a user-session action to run, instead of assuming a privileged callback can borrow a desktop credential. Scope the trigger to the intended connection identifier rather than to any interface that happens to be called tun0. A dispatcher rule matching the wrong thing fires on every network change, including ones that have nothing to do with this mount.

The action should confirm the expected hostname, notice an existing mount, and make one bounded attempt. A poll loop that starts a new SSHFS process every few seconds, or retries a credential prompt while the server is down, turns a short outage into a pile of stuck processes. Bound the attempt with a timeout and a single retry.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

The first command gives the connection identifier the dispatcher should match. The other two show whether an attempt is already running, which is the check that prevents duplicates.

An unattended service needs its own approved credential and host-verification arrangement in its own execution context. It cannot assume a graphical agent is unlocked, and it should not try to unlock one.

Plan the disconnect before forcing cleanup

For a planned disconnect, finish file operations and unmount from the mounting user's own workflow. Target the mountpoint rather than the process, and confirm the result before reporting success.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Unmount only the mount this workflow created. If it is busy, that is an application decision: a forced detach that exists to make a hook return success hides data loss instead of preventing it.

Unexpected loss behaves differently. SSHFS documents that a network interruption can block a filesystem operation, and the reconnect option restores the transport without restoring handles: a file opened before the reconnect can fail on the next write, and an interrupted write is not preserved. That distinction matters most for editors that keep one file open for hours. Plan a reopen step instead of assuming recovery.

Test the behaviour with disposable files before you rely on it. A directory that reappears after the tunnel returns does not prove that earlier handles or unsaved work survived.