Sometime ago I had made Samba shares visible to Windows 7 (and 10) clients by enabling "SMB1.0/CIFS File Sharing Support" in Windows Features (part of "Programs and Features" in the Control Panel).
I recently noticed that the shares were no longer being seen by Windows Explorer. Accessing by share name still worked fine.
It turns out that Windows 10 (probably from the Fall Edition - 1709) no longer supports SMBv1. Windows 10 uses Web Services for Windows (WSD) to discover shares. Samba does not support this; in fact has no intention of supporting it.
There is a deamon for Linux that supports WSD, but that would require a port to FreeBSD. I don't care that much.
I disabled SMBv1 on all the Windows 10 machines. Everything still
worked, but... Sometimes a share was inaccessible, producing the
error code 0x800704cf. After retrying a few times it
was accessible and worked ok.
The change that fixed this for me involved de-selecting "Client for Microsoft Networks" on the network interface properties screen. That's non-intuitive.
There was one odd consequence of this change and this oddness only occured on an X1 Carbon Thinkpad, which has a Microsoft account/Windows Hello login. If emacs was first used to access a file on a share, Windows prompted for username and login, claiming the user name or password word were incorrect. The share server credentials were correct in the Credential Manager. Even odder, if the first share file access was from a Microsoft program (e.g. Notepad), then a connect from Emacs worked instantly; no prompt for credentials.
For reasons unknown, Emacs causes Windows to use the Windows Hello credentials, not those held in the Credential Manager. So, the fix was:
/usr/local/etc/smbusers as an alias of my server user
name.
