Bug 1513394 - Applications using gvfs are unable to browse SMB shares
Summary: Applications using gvfs are unable to browse SMB shares
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: samba
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Guenther Deschner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1557860 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-15 10:32 UTC by Tomas Kovar
Modified: 2019-05-06 17:13 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Force SMB1 in gvfsbackendsmbbrowse (837 bytes, patch)
2018-02-26 12:43 UTC, Tomas Kovar
no flags Details | Diff
Changes to spec file for building (1.25 KB, patch)
2018-02-26 12:45 UTC, Tomas Kovar
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Samba Project 12876 None None None 2019-05-06 15:29:26 UTC
GNOME Bugzilla 780958 None None None 2019-05-06 15:29:27 UTC

Description Tomas Kovar 2017-11-15 10:32:07 UTC
Description of problem:

Nautilus and other applications using gvfs are unable to browse SMB shares.

Version-Release number of selected component (if applicable):

gvfs-smb-1.34.1-1.fc27.x86_64

How reproducible:

The same bug appears on several computers updated to F27, from F26.

Steps to Reproduce:

1. nmblookup -M -- -
2. nmblookup -M workgroup
3. smbtree
4. gio list network://
5. gio list smb:///
6. gio list smb://workgroup

Actual results:

1. will return IP address for __MSBROWSE__ special name
2. will return IP address for workgroup master browser
3. will correctly list workgroup, workgroup members and their shares
4. returned items are missing workgroup members
5. will return empty
6. will return an error message "The specified location is not mounted"

Expected results:
1. OK
2. OK
3. OK
4. returned items should contain workgroup members
5. should contain workgroup name
6. should contain workgroup members

Additional info:

This bug appeared after upgrade to Fedora 27. In Fedora 26, it worked correctly.

Comment 1 Ondrej Holy 2017-11-24 13:54:01 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?

Comment 2 Tomas Kovar 2017-11-24 17:22:46 UTC
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

Comment 3 Ondrej Holy 2017-11-27 12:44:56 UTC
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...

Comment 4 Tomas Kovar 2018-02-26 12:43:28 UTC
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/

Comment 5 Tomas Kovar 2018-02-26 12:45:01 UTC
Created attachment 1400830 [details]
Changes to spec file for building

Patch to spec file for building with forced SMB1.

Comment 6 Ondrej Holy 2018-02-27 12:46:32 UTC
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

Comment 7 Ondrej Holy 2018-02-27 12:49:22 UTC
Alexander, don't you have any comments to this?

Comment 8 Alexander Bokovoy 2018-02-27 14:36:06 UTC
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.

Comment 9 Tomas Kovar 2018-02-27 14:46:03 UTC
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.

Comment 10 Alexander Bokovoy 2018-02-27 16:19:45 UTC
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

Comment 11 Tomas Kovar 2018-02-27 17:40:35 UTC
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.

Comment 12 Alexander Bokovoy 2018-03-19 06:30:19 UTC
*** Bug 1557860 has been marked as a duplicate of this bug. ***

Comment 13 Jonathan Underwood 2018-04-02 20:24:28 UTC
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 ?

Comment 14 Jonathan Underwood 2018-04-02 20:35:20 UTC
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.

Comment 15 Nate Graham 2018-05-11 20:27:56 UTC
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?

Comment 16 Tomas Kovar 2018-05-12 13:42:02 UTC
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.

Comment 17 Andreas Schneider 2018-09-04 14:53:12 UTC
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.

Comment 18 Ondrej Holy 2018-09-05 14:42:31 UTC
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.

Comment 19 Andreas Schneider 2018-09-06 07:56:18 UTC
There is no workgroup support with SMB3!

smb://WORKGROUP is a SMB1 only feature!!!

Comment 20 Ondrej Holy 2018-09-06 09:55:49 UTC
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...

Comment 21 Ondrej Holy 2018-09-21 08:58:24 UTC
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.

Comment 22 Damian Ivanov 2018-10-03 06:22:19 UTC
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?

Comment 23 Rich 2018-11-06 19:52:01 UTC
Not fixed in Fedora 29. 
Setting server max protocol = NT1 does not fix issue.

Comment 24 Ondrej Holy 2018-11-07 11:43:53 UTC
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"...

Comment 25 Rich 2018-11-07 15:48:06 UTC
(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.

Comment 26 Tomas Kovar 2018-11-08 23:17:07 UTC
(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).

Comment 27 Tomas Kovar 2019-04-30 21:29:11 UTC
Browsing of SMB shares now works in Fedora 30.

Comment 28 Rich 2019-05-01 12:25:47 UTC
Nautilus browsing of SMB shares is working in Fedora 30 if you are using the GNOME desktop. 
Not working with DeepinDE.

Comment 29 jman012345 2019-05-06 15:26:59 UTC
(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.

Comment 30 Tomas Kovar 2019-05-06 15:34:56 UTC
(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.

Comment 31 jman012345 2019-05-06 17:13:56 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.