When setting the min/max client protocol version via smb.conf to: --- client min protocol = SMB2 client max protocol = SMB3 --- then server/share discovery (i.e. opening the directory "smb://") with libsmbclient fails. This is reproducible both with Samba's own code as well as in my own code using the library. Steps to reproduce: (1) set the min/max client protocol version as above in smb.conf (2) run "smbtree", or the example application from the Samba sources in examples/libsmbclient/testbrowse2.c (3) no servers/shares are found Some additional information: * The fileserver is running Samba 4.5 on FreeBSD, and has its max protocol set to SMB3, so it's not an issue of an SMB1-only server * I can connect to a share on the server using "smbclient" just fine, even with the above smb.conf settings. Wireshark confirms it's using SMB2 then. (But since I supply the path to the share manually to smbclient, there's no server discovery involved.) If needed, I can also provide log files of the test case with SMBCTX debug level raised, or provide a packet capture of a failed attempt.
Let's see if we can fix this before 4.7.0
I was under the impression that the "servers list" (ie network discovery) is not available with SMB2/SMB3, therefore the behavior is normal? For this very reason smbclient has been modified to force NT1/SMB1 when doing "-L": https://git.samba.org/?p=samba.git;a=commitdiff;h=2726c1a1b0c69d618248b607eca this has its own problems if the remote server has SMB1 disabled (https://bugzilla.samba.org/show_bug.cgi?id=12863). ======================== I'm testing with smbclient-4.7rc1: - smbclient defaults to max protocol smb3 - smbclient -L -> automatically forces downgrade to NT1 and I see server list if remote server/master browser supports NT1 - If I use "client min protocol = SMB2", then smbclient -L gives protocol negotiation failed: NT_STATUS_INVALID_PARAMETER I think this is due to the forcing downgrade to NT1. ======================= Both for smbclient and libsmbclient, I think we should first understand what is the expected behavior for getting the servers list when using SMB2/SMB3: - when the remote server/master-browser supports SMB1, and when not. - when the "client min protocol" is set to SMB2/SMB3, and when not ======================= As far as I know, if you disable SMB1 on Windows 10, then Windows 10 will completely disable netbios discovery (ie: no downgrade to browse network, no more "computer browser" service), and will do discovery with LLMNR/WSD only. https://bugzilla.samba.org/show_bug.cgi?id=11473 Ie: windows 10 with SMB1 disabled won't see Samba on the network neighborhood (computers list).
Can anyone confirm or deny this? That share browsing is generally not available for protocol reasons when min client protocol >= SMB2?
Correction, I mean share listing, not browsing.
SMBC_opendir_ctx() doesn't seem to support SMB2/3 as it uses cli_NetServerEnum() Jeremy, do you see any way to get SMBC_opendir_ctx() working with SMB2/3? Otherwise this might be a show stopper for "client max protocol = SMB3" :-( smbtree can be fixed by forcing SMB1 as a first step.
(In reply to julian.harnath from comment #4) Share listing is supported over DCERPC (which can use any SMB versions)
Can't we change SMBC_opendir_ctx() to call mDNS browsing (as in do_smb_browse()) instead of cli_NetServerEnum() ? Not an immediate fix, but doable I think.
(In reply to Jeremy Allison from comment #7) git grep -i dnssd doesn't find any configure check. Which system library supports this? I'm not sure that relying on the presence of such a library at build time is a good thing, and I guess not much servers support this anyway. I guess LLMNR would be needed...
DNSSD is an Apple invention (I think Macs still use it - they call it Bonjour I think). http://www.dns-sd.org/ We used to support this in the client. Looks like Windows 10 added support for it: https://channel9.msdn.com/Events/Build/2015/3-79 https://ctrl.blog/entry/windows-mdns-dnssd Maybe we should resurrect it ?
(In reply to Jeremy Allison from comment #9) Maybe, but I guess this is nothing we can rush into 4.7. I guess we should have a section that smb:// only works with "client max protocol = NT1" to WHATSNEW.txt and may fix this completely later. What do you think?
Yes, this won't make 4.7.0 I think. Also, reading my previous comment links more carefully it looks like there are still bugs in the MS implementation of bonjour anyway :-(.
With the changes of bug #12863 this is no longer blocking 4.7.0
Is this bug open or resolved ?
(In reply to Harsh Shukla from comment #13) It's open