GNOME Bugzilla – Bug 780958
Windows network 'folder is empty' when smb.conf client max protocol set to SMB3
Last modified: 2018-09-21 08:53:21 UTC
Problem: When changing client to use SMB3, Nautilus no longer presents the share; however smbclient still works. Reproduce steps: 1. Fedora Server 25 has samba-4.5.6-0.fc25.x86_64 2. Fedora Workstation 26 has nautilus-3.24.0-1.fc26.x86_64 samba-client-4.6.0-3.fc26.x86_64 3. Connect with Nautilus, yes it works fine. Also connect with smbclient, and it's also fine. Over on the server, smbstatus shows that both Nautilus and smbclient make an NT1 protocol connection. No errors in the journal for either server or client. 4. Edit /etc/samba/smb.conf and add under [global] client max protocol = SMB3 5. Reboot 6. Try to connect with Nautilus, click on Other Locations, double click on Windows Network, I see only a "Folder is Empty" icon. 7. Try to connect with smbclient, still works, and over on the server, smbstatus shows that this is an SMB3_11 protocol connection. 8. Change /etc/samba/smb.conf to comment out the client max protocol line; and reboot. 9. Now it works through Nautilus again. Additional notes: When trying to connect via Nautilus with the client max protocol = SMB3 enabled, the smbstatus over on the server does indicating a connection, even though Nautilus doesn't show the name of the server nor does it bring up a login dialog. Samba version 4.5.6 PID Username Group Machine Protocol Version Encryption Signing ---------------------------------------------------------------------------------------------------------------------------------------- 15018 nobody nobody f26h (ipv4:10.0.0.122:56622) SMB3_11 - - Service pid Machine Connected at Encryption Signing --------------------------------------------------------------------------------------------- IPC$ 15018 f26h Wed Apr 5 06:09:13 PM 2017 MDT - - No locked files journals on both ends contain no error messages.
Thanks for your bug report. It sounds like GVfs bug... I don't know what is wrong, but I think it works if you add also "client min protocol". Does it work for you with that?
'client min protocol' should not matter here because internally libsmb does set both min and max for the supported protocol versions using lp_client_min_protocol() and lp_client_max_protocol() functions -- these take either defaults or values set in smb.conf. The default for 'client min protocol' is CORE, which should just work fine if server supports it -- most servers should support CORE but may advertise signing requirements which really only started after NT1. What if you'd add 'log level = 10' to smb.conf and let nautilus to try again? I hope it does not shut down Samba debug output (goes to stderr by default) and you'll be able to see it in the user's journal.
Created attachment 349379 [details] gvfsd log log level = 10 then try to connect
> f26h.localdomain gvfsd[1689]: Kerberos auth with 'chris@COLOR' (COLOR\chris) to access '10.0.0.3' not possible Are you specifying IP address to connect or there is a name? From the client log it is unclear what was UNC path for connection. Kerberos authentication does not work against raw IP addresses. I guess this is indeed gvfsd bug.
(In reply to Alexander Bokovoy from comment #4) > Are you specifying IP address to connect or there is a name? I don't understand the question. I'm not specifying either an IP address or name. I merely click on "Other locations" and then double click on Windows Network, and then I get "Folder is Empty". When the modifications to /etc/samba/smb.conf are reverted, upon double clicking on Windows Network, I see COLOR which is the workgroup, and then the hostname which is f25s, and then the share which is brick1, and then I get a login dialog.
(In reply to Alexander Bokovoy from comment #4) > > f26h.localdomain gvfsd[1689]: Kerberos auth with 'chris@COLOR' (COLOR\chris) to access '10.0.0.3' not possible > > Are you specifying IP address to connect or there is a name? If I use smbclient to connect (with or without client max protocol = SMB3 change), I'm always using IP.
If you are using IP to connect, you are not using Kerberos. So it looks like gvfsd makes some decisions which are different from the flows implemented by smbclient. For example, clicking on "Other locations" supposedly causes discovery of resources available in your network. This is not working unless you have WINS enabled and servers registering there. When you are using smbclient you are not performing any discovery like that because you have already specified target server. So I think it is actually gvfsd bug in improper use of libsmb, probably in not handling fallbacks between different authentication schemes.
Networking stuff quickly goes over my head. But I know that WINS is not enabled on the Fedora server. It does have avahi enabled, so I'm guessing that 'f25s' is discovered on macOS and Windows via mDNS. I know smbd offers a bunch of services including dns, and I haven't disabled any of them even though I only have a need for file server. But I'm not sure whether Samba's dns service is involved in any of the client side discoveries.
Glib/GIO doesn't have API for Kerberos authentication and GTK+ doesn't have corresponding dialogs. So, kerberos is tried at the first place if user is specified. Then, anonymous is tried in some cases if user is not specified. Finally, user and password are requested if not found in keyring... Authentication handling slightly differs for each case: mounting share, browsing server, or browsing network... "Other locations" should also include results from DNS-SD backend, but what you are describing in the Comment 5 is definitely smbbrowse backend (smb backend is used only for specific share). As far as I know the available shares are simply obtained by smbc_opendir using just smb:// (and server consequently)... There isn't any special handling for SMB3 protocol and obviously SMB3 protocol behaves slightly different if it works without "client max protocol = SMB3".
Alexander, see: do_mount (initialization and connection): https://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackendsmbbrowse.c#n775 auth_callback (smbc_setFunctionAuthDataWithContext): https://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackendsmbbrowse.c#n282 update_cache (used to obtain list of servers/shares): https://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackendsmbbrowse.c#n545 Do you see anything what is wrong with SMB3?
Chris, so "Other Locations" doesn't work to you with SMB3, but you can mount the share if you specify whole URI (smb://server/share), don't you?
(In reply to Ondrej Holy from comment #11) > Chris, so "Other Locations" doesn't work to you with SMB3, but you can mount > the share if you specify whole URI (smb://server/share), don't you? Sorry I missed this. That's correct, if the workstation /etc/samba/smb.conf has 'client max protocol = SMB3' set: Other locations > Windows Network icon > Folder is Empty (i.e. it does not work) Other location > Connect to Server line at the bottom > connection works. And over on the server, smbstatus confirms this is a SMB3_11 connection. So using connect to server is a possible work around for the reported problem.
A related problem (let me know if this should be filed as a separate bug). People are reporting they cannot connect to Windows servers patched for the wannacry exploit, and my understanding is that NT1/SMB1 connections are disallowed. To simulate this on Fedora: Modify server /etc/samba/smb.conf to add server min protocol = SMB2 client /etc/samba/smb.conf is default as installed Other locations > Windows Network icon > I get Folder Empty Other location > Connect to Server > I get a dialog "Unable to access location Failed to mount Windows share: Connection timed out" Modify client /etc/smb.conf to add client max protocol = SMB3 And now Connect to Server works OK. So the gist here is that out of the box, Fedora 26 is probably not going to be able to connect to wannacry patched Windows servers, if it's in fact correct they disallow NT1 protocol and if my simulation of that with 'server min protocol = SMB2' is valid. The user will need to set client max protocol = SMB2 (or SMB3), and then connect via Connect to Server. For context in my testing, I'm using Fedora 25 Server, and Fedora 26 Workstation; that translates into samba-4.5.8-1.fc25.x86_64 samba-client-4.6.3-0.fc26.x86_64
Thanks for the info. I think that those issues are probably relevant but different. However, anyway I am convinced that this is not GVfs bug: "Windows Network" is a shortcut for "smb:///". I think that there isn't pure libsmbclient based equivalent, but it does more or less the same as smbtree. Both stop working if you add "client max protocol = SMB3" in smb.conf. "Windows Network" folder is empty and smbtree output is empty. Similarly for the second problem. "smb://server/share" timed out if you add "server min protocol = SMB2", but also "smbclient //server/share" fails in such case with "protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE". Alexander?
"Windows Network" folder was supposed to show servers broadcasting their status via WINS. It will only work if your domain is using nmbd to run WINS/NetBIOS. If you don't run nmbd and don't have appropriate firewall rules that allow passing packets for nmbd, you'll see nothing there. But when the server is discoverable, a NetServerEnum command is sent to them to pick up details. NetServerEnum is part of MS-RAP protocol which depends on MS-SMB, i.e. only SMB1 protocol. So this should explain why you see an empty output. See MS-BRWS and MS-RAP specs. It looks like enumerating servers is a feature no more. If you do not specify explicitly in smb.conf, 'client max protocol' is set to 'default' which is NT1, and there is nothing that can override it other than explicitly set it in smb.conf. So I think this is a part that needs to be discussed on samba-technical@ and changed to SMB3.
I started the discussion on samba-technical@ about the 'client max protocol' change. You can follow it there or through the mailing list archive: https://lists.samba.org/archive/samba-technical/2017-May/120768.html
Alexander, thanks for the explanation and the discussion on samba-technical! So, this is a problem on samba side, however, letting the bug opened for now in order to solve what to do with "Windows Network" folder...
Today Samba 4.7.0rc1 was released. It includes changes that allow libsmbclient-based code to use up to SMB 3.11 dialect when negotiating with a server. This should make it possible to have a server with SMB1 disabled. We are planning to build Samba 4.7.0rc1 for Rawhide in next few days and possibly provide COPR repo for f26/f25. Note that Samba 4.7.0 will require an upgrade of libldb and associated libraries, so it may be not an easy test in the existing environment.
See patches forcing SMB1 to be negotiated using functions from private headers: https://bugzilla.redhat.com/show_bug.cgi?id=1513394
It should be fixed in samba 4.8.0 as per https://bugzilla.redhat.com/show_bug.cgi?id=1513394#c10.
The following should fix this (with recent enough samba): https://gitlab.gnome.org/GNOME/gvfs/merge_requests/12