Mounting SMB is now sporadic

English Network/Internet
#1

(A continuation of thread https://forums.opensuse.org/showthread.php/538205-Can-no-longer-mount-SMB-volumes)

There was a system update on 2019-11-09 which included a lot of samba updates. Since then, mounting two SMB volumes at boot time is hit or miss, about 50/50 chance, that one or both volumes do not mount. If the mount fails, it will never succeed until, maybe, during a reboot.

The SMB volumes had mounted reliably for years.

Here’s what I know.
Without the version option:

$ sudo mount /t-smb
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Journal:

2019-11-16T14:20:03-0700 sma-station14l kernel: CIFS: Attempting to mount //sma-nas-02/pub-data
2019-11-16T14:20:03-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-16T14:20:10-0700 sma-station14l kernel: CIFS VFS: Error connecting to socket. Aborting operation.
2019-11-16T14:20:10-0700 sma-station14l kernel: CIFS VFS: cifs_mount failed w/return code = -2

I tried adding “-o vers=X.0” to the mount command, where X = 1, 2, or 3. Same result for all versions.

$ sudo mount /t-smb -o vers=2.0
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

In the system journal:

2019-11-16T14:17:49-0700 sma-station14l kernel: CIFS: Attempting to mount //sma-nas-02/pub-data
2019-11-16T14:17:55-0700 sma-station14l kernel: CIFS VFS: Error connecting to socket. Aborting operation.
2019-11-16T14:17:55-0700 sma-station14l kernel: CIFS VFS: cifs_mount failed w/return code = -2

In /etc/fstab:

//sma-nas-02/pub-data /t-smb  cifs   credentials=/home/jmoe/.smb/.smbpw,uid=sma-user4,gid=users,file_mode=0664,dir_mode=0775,noserverino,noperm  0  0
//sma-nas-02/graphics  /w-smb  cifs   credentials=/home/jmoe/.smb/.smbpw,uid=sma-user4,gid=users,file_mode=0664,dir_mode=0775,noserverino,noperm  0  0
#2

In the case where you get the mount failure(s), does it succeed consistently if you mount manually (after boot)?

#3

No.
The excerpts in the OP are all from manual attempts to mount the volumes. When it decides to fail, it always fails.

#4

Another observation: The NAS path defined in /etc/fstab is using a host name ‘//sma-nas-02/…’ which will require some kind of reliable name resolution mechanism at boot. Are you using local DNS for name resolution? It would be interesting to substitute the actual NAS IP address instead, or add the requisite mapping entries in /etc/hosts perhaps as a test. If the NAS supports mDNS, you could also try using ‘//sma-nas-02.local/…’ to see whether that is more reliable.

#5

There was a system update on 2019-11-09 which included a lot of samba updates. Since then, mounting two SMB volumes at boot time is hit or miss, about 50/50 chance, that one or both volumes do not mount. If the mount fails, it will never succeed until, maybe, during a reboot.

I see no such recent samba related updates for openSUSE Leap 15.1

rpm -qa --last|head -n100|grep samba
#6

None of your suggestions made any difference. As noted, once it has failed at boot, it is done.

It was 2019-11-08:

$ sudo rpm -qa --last|head -n100|grep samba
libsamba-policy0-python3-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:41 MST
samba-winbind-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:39 MST
samba-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:36 MST
samba-client-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:35 MST
samba-winbind-32bit-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:33 MST
samba-libs-python3-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:31 MST
samba-client-32bit-4.9.5+git.210.ab0549acb05-lp151.2.9.1.x86_64 2019-11-08T06:44:31 MST
#7

Ok, let’s see what others come up with here. A bug report may be needed.

#8

One more thing…returning to the opening post

CIFS VFS: cifs_mount failed w/return code = -2

From ‘man mount’, the following is mentioned. I’m not sure what this means in the context of the samba mounts though…

RETURN CODES
mount has the following return codes (the bits can be ORed):

   0      success

   1      incorrect invocation or permissions

   2      system error (out of memory, cannot fork, no more loop devices)

   4      internal mount bug

   8      user interrupt

   16     problems writing or locking /etc/mtab

   32     mount failure

   64     some mount succeeded

   The command mount -a returns 0 (all succeeded), 32 (all failed), or 64 (some failed, some succeeded).
#9

This is kernel log, error is -ENOENT which is what already has been spelled out (“No such file or directory”). You need to follow kernel code to find out when it returns this error. But if it worked before update and stopped working after update without any other changes in environment then bug report is needed.

#10

This may be related to the DHCP issue I just discovered.

#11

I had wondered about that, but strange that you report the problem persists when you try manually mounting. Do you have networking issues at that time?

#12

Yes, indeed, the DHCP failure was the cause of this issue.
I configured another host to offer DHCP and, Voila! volume mounts started working as expected.

#13

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.

The DHCP thread: https://forums.opensuse.org/showthread.php/538232-Now-DHCP-has-decided-to-quit

#14

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.

The DHCP thread: https://forums.opensuse.org/showthread.php/538232-Now-DHCP-has-decided-to-quit