This happens since two different 20191027 dups, 64bit and 32 bit. Is this a bug? Is there a way to get it back, or a replacement, or equivalent? Is it related to SMB1 disabled by default or lanman/plaintext auth deprecation?
On a would-be client, this results:
# smbtree -N
MYGROUP
\\<server> <clhost> openSUSE TW Samba 4.11.2-git.99.f93cc798f2 smbXcli_negprot_smb1_done: No compatible protocol selected by server.
:(Hi
I think it’s all related to the deprecation, maybe this will help;
https://forums.opensuse.org/showthread.php/538028-dolphin-cannot-access-to-smb-server-192-168-204-86?p=2919426#post2919426
Maybe the protocol needs to be SMB2, SMB2_02 etc…
I’m pretty certain of that. 
Maybe the protocol needs to be SMB2, SMB2_02 etc…
As of TW20191107, adding ‘client min protocol = SMB1’ to [global] results in smb and nmb failing to start. Adding instead ‘client min protocol = NT1’ helps in no apparent way.
I don’t use NAS. I rarely use Windows. My need for Samba is foremost for connecting to OS/2, secondarily to Linux-based satellite receivers expecting to be on Windows networks. Most network traffic here is NFS, which I never figured out how to utilize with OS/2.
Hi
The only way I’ve managed to figure it out across different releases is via smbclient and debug. Maybe you need additional client options aside from the protocol? For OS/2 isn’t that netbios related?
The sheer age of OS/2 likely means that the “ancient” NetBIOS API is being used and relying on the “ye olde” SMBv1 protocol to achieve this. (Samba still supports this protocol for now, but it is likely to be removed completely as a supported protocol in the near future.)