NFS Share Over a WireGuard Tunnel
<-Installing WireGuard on OpenMediaVault 5.6.1 (March 2021)

Not many will be concerned about this topic and, manifestly, neither was I because for over a year now I ignored my inability to mount an NFS share on a remote OpenMediaVault system accessed through a WireGuard virtual private network. It has always been possible to open SSH sessions with the remote system over the WireGuard tunnel which was enough for my needs. Yesterday, in a fit of housekeeping, I pushed commits to a couple of Mercurial backup repositories on the remote system and I wondered why this was being done through SSH (which requires hg on the remote machine) and not directly with the hg instance on my desktop.

The principal players their pertinent attributes are as shown below when the WireGuard tunnel is in place.

Extra points for anyone that works out the source of the user and host names. And if you are wondering, the WireGuard interface is named romv on the desktop and wg0 on the remote machine.

Here is the problem that I was encountering until yesterday after creating a tunnel between the two computers.

michel@hp:~$ sudo wg-quick up romv [#] ip link add romv type wireguard [#] wg setconf romv /dev/fd/63 [#] ip -4 address add dev romv [#] ip link set mtu 1420 up dev bomv [#] ip -4 route add dev romv michel@hp:~$ sudo mount -t nfs /media/michel/romv_michel mount.nfs: access denied by server while mounting

That stymied me because the showmount command seemed to prove that the remote system and the shared directory /export/_michel were reachable through the VPN.

michel@hp:~$ showmount -e Export list for /export /export/_michel,

Looking at the notes taken back a year ago, it's obvious I gave up rather quickly. Yesterday I had the brilliant idea to look at the log on the remote system after failing to once again mount the share.

michel@romv:~$ journalctl -e -- Logs begin at Sun 2021-02-13 02:43:19 AST, end at Tue 2021-02-22 15:51:38 AST. -- ... Feb 22 15:48:11 romv rpc.mountd[511]: refused mount request from for /export/_michel (/export/_michel): unmatched host ...

I was surprised to see that the request for the mount came from the desktop end of the WireGuard "virtual" network: In retrospect, I wish I had turned on verbosity when trying mount the remote share.

michel@hp:~$ sudo mount -v -t nfs /media/michel/romv_michel mount.nfs: timeout set for Tue Feb 22 16:08:19 2022 mount.nfs: trying text-based options 'vers=4.2,addr=,clientaddr=' mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting

Perhaps I would have twigged onto the network mismatch, but I was assuming that the tunnel was totally transparent and mounting the romv shared directory on the desktop would proceed just it occurs when mounting a shared directory located on a NAS on the home network that is also running OpenMediaVault. No use worrying about that now. In any case, that "unmatched host" flag in the log made it easy to find a key piece of advice: How to fix "mountd: refused mount request: unmatched host" by GOLINUXHUB. So as usual, I am presenting a solution found by someone else. Let's start by looking at the exports on the remote system.

michel@romv:~$ sudo exportfs -v /export/_michel,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,insecure,root_squash,no_all_squash) /export,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,ro,secure,root_squash,no_all_squash)

So OpenMediaVault had provided for sharing the /export/_michel directory on the subnet and the request was coming from a different subnet: Editing the /etc/exports file as suggested by GOLINUXHUB didn't seem like a good idea because that file begins with an ominous message.

# This file is auto-generated by openmediavault (https://www.openmediavault.org) # WARNING: Do not edit this file, your changes will get lost.

Luckily, the exportfs man page says that extra configuration files can be created in a subdirectory.

FILES /etc/exports input file listing exports, export options, and access control lists /etc/exports.d directory where extra input files are stored. Note: only files that end with .exports are used.

Let's proceed with that option hoping that OpenMediaVault will not harm the extra configuration file.

michel@romv:~$ sudo mkdir /etc/exports.d michel@romv:~$ echo "/export/_michel,subtree_check,insecure)" | sudo tee /etc/exports.d/tunnel.exports /export/_michel,subtree_check,insecure)

Let's reexport all directories and check the modified exports.

michel@romv:~$ sudo exportfs -ra michel@romv:~$ sudo exportfs -v /export/_michel,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,insecure,root_squash,no_all_squash) /export/_michel,wdelay,insecure,root_squash,sec=sys,rw,insecure,root_squash,no_all_squash) /export,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,ro,secure,root_squash,no_all_squash)

Mounting the NFS share and testing shows that it is possible to create, set attributes, execute and delete files just as on a local drive.

michel@hp:~$ sudo mount -v -t nfs /media/michel/romv_michel mount.nfs: timeout set for Tue Feb 22 16:11:11 2022 mount.nfs: trying text-based options 'vers=4.2,addr=,clientaddr=' mount.nfs: mount(2): No such file or directory mount.nfs: trying text-based options 'addr=' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying prog 100005 vers 3 prot UDP port 39036 michel@hp:~$ ls -l /media/michel/romv_michel/test ls: cannot access '/media/michel/romv_michel/test': No such file or directory michel@hp:~$ touch /media/michel/romv_michel/test michel@hp:~$ ls -l /media/michel/romv_michel/test -rw-rw-r--+ 1 michel users 0 Feb 22 16:00 /media/michel/romv_michel/test michel@hp:~$ cat > /media/michel/romv_michel/test<< EOF > #!/bin/bash > echo "hello" > EOF michel@hp:~$ chmod +x /media/michel/romv_michel/test michel@hp:~$ /media/michel/romv_michel/test hello michel@hp:~$ rm /media/michel/romv_michel/test michel@hp:~$ ls -l /media/michel/romv_michel/test ls: cannot access '/media/michel/romv_michel/test': No such file or directory

There is a benefit to mounting the share in the media directory; it shows up as a device (appareil in French) in the (Caja) file manager on the desktop.

share in Caja

I envision mounting the shared remote directory only occasionally so I cobbled together a bash script to take care of the chore.

#!/bin/bash if [ ! -d "/sys/class/net/romv/" ]; then # no romv interface, setup the Wireguard tunnel sudo WireGuard-quick up romv sleep 2 if [ ! -d "/sys/class/net/romv/" ]; then echo "Could not setup WireGuard tunnel" exit 1 fi fi # mount the NFS share on romv #sudo mount -v -t nfs -o nfsvers=3 /media/michel/romv_michel sudo mount -t nfs -o nfsvers=3 /media/michel/romv_michel if [ $? -eq 0 ]; then echo "Remote directory mounted on /media/michel/romv_michel" else echo "Could not mount the remote directory" exit 2 fi

If for some reason the mount command does not work, then the following will be displayed.

michel@hp:~$ mount_romv mount.nfs: Connection timed out Could not mount remote directory

It takes so long for the operation to time out, I would probably bail out after a minute or so rather than let it complete its task.

It would be nice to report that the above is a perfect solution to the problem but it is not. Note how the shared directory was mounted with version 3 of NFS. This is confirmed with the following command.

michel@hp:~$ df -t nfs -t nfs4 --output=source,fstype,target Sys. de fichiers Type Monté sur nfs /tmp/romv_michel nfs4 /mnt/nas-michel

This is a bit surprising because, as can be seen, the shared directory on the local NAS also running OpenMediaVault was mounted with version 4 of NFS. Right now this seems like a curious artefact that may be explained by the nature of the quite old single core Athlon processor used on the remote machine. There's no proof that this is the case, but it's a good story. Note the -o nfsvers=3 option in the mount command in the bash file. It removes the attempt to mount the remote share with nfs4.

There was a major problem when I first mounted the remote share. It was impossible to create or modify files on the remote directory. There were permission errors that turned out to be associated with the different users on the desktop and the remote system. More accurately, the user name michel was the same on both machine but the user ID was 1000 on the desktop and 1001 on the remote system. I believe there are ways around this; I took the coward's way out. With a lot of scrambling and a bit of luck, I managed to change the michel user ID on the remote system to 1000. That, plus changing the owner:group of the shared directory from 1001:users to michel:users, worked. In retrospect, I wonder if just doing the later step alone would have been sufficient, but I will not investigate this any further at this point. In a year's time, I may come back, but the remote machine may be gone by then.

By the way, I decided to continue using the SSH protocol to push changes to the remote repositories. I am chalking up yesterday as a learning experience.

<-Installing WireGuard on OpenMediaVault 5.6.1 (March 2021)