2

I need to mount NFS shares on my laptop when I am in the office and plugged into a wired Ethernet connection (via a dock). Is there a reliable way to automatically mount and unmount NFS shares in this scenario?

I'm running Arch Linux. I tried the NetworkManager dispatcher method described here: NFS - ArchWiki

Using that method, my system will freeze (hang, become unresponsive) when I try to connect to any WiFi access point outside the office.

All of my NFS mounts use these options:

nfsserver:/path/one/ /path/one nfs _netdev,defaults,noatime,nodiratime,soft,retrans=6,timeo=20,retry=0,rsize=32768,wsize=32768,proto=tcp   0 0

The full instructions I used from the link above are pasted here:

Enable and start the NetworkManager-dispatcher.service.

The following script safely unmounts the NFS shares before the relevant network connection is disabled by listening for the pre-down and vpn-pre-down events:

Note: This script ignores mounts with the noauto option.

Place this script at /etc/NetworkManager/dispatcher.d/30-nfs.sh

#!/bin/bash

# Find the connection UUID with "nmcli con show" in terminal.
# All NetworkManager connection types are supported: wireless, VPN, wired...
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"

if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then
    
    # Script parameter $1: NetworkManager connection name, not used
    # Script parameter $2: dispatched event
    
    case "$2" in
        "up")
            mount -a -t nfs4,nfs 
            ;;
        "pre-down");&
        "vpn-pre-down")
            umount -l -a -t nfs4,nfs >/dev/null
            ;;
    esac
fi

Make the script executable with chmod and create a symlink inside /etc/NetworkManager/dispatcher.d/pre-down to catch the pre-down events:

# ln -s /etc/NetworkManager/dispatcher.d/30-nfs.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-nfs.sh

In order to make this script actually work, I had to modify the case statement for the pre-down event as follows:

 "pre-down"|"down")

Before that change, no script action was taken in response to the pre-down event. After the change, script responds to events appropriately. However, as I said, my laptop freezes whenever I try to connect to WiFi access points outside of the office.

I can't find anything in the logs that seems related to this. But I have enough experience with NFS to guess that this issue is exactly what happens when NFS mounts are not available. Furthermore, the problem only started after I started using the method described above. Previously, I was connecting manually via SSHFS and I did not have a freezing problem.

I also briefly tried the following method:

[solved] Long delay booting with a downed NFS share / Networking, Server, and Protection / Arch Linux Forums

However, that method looked really sketchy and dated, so I gave up on it quickly. Because this seems to be a common need, I expect there is a known, reliable solution. However, I can't seem to find one.

Community
  • 1
MountainX
  • 17,168
  • 59
  • 155
  • 264
  • This would be an ideal situation to use the Automounter (`autofs`). – roaima Mar 26 '18 at 21:52
  • Here is the reason I didn't yet try autofs: https://unix.stackexchange.com/questions/415947/how-to-deal-with-freezes-caused-by-autofs-after-network-disconnect The OP says, "I thought autofs would help me here but it causes me even more trouble." – MountainX Mar 27 '18 at 05:08
  • On and off, I've been using NFS and automount for probably close to 15 years on various laptops. Works well provided you remember not to try and mount a filesystem that can't be reached. Note that your reference is to CIFS and SSHFS, whereas you are using NFS. – roaima Mar 27 '18 at 06:34
  • What do you mean by "provided you remember not to try and mount a filesystem that can't be reached"? I thought automating the process would eliminate situations like that. (I don't even have to worry about that with my manual mount script because it checks if the server is available before mounting.) – MountainX Mar 30 '18 at 20:50
  • `autofs` works by giving you a directory tree where filesystems are mounted (and umounted) on demand. The demand is triggered when you access the directory. If you accidentally try to `ls` a demand-mounted filesystem then `autofs` will go off and try to mount it. Doing that when the remote server isn't accessible leads to a frustrating wait while everything times out. – roaima Mar 30 '18 at 20:57
  • Thanks for the explanation. On paper, NetworkManager-dispatcher.service sounds like a better solution than autofs (it avoids pitfalls like that one, for example). Unfortunately, when I tried the script shown in my post, my system would crash frequently. Maybe I need to try to solve that issue rather than switch to autofs. – MountainX Apr 01 '18 at 00:44
  • 1
    Just want to mention that I have the same issues. Laptop with nfs (and cifs) mounts on different networks, the system restarts from suspend only to hang after a while with 100% "phantom" load on all cpus (identified as "other" on the system monitor and no obvious fan noise). What is strange is that this question is the first time I see similar issues for somebody else. – fho Sep 03 '18 at 19:37
  • @fho I'm sure it is a common issue. Like you, I'm baffled that it seems so difficult to find a working solution. I've been searching for years. My current solution is to mount all NFS shares manually using `sudo mount -a -t nfs,nfs4` and to remember to unmount before I undock at the office. Not convenient, but all the automatic solutions I have tried are far worse. – MountainX Sep 03 '18 at 19:56
  • Could it be that it's "something we do"? At home I have a backup solution (borg) that accesses the NAS drive, that gets possibly interrupted by suspending the laptop. At work I have nothing automatically set up that I am aware of, but still suspending sometimes kills the system. – fho Sep 03 '18 at 21:40
  • @fho I am not sure about Borg backup. Suspend and resume work fine for me while connected to NFS shares. For example, if the laptop remains plugged into Ethernet, when it resumes, the shares function 100% normally. – MountainX Sep 03 '18 at 21:58
  • That is suspend and resume in one location is it? That is working fine for me too. Hangs only occur when switching locations. Also it's a very strange "hang" ... everything works normal until it tries to access any filesystem then the program freezes. – fho Sep 04 '18 at 14:49
  • @fho - the behavior you described is expected. What I do now is manually unmount NFS shares before disconnecting from a specific network. I have tried automating that, but all the commonly recommended methods fail to provide satisfactory results, so I do it manually. Whether manual or automatic, the NFS shares much be unmounted before leaving a network or the system will hang as soon as anything tries to access one of the shares. – MountainX Sep 06 '18 at 20:49

0 Answers0