3

I have two devices: a laptop with Ubuntu 20.04, and a Raspberry Pi 4 with Raspberry Pi OS.

Both of these have an identical version of nfs-kernel-server and setup on them.

Both of of these share some of their directories with the other machine, sometimes simultaneously, via the NFS4 protocol.

Due to clumsiness, I quite often manage to interrupt these connections:

  • I often shut the Raspberry down, while forgetting to unmount its share on the laptop
  • my laptop either goes to sleep, or I log out / reboot, while the Raspberry is accessing its shares

In any case, neither machine in the role of client take these disruptions too well; attempts to unmount after-the-fact do not go well (endless waiting without any results), and other things can get impacted too: my Ubuntu sometimes starts to complain that no application is associated with opening .txt files (!)

Question:

How can I somehow reset these interrupted NFS connections on the clients (without rebooting)? 1.) To ease the unmounting 2.) To allow for a clean slate start for re-mounting.

Details:

nfs-common version on both machines: 1.3.4-2.5

All these mounts are initiated manually (by running a script, on demand); none of them are in /etc/fstab. I have not supplied any options with the mount command whatsoever; it's as plain as:

sudo mount IP:/share /mountpoint
Levente
  • 3,961
  • I have found this: https://unix.stackexchange.com/q/177039/448600 and this: https://www.suse.com/support/kb/doc/?id=000019722 Pretty much looks like I need to get more disciplined around my NFS connections :( At the same time it's extremely interesting that there's no feature in NFS to deal with this. – Levente Apr 02 '21 at 17:25
  • You need to specify the two options soft,bg and probably the third option timeo – Raffa Apr 02 '21 at 19:38
  • @Raffa It's not in fstab, rather I use the mount command on demand; and I don't see these options in man mount: http://manpages.ubuntu.com/manpages/bionic/man8/mount.8.html – Levente Apr 02 '21 at 19:50
  • It is in man mount... look for -t or fstype. The options themselves are in man nfs... so basically you would use something like sudo mount -t nfs -o soft,bg,timeo=30 IP:/share /mountpoint – Raffa Apr 02 '21 at 20:36
  • @Raffa I used your command with the modification of -t nfs4 and -v. I made the client the Raspberry. Mounted my laptop's share. Set up a slideshow of images from the laptop's share. Then I sent the laptop to sleep. Slideshow app on Raspberry froze. umount -v says:"nfs4 mount point detected", and then: "umounted". Subsequent umount -v says "not mounted". But in the graphical file manager, the mount point keeps showing as "inode/x-corrupted type". Subsequent mount -v attempts return just one line about "trying", then exit. The mount point remains as corrupted inode. – Levente Apr 02 '21 at 21:09
  • Rebooting the Raspberry restores the mount point as healthy directory and mounting the laptop's share works again. – Levente Apr 02 '21 at 21:11
  • That is expected as nfs shares are complicated. Many factors are involved even DNS sometimes... There is nothing wrong withe using the frowned upon umount -f in this case as it might be the only way to refresh the state of the nfs share. It is helpful in case of an unreachable NFS system. – Raffa Apr 02 '21 at 21:44
  • Does umount -f do something extra, even after a regular umount aready reports "not mounted"? – Levente Apr 02 '21 at 21:46
  • Yes, "It is helpful in case of an unreachable NFS system" this is also stated in man umount specifically under the option -f... here... It refreshes the nfs mount state – Raffa Apr 02 '21 at 21:49
  • @Raffa I did it with umount -f -v, and it worked! It said again, "nfs4 mount point detected", and then: "umounted". The graphical file manager kept showing the mount point as corrupted inode, so I closed the window, then reopened a new one, in which the mount point appears again as a healthy directory. Subsequently I could mount the share on it again. Do you want to add an answer? It could offer a solution that is ahead of several other resources. – Levente Apr 02 '21 at 23:34
  • With pleasure... answer on the way... one moment please. The most important thing is your nfs share is tamed now :) and as you mentioned, the solution for this issue is not easily available. So indeed it is worth an answer. – Raffa Apr 02 '21 at 23:49

1 Answers1

5

  • You need to use the options soft, bg, and probably timeo like so:

    sudo mount -t nfs -o soft,bg,timeo=30 IP:/share /mountpoint

    Please see man nfs for information and usage.

  • When the connection to the NFS share is interrupted, refresh the mount-point with umount -f like so:

    sudo umount -f /mountpoint

    Then mount the NFS share again with the same options above.

    Please see man umount for information and usage.

Raffa
  • 32,237
  • 1
    This worked; using the suggested mount options, after umount -f I could re-mount the share. Thank you! – Levente Apr 03 '21 at 00:05