0

I am using systemd to automatically mount a NFS partition on a notebook with Arch.

Problem:

If dolphin had a folder of the NFS share opened when closing and I change the network, it refuses to open the next time I start it.

The same sometimes happens for zsh and other software.

The problem only happens when I'm connected to any other than my usually used network and don't use my VPN or not connected to any network at all. As long as the NFS server is reachable by my system, everything works as smooth as it should.

current Workaround:

At the moment I'm circumventing that problem by stopping the automount unit and starting the application again.


Here are the relevant unit files:

/etc/systemd/system/pool1.automount

Content:

[Unit]
Description=Automount NFS pool1
Requires=NetworkManager.service
After=network-online.target

[Automount]
Where=/pool1
TimeoutIdleSec=10min

[Install]
WantedBy=multi-user.target

/etc/systemd/system/pool1.mount

Content:

[Unit]
Description=Mount NFS pool1

[Mount]
What=192.168.1.5:/pool1
Where=/pool1
Type=nfs
Options=soft,async

I'm sure that there is an option to tell systemd to only try to mount the share if it is present, but I haven't found anything about it.

I am looking for a solution which seamlessly handles different networks without any delays if the NFS server is not present.


Update

I've added TimeoutSec=5 to the [Mount] section, the only difference is that now dolphin gives up after 5 seconds and closes itself.

1
  • 1
    Mount units have a TimeoutSec= parameter applicable to them, after which systemd gives up on that mount - link. The default value seems to be 90s. You can try configuring this to a lower value, and see if dolphin recovers properly.
    – Haxiel
    Feb 26, 2022 at 3:16

1 Answer 1

1
+50

I was able to recreate the problem. There seems to be multiple issues at play. NFS itself, systemd, and the network stack have issues. The automount stuff is not really designed for transient conditions. Maybe it can be hacked to work better, I don't know. Anyway...


A brute force approach is shown here. Basically, don't use automount and instead continuously ping the server from cron and mount or unmount based on its status.


Another approach from my experimentation it's possible to use networkd-dispatcher to mount and unmount automatically. The event scripts detect the server or network and act accordingly.

Create fstab for the mount (or whatever method you prefer). Set to "noauto" at least.

Create the following script at /etc/networkd-dispatcher/routable.d/10-nfs-pool1. Mark executable (I guess).

#!/bin/sh
if ping -q -c1 nfs-server >/dev/null; then
   mount /pool1
else
   umount -f -l /pool1
fi

Now duplicate that file in off.d and no-carrier.d:

ln -s ../routable.d/10-nfs-pool1 /etc/networkd-dispatcher/off.d/
ln -s ../routable.d/10-nfs-pool1 /etc/networkd-dispatcher/no-carrier.d/

Unfortunately both of the above approaches keep the mount active even when it's not being used. The problem with automount is when you start manually managing the mount then automount gets disabled. Automount seems like it could use more features but maybe I just don't know about them.

1
  • Thanks for taking the time to come up with a solution Mar 15, 2022 at 23:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .