Recently after I suspend my Tumbleweed machine and then resume from suspend, my NAS NFS is no longer mounted. Here is the fstab entry:
DiskStation:/volume1 /mnt/DiskStation nfs defaults 0 0
When I issue the mount command, the only difference between the output of pre-suspend and post-resume is this one line:
DiskStation:/volume1 on /mnt/DiskStation type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.43,local_lock=none,addr=192.168.1.112)
‘sudo mount -a’ fixes the issue.
Where can I look for clues as to what is happening? I have done a ‘zypper dup’ and am at the 2018-12-05 release.
As I searched for answers on what might be going wrong, I came across advice given to somebody with a similar issue, and that was to use autofs.
Looking into autofs here is what my /etc/auto.master looks like:
Initially that worked, but the issue is that after a suspend/resume the nfs directories do not get mounted until I issue another
restart autofs command.
Does that shed any more light on what might be going on?
Another important point that I wanted to make here is to ensure that your network filesystems are unmounted before you suspend the client machine. If you suspend while a network filesystem is still mounted and then resume when the remote system isn’t reachable (eg network connectivity not up yet), then you will encounter issues like you describe.
Hi deano_ferrari. Thanks for the reply. ‘cd /mnt/DiskStation;ls’ after a suspend and resume does not list anything. After a mount command though, the same ‘cd /mnt/DiskStation;ls’ shows the proper directories.
This is a NAS and always available (unless something has changed). And this is not a new installation. I’ve been running openSUSE (Leap and Tumbleweed) with this exact combination for many years. This development with the mounts not showing up is new though. I had never had to unmount before suspend and remount after resume prior to this.
Thinking about what you said about “suspend while a network filesystem is still mounted and then resume when the remote system isn’t reachable (eg network connectivity not up yet)” makes me wonder though if some timing has changed in the process of network coming up on the client.
I got some advice about switching to systemd automount. I’ll see if that makes a difference.
I would look at shortening the timeout value so that the network share is unmounted after a lesser period of inactivity, and so more likely unmounted before a suspend is invoked. You may find 120 seconds is probably more than sufficient for your needs.
Following Per Jessen’s suggestion for using systemd automount worked perfectly. As soon as I hit the power button to come out of suspend, I could hear the NAS disk start to spin up and the directories were mounted as expected.
Well, unfortunately that did not last long. Basically, after a reboot, things behave as expected, but after 2 or more suspend/resumes, the NFS no longer mounts automatically after the resume.
Looking at the /var/log/messages I came across this:
**Failing Case**
2018-12-24T08:38:20.981130-08:00 OptiPlex9020 systemd[1]: Started Network Manager Script Dispatcher Service.
2018-12-24T08:38:20.983929-08:00 OptiPlex9020 chronyd[1068]: Forward time jump detected!
2018-12-24T08:38:20.983989-08:00 OptiPlex9020 chronyd[1068]: Can't synchronise: no selectable sources
2018-12-24T08:38:20.984021-08:00 OptiPlex9020 chronyd[1068]: Source 45.127.112.2 offline
2018-12-24T08:38:20.984049-08:00 OptiPlex9020 chronyd[1068]: Source 74.82.59.150 offline
2018-12-24T08:38:20.984077-08:00 OptiPlex9020 chronyd[1068]: Source 204.11.201.12 offline
2018-12-24T08:38:20.984104-08:00 OptiPlex9020 chronyd[1068]: Source 173.51.147.14 offline
2018-12-24T08:38:21.203889-08:00 OptiPlex9020 kernel: [31589.504434] IPv6: ADDRCONF(NETDEV_UP): em1: link is not ready
**2018-12-24T08:38:21.218507-08:00 OptiPlex9020 systemd[1]: mnt-DiskStation.automount: Got invalid poll event 16 on pipe (fd=67)**
**2018-12-24T08:38:21.218583-08:00 OptiPlex9020 systemd[1]: mnt-DiskStation.automount: Failed with result 'resources'.**
2018-12-24T08:38:21.228127-08:00 OptiPlex9020 dbus-daemon[1029]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Those two BOLDED lines are not present in the messages file when NFS does automatically get mounted:
**Passing Case**
2018-12-22T11:31:31.127923-08:00 OptiPlex9020 systemd[1]: Started Network Manager Script Dispatcher Service.
2018-12-22T11:31:31.131072-08:00 OptiPlex9020 chronyd[1097]: Forward time jump detected!
2018-12-22T11:31:31.131147-08:00 OptiPlex9020 chronyd[1097]: Can't synchronise: no selectable sources
2018-12-22T11:31:31.131197-08:00 OptiPlex9020 chronyd[1097]: Source 173.230.144.109 offline
2018-12-22T11:31:31.131254-08:00 OptiPlex9020 chronyd[1097]: Source 199.102.46.79 offline
2018-12-22T11:31:31.131309-08:00 OptiPlex9020 chronyd[1097]: Source 208.75.89.4 offline
2018-12-22T11:31:31.131362-08:00 OptiPlex9020 chronyd[1097]: Source 199.102.46.76 offline
2018-12-22T11:31:31.345628-08:00 OptiPlex9020 kernel: 7288.679520] IPv6: ADDRCONF(NETDEV_UP): em1: link is not ready
2018-12-22T11:31:31.379229-08:00 OptiPlex9020 dbus-daemon[1007]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Was there any resolution to this?
I have recently built a workstation (opensuse TW) as a frontend to a mediaserver.
I have the a similar fstab entry, which works for my Fedora workstations, connecting to the same media server.
When the system resumes from suspend, the nfs shares are not connected.
When the system resumes from suspend, the nfs shares are the only missing shares.
I have better results just from appending x-systemd.automount to the mount options.
It isn’t obvious whether x-systemd.requires=network-online.target will properly replace the _netdev option, but I will later see what affect it has on boot, shutdown, and resume.
Well, the resolution for me was that the issue disappeared as mysteriously as it appeared. I did some more experiments. I ended up with an fstab entry like this:
The reason I added the nfsvers option was that when did a mount -a -v it showed that mount was negotiating down from 4.2 and finally settling on 4.0. But that did not make a difference. nfs mount still would not mount after resume. I even did a re-install of the latest Tumbleweed. But after some while I noticed that the problem had gone away. I decided to leave well enough alone and never went back to the old fstab entry.
