Booted the computer today. It announced that it could no longer mount the two SMB volumes. Delving into the system journal found this pearl:
2019-11-14T13:37:28-0700 sma-station14l kernel: CIFS: Attempting to mount //sma-nas-02/pub-data
2019-11-14T13:37:28-0700 sma-station14l kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
2019-11-14T13:37:35-0700 sma-station14l kernel: CIFS VFS: Error connecting to socket. Aborting operation.
2019-11-14T13:37:35-0700 sma-station14l kernel: CIFS VFS: cifs_mount failed w/return code = -2
The volumes are located on a NAS. The computer has been mounting these volumes for at least 5 years now.
I checked the SMB options at the NAS. The max version offered is SMB3, the min version is SMB1. Which, if my math is correct, allows SMB2.1. The implication is stupidity on the host’s part.
I note that SMB was updated a couple of days ago; the NAS has not had a recent update (although one is pending).
Speculating here, but it might be that the mount is being attempted before your network is up. Can you show us your defined morunts in /etc/fstab please? The ‘_netdev’ option may be needed for example. From ‘man mount’…
_netdev
The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount
these filesystems until the network has been enabled on the system).
In addition to that there are systemd options such as ‘x-systemd.after=network-online.target’ that can be used to ensure that a shared file-system is mounted after the specified unit is reached/started etc.
Yes, indeed, the DHCP failure was the problem.
I configured another host to offer the DHCP service. And, Voila!, both NFS and SMB volumes mounted as expected.
