Bug 1513394
Summary: | Applications using gvfs are unable to browse SMB shares | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tomas Kovar <tomas> | ||||||
Component: | samba | Assignee: | Guenther Deschner <gdeschner> | ||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 29 | CC: | abokovoy, al.dunsmuir, alexl, anoopcs, asn, damianatorrpm, gdeschner, jarrpa, jman012345, johannespfau, jonathan.underwood, kevin.vanhooren, lmohanty, madam, massi.ergosum, nate, oholy, ralph, rich, sbose, ssorce, tomas | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2019-11-27 22:28:47 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Tomas Kovar
2017-11-15 10:32:07 UTC
Thanks for your bug report. 4. OK if 5. is empty 5. it should work if smbtree works, I will do some tests... 6. but let's start from the tail... You have to mount it first: gio mount smb://workgroup gio list smb://workgroup Does it work after mounting? If not, does smbclient -L //workgroup/ work? ad 4. 5. is not supposed to be empty :/ ad 6. "gio mount smb://workgroup" doesn't work: gio: smb://workgroup/: Failed to retrieve share list from server: Success "gio mount smb://server" works, after mounting "gio list smb://server" lists the shares. (Interestingly, "gio mount -u smb://server" fails: gio: smb://server/: Could not find enclosing mount.) smbclient -L //workgroup/ also doesn't work: Connection to workgroup failed (Error NT_STATUS_UNSUCCESSFUL) More info with -d4: no entry for workgroup#20 found. wins_srv_is_dead: <WINS.IP.ADDRESS> is alive resolve_wins: using WINS server <WINS.IP.ADDRESS> and tag '*' nmb packet from <WINS.IP.ADDRESS>(35072) header: id=17968 opcode=Query(0) response=Yes header: flags: bcast=No rec_avail=Yes rec_des=Yes trunc=No auth=Yes header: rcode=3 qdcount=0 ancount=1 nscount=0 arcount=0 answers: nmb_name=WORKGROUP<20> rr_type=10 rr_class=1 ttl=0 Negative name query response, rcode 0x03: The name requested does not exist. resolve_lmhosts: Attempting lmhosts lookup for name workgroup<0x20> getlmhostsent: lmhost entry: 127.0.0.1 localhost resolve_hosts: Attempting host lookup for name workgroup<0x20> resolve_hosts: getaddrinfo failed for name workgroup [Name or service not known] name_resolve_bcast: Attempting broadcast lookup for name workgroup<0x20> Connection to workgroup failed (Error NT_STATUS_UNSUCCESSFUL) And it is right, there's no such name for fileserver (<0x20>), only name for master browser (<0x1d>). smbclient -L //server does work, and it asks for the password first: Enter WORKGROUP\users's password: Sharename Type Comment --------- ---- ------- share Disk Reconnecting with SMB1 for workgroup listing. Server Comment --------- ------- Workgroup Master --------- ------- WORKGROUP SERVER Sorry, "smbclient -L //workgroup/" is probably not expected to work. But smbtree works for me also, so I suppose that 5. and 6. should work consequently, however they don't work with older gvfs versions also, so I suppose that something changed on samba side in F27. Some observations with GVFS_DEBUG=1: Ad 5. - smbc_opendir_fn for smb:// works correctly, but smbc_getdents_fn return 0 results. However I see the following activity for our smbc_add_cached_srv_fn/smbc_get_cached_srv_fn: smb-network: adding cached server '192.168.100.1'\'IPC$', user 'WORKGROUP';'oholy' with data 0x7f7224016270 ... smb-network: looking up cached server '192.168.100.1'\'IPC$', user 'WORKGROUP';'oholy' smb-network: returning 0x7f551801d2e0 So samba obviously knows about that available server, but doesn't return it for some reason... Ad 6. - smbc_opendir_fn for smb://workgroup/ returns NULL, but errno is not set and I see: smb-network: do_mount - [smb://workgroup; 0] dir = (nil), cancelled = 0, errno = [0] 'Success' But I suppose that is should return valid SMBCFILE *, or set errno appropriately. Let's try to move it in samba component... Created attachment 1400829 [details] Force SMB1 in gvfsbackendsmbbrowse It is related to change in samba, indeed. It is caused by changes described in the section of "'smbclient' changes", specifically: The default for "client max protocol" has changed to "SMB3_11", The NetBIOS-based browsing is a SMB1-only functionality, it is not supported by SMB2+. When connecting to a server that does support SMB2+, the client will negotiate to use higher versions, which have as a result that browsing (and some other extensions, like the unix extensions) won't work. There is a reason for obsoleting SMB1[0]. For utilities shipped with samba, there is the -m switch, that can force specific version. The attached patch does something similar for gvfsbackendsmbbrowse - it forces it to use SMB1, so it works at all. It does that somewhat forcibly, though. Libsmbclient does not provide any API to do that. The way the samba utilities do that is to use API, that has headers available only during samba build, but not in the devel packages. Here I declare the needed function prototype myself and just link to libsmbconf. (Libsmbclient does read user and global smb.conf; hovewer it can't do that depending on context; we want SMB1 only for browsing, not for all trafic). With this patch, the browsing works, just like it did in Fedora 26. The proper long-term solution would be a new browsing backend, based on WS-Discovery; that's what Microsoft is doing in Windows 2016/Windows 10. (And of course, WS-Discovery based publishing on samba side would be needed too). [0] https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/ Created attachment 1400830 [details]
Changes to spec file for building
Patch to spec file for building with forced SMB1.
Thanks for debugging and patches. It would be nice to force gvfsd-smb-browse to use SMB1, but I am not really sure that it is wise to use functions from private headers :-( It seems that samba upstream already fixed this issue for their cmd tools by forcing SMB1. Can you please ask them to add some helper for this into the official API? Probably a good place to start: https://bugzilla.samba.org/show_bug.cgi?id=12876 Alexander, don't you have any comments to this? If you just need to enumerate existing shares, I think you are better to use libnetapi than what is available in the current libsmbclient public API. See source3/lib/netapi/examples/share/share_enum.c as an example. https://github.com/samba-team/samba/blob/master/source3/lib/netapi/examples/share/share_enum.c libnetapi is available as part of samba-client-libs and headers are part of samba-devel. Ondrej: I agree, it's an ugly hack. I consider it a proof of concept, of what is needed to be done, not anything production-worthy. Alexander: It is about workgroup and host discovery (Other locations in Nautilus, Network in macOS Finder or Network Neighborhood in Windows Explorer), not about enumerating shares. To enumerate shares, you already have to know to which host you are going to connect. This is fixed upstream and will be released in 4.8.0 In libsmbclient, we end up going to get_ipc_connect() (https://github.com/samba-team/samba/blob/master/source3/libsmb/cliconnect.c#L3728) and it enforces SMB1 when talking to IPC$ shares already. The fix is available with https://bugzilla.samba.org/show_bug.cgi?id=12876 but it didn't get to 4.7.x at the time and was never backported: $ git tag --contains 0f9d10246071160dc736205af234ab0ca456d0dc |grep samba samba-4.8.0rc1 samba-4.8.0rc2 samba-4.8.0rc3 The forcing of SMB1 in get_ipc_connect() was released also since 4.7.0rc5, cherrypicked as dcdeb33aaa81561ddaf684aa30fb3b4b441096e6. That doesn't seem to work, though, and more debugging will be needed. I will have a look at it, as time permits. *** Bug 1557860 has been marked as a duplicate of this bug. *** This really would be nice to fix in released Fedora 27, as it's a pretty big regression from Fedora 26. Why not push builds with Thomas' patch for Fedora 27, since that's unlikely to get updated to Samba 4.8.0 ? Actually, it seems that the patch is not necessary. All that's needed is to add this to smb.conf: server max protocol = NT1 And restart the server. This forces the samba server to use the old protocol. This should probably be in the default config file supplied in the samba RPM for F27, so as to avoid regression from F26. That forces the use of the old SMB1 protocol for actually connecting as well though--not just browsing. What's really needed here is to use a modern, supported method of browsing, such as Avahi/Bonjour, or WS-Discovery. Going back to SMB1 for discovery will work less well over time as Microsoft disables it for more and more versions of Windows. Windows Server 2016 already doesn't support SMB1, and Windows 10 only supports SMB1 if you turn it on within the first 15 days (otherwise it deletes itself). Using SMB1 for browsing is not a bad workaround for now, but it's not going to be workable over the long term. What fix does Samba 4.8.0 supposedly have? The workaround to use SMB1 for discovery? Do we know that it actually works? For the record, it doesn't work in Fedora 28 and Samba 4.8 either. While I agree with Nate, that a switch to newer/safer protocols is needed, both Avahi/Bonjour and WS-Discovery are missing a feature, that SMB1 has: they both work only in the broadcast domain. For example, with SMB1 you can get a browse list when you use a VPN, with Avahi/Bonjour and WS-Discovery, you won't. Maybe it would be possible to make it work with DNS-based Avahi, at least for Linux clients (not sure how Mac OS clients would react to that, and we all know how Windows clients would react). Technical nitpick: you don't have to turn on SMB1 in Windows 10. It is on by default. You have to use it within the first 15 days (where "use" means: connect your computer to a network where SMB1 browsing is used), and then it will keep installed. Similarly, it is still on by default in Windows 2016, just disable-able. I've just tested it with Dolphin from KDE and I can list the shares of a Windows Server 2016. I've even set 'client min protocol = SMB3' to only use the SMB3 protocol. I have Samba 4.8.4 currently installed. My guess would be that gvfs is doing something wrong. I've just tested it with up-to-date Fedora 28 (samba-4.8.5-0.fc28.x86_64) and I still see the issue. Just a note that this issue is about smb://workgroup and "client max protocol = SMB3". smb://server works properly. client max protocol = NT1 ========================= $ smbtree WORKGROUP \\T450S Samba 4.7.9 \\T450S\IPC$ IPC Service (Samba 4.7.9) \\T450S\oholy-public \\T450S\oholy-private $ kioclient 'ls' 'smb://WORKGROUP/' T450s (Samba 4.7.9) $ gio list smb://WORKGROUP/ T450S Everything works properly. client max protocol = SMB3 ========================== $ smbtree WORKGROUP \\T450S Samba 4.7.9 \\T450S\IPC$ IPC Service (Samba 4.7.9) \\T450S\oholy-public \\T450S\oholy-private $ gio list smb://WORKGROUP/ $ kioclient 'ls' 'smb://WORKGROUP/' Only smbtree works properly in this case, because it internally forces NT1, which is not possible over libsmbclient, so gio/kio doesn't work. client min protocol = SMB3 ========================== $ smbtree $ gio list smb://WORKGROUP/ $ kioclient 'ls' 'smb://WORKGROUP/' I suppose that this is expected, because NT1 is needed for it. There is no workgroup support with SMB3! smb://WORKGROUP is a SMB1 only feature!!! I see that there is no workgroup support with SMB3, but smbtree works with "client max protocol = SMB3" if the server doesn't disable NT1, because it internally forces NT1 and we would like to achieve the same for gvfs, but libsmbclient doesn't provide API to choose protocol version... I've merged the following upstream fix, which uses newly added smbc_setOptionProtocols() API: https://gitlab.gnome.org/GNOME/gvfs/merge_requests/12 I can backport it in older Fedoras if the new API will be backported in libsmbclient also. I can confirm the issue on Fedora 27. Funny that the a 10 year old distro (in VM Xandros 3) did correctly see it in konqueror. smbtree works fine. Only gvfs is affected? Not fixed in Fedora 29. Setting server max protocol = NT1 does not fix issue. You need to be sure that NT1 is used, so setting "server max protocol = NT1" only is not enough. Because if I recall correctly, the default value for "client min protocol" has been changed in samba to "SMB3_11". So you need to change this back on client manually to "client min protocol = NT1"... (In reply to Ondrej Holy from comment #24) > You need to be sure that NT1 is used, so setting "server max protocol = NT1" > only is not enough. Because if I recall correctly, the default value for > "client min protocol" has been changed in samba to "SMB3_11". So you need > to change this back on client manually to "client min protocol = NT1"... I have included both settings client max protocol = NT1 server min protocol = NT1 SELinux and firewall both disabled. Still can not see Windows 7 nor Windows 10 machines on the network in Nautilus. I only see my other Linux machines. My Centos 7 and my Fedora 26 both can browse the Windows network. Setting NT1 is not a solution. Nautilus as does smbtree both show the local SMB machines with these settings but fails seeing any of the Windows machines. This continues to be a serious problem with the integration of Fedora into a mixed network. (In reply to Rich from comment #25) > > I have included both settings > client max protocol = NT1 > server min protocol = NT1 > SELinux and firewall both disabled. > Still can not see Windows 7 nor Windows 10 machines on the network in > Nautilus. "client max protocol = NT1" is all that is needed for browsing to work (I just tried it). However, it will use SMB1 also for data transfer then. > I only see my other Linux machines. My Centos 7 and my Fedora 26 both can > browse the Windows network. Setting NT1 is not a solution. Nautilus as does > smbtree both show the local SMB machines with these settings but fails > seeing any of the Windows machines. Looks like you have also some different problem here. SMB browsing is very fragile, it can be accidentally broken by many things. Try the first three steps in the original bug report, what it will show you. > This continues to be a serious problem with the integration of Fedora > into a mixed network. While it is annoying, you can work around it by using avahi/bonjour/mDNS in addition to SMB browsing. Linux and Mac machines will pick it up. Or just wait, until smbc_setOptionProtocols gets into Samba release (it is not yet in 4.9.2). Browsing of SMB shares now works in Fedora 30. Nautilus browsing of SMB shares is working in Fedora 30 if you are using the GNOME desktop. Not working with DeepinDE. (In reply to Tomas Kovar from comment #27) > Browsing of SMB shares now works in Fedora 30. I'm still getting "Unable to find any workgroups in your local network. This might be caused by an enabled firewall" in Nautilus using Fedora 30 KDE when trying to discover Samba shares. Browsing only works when I manually enter the URL of the share. (In reply to jman012345 from comment #29) > (In reply to Tomas Kovar from comment #27) > > Browsing of SMB shares now works in Fedora 30. > > I'm still getting "Unable to find any workgroups in your local network. This > might be caused by an enabled firewall" in Nautilus using Fedora 30 KDE when > trying to discover Samba shares. Browsing only works when I manually enter > the URL of the share. SMB browsing is quite fragile; it can be broken by many other things than this specific bug - for example, by firewall, by misconfigured WINS in your network or by misconfigured machine acting as the local master browser. Please try the steps to reproduce in the original bug report; if you won't get the expected result before step 4, your problem has different cause than this bug report. (In reply to Tomas Kovar from comment #30) > (In reply to jman012345 from comment #29) > SMB browsing is quite fragile; it can be broken by many other things than > this specific bug - for example, by firewall, by misconfigured WINS in your > network or by misconfigured machine acting as the local master browser. > Please try the steps to reproduce in the original bug report; if you won't > get the expected result before step 4, your problem has different cause than > this bug report. Alright, I get unexpected results for each step in the original report, so it looks like I'm having a different problem. Please disregard my last comment then. This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |