View source for Mount on VPN Connect

I use a VPN to my server from my laptop which can happen from effectively "anywhere". But I also don't always ''want'' to connect to my server so I use the KDE Network Manager to manually connect with through GUI only when needed. This causes issues when it comes to mounting remote filesystems because the server isn't always available.

This is my solution for an adhoc drive mount over and unpredictable VPN connection. This uses Systemd due to its ability to add dependencies which make it more robust. I'm also only going to be covering SMB. In my experience NFS is inferior in performance consistency even in an all Linux environment.

== Starting Point ==
On your server you need to setup a typical Samba setup<ref>https://ubuntu.com/tutorials/install-and-configure-samba#1-overview</ref>. Make sure you can mount your share on your client computer using other methods like <code>mount</code> or <code>/etc/fstab</code>.

I'm also going to be using Wireguard<ref>https://www.wireguard.com/quickstart/</ref> but there isn't anything unique to that for this setup. Note that we do not need proxy forwarding for this.

== VPN Network Interface Target ==
In order to prevent the mounts from attempting to access the server when it is unreachable we need to set the VPN connection as a dependency of the Systemd mount. This is not the same as <code>network-online.target</code>. We can use a specific network interface device as a target, but you need to find what yours is called.

You can list all targetable NICs for Systemd using the following command:<syntaxhighlight lang="bash">
systemctl list-units --no-pager | grep net-device
</syntaxhighlight>You'll be given a result similar to this:<syntaxhighlight>
sys-subsystem-net-devices-docker0.device                 loaded active plugged   /sys/subsystem/net/devices/docker0
sys-subsystem-net-devices-enp45s0.device                 loaded active plugged   Killer E3000 2.5GbE Controller
sys-subsystem-net-devices-enx9cebe850e460.device         loaded active plugged   Dell D3100 Docking Station
</syntaxhighlight>The list can be much longer depending on your system. To more easily find your VPN interface you can run the command before and after connecting and look for the new line that will be added. For reference, here is how my Wireguard connection was shown:<syntaxhighlight>
sys-subsystem-net-devices-Videos\x2dLocal.device         loaded active plugged   /sys/subsystem/net/devices/Videos-Local
</syntaxhighlight>I will be using <code>sys-subsystem-net-devices-Videos\x2dLocal.device</code> as my target for service unit scripts.

== Systemd Mount and Automount ==
Systemd can manage the mounting of filesystems as unit files. These are just plain text files that are easily configurable for different needs. On Ubuntu, as an example, they are located in <code>/etc/systemd/system/</code>. We are going to make a <code>mount</code> and <code>automount</code> service for each share you want to mount to after connecting to the VPN.

=== Mount Service File ===
The SMB/CIFS settings for the mount go in the <code>mount</code> script. The settings you need for this will be dependent on your server setup but the one I'm using here are a decent general purpose solution.
{| class="wikitable"
|+opt-videos.mount
|<syntaxhighlight lang="systemd" line="1">
[Unit] 
Description=SMB Share
OnFailure=automount-restarter@%N.service

[Mount]
# Server share path over VPN
What=//10.0.10.1/videos 
# Local mount directory
Where=/opt/videos 
# SMB mount options
Options=credentials=/etc/smb.conf,vers=3.1.1,uid=1000,iocharset=utf8
Type=cifs 
TimeoutSec=30
</syntaxhighlight>
|}
Some notes about different settings in there:

* '''credentials''': The path to a file that stores the user auth for connecting to the samba server<ref>https://ubuntu.com/tutorials/install-and-configure-samba#3-setting-up-samba</ref>
* '''uid''': The user ID number for the user on the ''server'' you want the file modifications to be saved as.
* '''opt-videos.mount''': The filename for the unit file '''must''' match the path set in <code>Where=</code> with directory delimiters (<code>/</code>) replaced with hyphens.

We'll get to '''OnFailure''' below as it is a workaround for a Systemd quirk.

=== Automount Service File ===
The mount file lacks an <code>[Install]</code> directive meaning it is not run during startup. The automount file does and by sharing the same filename will watch for filesystem access of the mount path to automatically call the mount file. It also has the dependencies to know to run only after the network interface is connected.
{| class="wikitable"
|+opt-videos.automount
|<syntaxhighlight lang="systemd" line="1">
[Unit]
Description=SMB Share Automount
OnFailure=automount-restarter@%N.service
# Network interface target dependancies
After=sys-subsystem-net-devices-Videos\x2dLocal.device
Requisite=sys-subsystem-net-devices-Videos\x2dLocal.device

[Automount]
Where=/opt/videos

[Install] 
WantedBy=multi-user.target
</syntaxhighlight>
|}
The name of the automount file must be the same as the mount file and also requires the <code>Where=</code>  value for the mount path. Note that we are using <code>Requisite=</code> instead of <code>Requires=</code>. Like requires, requisite will make the target in <code>After=</code> a dependency. Unlike requires, requisite will not attempt to launch the target and instead will terminate as a failure immediately if it is not running. In this application this prevents Systemd from waiting for the VPN connection to start when it may or may not be connected depending on what the user is doing. This will also call the '''OnFailure''' service that we will get to in a moment.

== Self Starting ==
If you connect to your VPN and start the automount service the filesystem should be mounted when you attempt to access the mount path. If you attempt to enable the service and reboot though, it will fail and stay terminated. There is no built in feature of Systemd to re-attempt to start on failure. This is where the last unit file comes into play. This is based on a solution responding to an issue to this very problem on Systemd's git repository<ref>https://github.com/systemd/systemd/issues/16811#issuecomment-728662590</ref>.
{| class="wikitable"
|+automount-restarter@%N.service
|<syntaxhighlight lang="systemd" line="1">
[Unit]
Description=automount restarter for %i

[Service]
Type=oneshot
ExecStartPre=/usr/bin/sleep 10
ExecStart=/usr/bin/systemctl restart %i.automount
</syntaxhighlight>
|}
This is a service that the mount and automount files will call on failure. It will wait 10 seconds and then call back the service that called it. Being a <code>oneshot</code> service means that it will instantly exit and not persist, so you will not build a growing stack of services calling each other.

Functionally, this means that after booting your computer will attempt to start the automount service every 10 seconds, and if you are not connected to your VPS it will never attempt to mount it. This is the most flexible solution to this problem I have found so far and is easily adaptable to add additional mounts by creating more Systemd files. 

== Refrences ==
<references />
[[Category:Guide]]