Add new post about NFS on Tailscale
This commit is contained in:
Greg Hellings
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: "NFS Over Tailscale - or any VPN"
|
||||
date: 2025-10-26T22:20:32-05:00
|
||||
draft: false
|
||||
---
|
||||
|
||||
## The Problem
|
||||
For my home media consumption I use a [media server](https://jellyfin.org/)
|
||||
that runs in a small VM with passthru of a GPU for transcoding needs. The files
|
||||
are hosted on [my local NAS](https://www.truenas.com/) box, which handles running
|
||||
services like [Pinchflat](https://github.com/kieraneglin/pinchflat) and also
|
||||
holds the digitized copies from my wife's CD collection and my home photo
|
||||
and family video collection. The NAS exports each of these 3 collections as
|
||||
an NFS share that everyone on the LAN can mount, including the media server VM.
|
||||
|
||||
The media server and VM both are connected to my [Tailnet](https://tailscale.com/)
|
||||
in order to facilitate easy interoperation with my phone, my Kubernetes cluster,
|
||||
and other pieces of my personal infrastructure. Although the VM and NAS are on
|
||||
the same actual physical LAN and could directly connect over IP address, for
|
||||
the sake of continuity I keep all of my infrastructure communicating over the
|
||||
VPN.
|
||||
|
||||
This led to a problem: the VPN sits in the startup chain later than the mounts
|
||||
are being attached. While the system is smart enough to reserve NFS automounts
|
||||
for after reaching the `networking-online.target`, it was unaware that my
|
||||
particular needs include waiting for Tailscale to also be started.
|
||||
|
||||
## The Solution
|
||||
|
||||
So this is where I had to step outside of `/etc/fstab` and instead create a
|
||||
systemd mount file instead. `/etc/fstab` allows you to specify as an option
|
||||
a dependency on another mount using the option `x-systemd.requires=foo`, but
|
||||
I was unable to convince that option to allow me to specify a `foo.service`.
|
||||
It only seems to want to accept `foo` and assumes that its type is a `.mount`
|
||||
file. But, by crafting an actual systemd unit file for the mount directly, I
|
||||
could control this behavior.
|
||||
|
||||
In [NixOS](https://nixos.org) I configured it as follows:
|
||||
```nix
|
||||
systemd.mounts = let
|
||||
nfs = name: {
|
||||
what = "nas.my-domain.ts.net:/mnt/path/to/share/${name}";
|
||||
type = "nfs";
|
||||
name = "${name}.mount";
|
||||
where = "/${name}";
|
||||
requires = [ "tailscaled-autoconnect.service" ];
|
||||
after = [ "tailscaled-autoconnect.service" ];
|
||||
wantedBy = [ "multi-user.target" ];
|
||||
mountConfig.Options = "_netdev,noexec,ro,timeo=50,retrans=5,soft";
|
||||
};
|
||||
in [
|
||||
(nfs "photos")
|
||||
(nfs "video")
|
||||
(nfs "music")
|
||||
];
|
||||
```
|
||||
The options here are pretty well mapped directly to the systemd unit file
|
||||
options that you might expect.
|
||||
|
||||
## The Details
|
||||
|
||||
However, just for completeness's sake I'll show
|
||||
you one of the full systemd unit files it generated in case you are not on
|
||||
a NixOS system.
|
||||
|
||||
```
|
||||
[Unit]
|
||||
After=tailscaled-autoconnect.service
|
||||
Requires=tailscaled-autoconnect.service
|
||||
|
||||
[Mount]
|
||||
Options=_netdev,noexec,ro,timeo=50,retrans=5,soft
|
||||
Type=nfs
|
||||
What=nas1.private-redacted.ts.net:/mnt/all/video
|
||||
Where=/video
|
||||
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Of course, in order for this to work for you, you will need a `tailscaled-autoconnect.service`
|
||||
to wait on. It is not sufficient just to wait for the normal `tailscaled.service` unit
|
||||
file that is normally present. That only starts the daemon, but the daemon can sometimes
|
||||
take a bit to connect. That's where NixOS module maintainers come to the rescue by
|
||||
giving me this very helpful tailscaled-autoconnect service that I can latch on to. It has a
|
||||
`Type=notify` configuration and just runs a shell script, which I will replicate here:
|
||||
|
||||
```bash
|
||||
set -o errexit
|
||||
set -o nounset
|
||||
set -o pipefail
|
||||
|
||||
getState() {
|
||||
tailscale status --json --peers=false | jq -r '.BackendState'
|
||||
}
|
||||
|
||||
lastState=""
|
||||
while state="$(getState)"; do
|
||||
if [[ "$state" != "$lastState" ]]; then
|
||||
# https://github.com/tailscale/tailscale/blob/v1.72.1/ipn/backend.go#L24-L32
|
||||
case "$state" in
|
||||
NeedsLogin)
|
||||
echo "Server needs authentication, sending auth key"
|
||||
tailscale up --auth-key "$(cat /run/agenix/tailscale-key)?preauthorized=true" --hostname jellyfin
|
||||
;;
|
||||
Running)
|
||||
echo "Tailscale is running"
|
||||
systemd-notify --ready
|
||||
exit 0
|
||||
;;
|
||||
*)
|
||||
echo "Waiting for Tailscale State = Running or systemd timeout"
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
echo "State = $state"
|
||||
lastState="$state"
|
||||
sleep .5
|
||||
done
|
||||
```
|
||||
|
||||
Quickly looking through this script it is very straightforward. It loops every 0.5 seconds, calling
|
||||
the `tailscale up` command when the system needs to be logged in and passing it my Tailscale OAuth key.
|
||||
Once the system is up and Running, meaning that the connection to Tailscale is completed, it will
|
||||
notify systemd that the service has come up and then exit gracefully.
|
||||
|
||||
Obviously, tweak these scripts and needs to your own use. In NixOS, most of them are already present
|
||||
and all you need is to start your mount after `tailscaled-autoconnect.service`. A similar technique
|
||||
could easily be adapted to other flavors of Linux and to other VPN providers.
|
||||
Reference in New Issue
Block a user