I have a Win10 computer with SMB1 disabled. Before commit https://git.samba.org/?p=samba.git;a=commitdiff_plain;=2726c1a1b0c69d618248b607eca2b0845ddda41d: $ smbclient -L win10 -Uuser%pass -m smb2 ... ... IPC$ IPC IPC remoto print$ Disk Driver della stampante Domain=[WIN10] OS=[] Server=[] Server Comment --------- ------- Workgroup Master --------- ------- $ Looking normal ================================================ After commit https://git.samba.org/?p=samba.git;a=commitdiff_plain;=2726c1a1b0c69d618248b607eca2b0845ddda41d: $ smbclient -L win10 -Uuser%pass -m smb2 ... ... IPC$ IPC IPC remoto print$ Disk Driver della stampante protocol negotiation failed: NT_STATUS_CONNECTION_RESET <======= Now I may think I have a problem, even if I don't NetBIOS over TCP disabled -- no workgroup available $ ========================================================== If the remote computer supports NT1 then everything is OK. ========================================================== Maybe if PROTOCOL_NT1 >= remote_machine_min_protocol then max_proto = MIN(max_protocol, PROTOCOL_NT1); else do as before
This should improve the situation: https://git.samba.org/?p=samba.git;a=commitdiff;h=2726c1a1b0c69d618248b607eca Can you verify that?
(In reply to Stefan Metzmacher from comment #1) Ah, ok, that commit is actually your problem...
(In reply to Stefan Metzmacher from comment #2) Can you check the server logs for any PANIC backtrace message?
(In reply to Stefan Metzmacher from comment #3) In this case the server is Windows 10 with SMB1 disabled, I think by "panic" you meant samba server? The client is smbclient, so nothing is logged in samba logs. The problem is not of functionality, but of confusion in seeing an unexpected new smbclient error: - I run smbclient connecting to Windows 10, telling smbclient to use SMB2 with "-mSMB2" because I know that that particular Win10 is SMB2 only. - before the commit: I'd see clean smbclient output - after the commit: smbclient will show an error because it tries SMB1 against an SMB2/3 only Windows PC; this error could be confusing to users who could think something is wrong, even if everything is actually OK. =========== The reason I'm doing this tests is because I read that by the end of the year is possible that new Windows 10 "clean installs" (not upgrades) will have SMB1 disabled by default, so I wanted to test smbclient interactions with a SMB2/3 only Windows 10. https://www.bit-tech.net/news/bits/2017/06/19/microsoft-disable-smbv1-redstone-3/1/
(In reply to Giulio from comment #4) Can you find the exact commit that changes the behavior? The one you reference only changes the smbd. It might be the commit I referenced: https://git.samba.org/?p=samba.git;a=commitdiff;h=2726c1a1b0c69d618248b607eca I would be good to have tcpdump catures + -d10 output of smbclient for both cases. We hopefully change "client max protocol" to SMB3_11 for the 4.7.0 release in September.
(In reply to Stefan Metzmacher from comment #5) Yes, sorry for the mixup The commit I was referring to is s3:client: smbclient -L can't do workgroup listing over SMB2/3 https://git.samba.org/?p=samba.git;a=commitdiff;h=2726c1a1b0c69d618248b607eca the part with int max_proto = MIN(max_protocol, PROTOCOL_NT1);
(In reply to Giulio from comment #6) Using "server min protocol = SMB2_02" reproduces the bug: # bin/smbclient -L 127.0.0.1 -U% Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.7.0pre1-DEVELOPERBUILD) protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE NetBIOS over TCP disabled -- no workgroup available
(In reply to Stefan Metzmacher from comment #7) I have tried setting "server min protocol = SMB2" on smbd version 4.6.5 & I have observed the same/similar problem. smbclient version 4.6.5 reports the following error protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX smbclient version 4.5.10 reports the following error protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE Using -m SMB2 with smbclient suppresses this error, however I still see Giulio problem on the already released versions of Samba
Maybe https://bugzilla.samba.org/show_bug.cgi?id=12061 is related
(In reply to Stefan Metzmacher from comment #7) I best think we can do is something like this: $ bin/smbclient -L 172.31.9.163 -Uadministrator%A1b2C3d4 Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.6.6-SerNet-Ubuntu-11.trusty) Reconnecting with SMB1 for workgroup listing. protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE Failed to connect with SMB1 -- no workgroup available $ bin/smbclient -L 172.31.9.163 -Uadministrator%A1b2C3d4 --option="clientminprotocol=SMB2_02" Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.6.6-SerNet-Ubuntu-11.trusty) SMB1 disabled -- no workgroup available $ bin/smbclient -L 172.31.9.163 -Uadministrator%A1b2C3d4 --option="disablenetbios=yes" Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.6.6-SerNet-Ubuntu-11.trusty) NetBIOS over TCP disabled -- no workgroup available
Created attachment 13486 [details] git-am cherry-pickx from master.
Comment on attachment 13486 [details] git-am cherry-pickx from master. These also fix bug #12876 and #12881.
Re-assigning to Karolin for inclusion in 4.7.0.
Pushed to autobuild-v4-7-test.
Pushed to v4-7-test. Closing out bug report. Thanks!
Hello, I believe commits related to this issue have actually changed/broken workgroup listing in some Windows servers. Now, workgroup listing fails when trying to reconnect with SMB1. I'll provide smbclient -L -d5 outputs shortly. smbclient commandline tool is still able to successfully connect to the remote share and browse. But third party client program (KIO in this case, using libsmbclient.h) fails with KIO message "File exists" - but I realize this is probably not so valuable for you. That's why I'm posting the debug outputs. I have no libsmbclient insight right now, I'm just suspecting that it prevents connection for this type of samba share or at least changed the API a bit. Note, that I managed to connect to another samba share with KIO just fine - so it depends on the share, too. Downgrading from 4.7.0 to 4.6.7 solved the problem for me.
Created attachment 13655 [details] Connect with version 4.6.7
Created attachment 13656 [details] Connect with version 4.7.0
(In reply to clearmartin from comment #16) Attached logs(both) says that connecting with SMB1 failed. Its just the error message that got changed between 4.6.7 and 4.7.0 in your case.
Understood. So it is probably the usage of libsmbclient inside kio-extras that need to be changed so that connecting to the SMB share start working again with samba version 4.7.0. I was wondering if something else changed regarding the libsmbclient API. Anyway I did notify kio-extras devs in KDE bug report: https://bugs.kde.org/show_bug.cgi?id=369850