gvfs can't list shares from smb servers that disabled SMB1

Bug #1828107 reported by Andreas Hasenack
106
This bug affects 19 people
Affects Status Importance Assigned to Milestone
gvfs
New
Unknown
gvfs (Ubuntu)
Triaged
High
Unassigned

Bug Description

After bug #1778322 is fixed (just needs a gvfs rebuild with newer samba), samba machines will start to show up again in the "windows network" tab in nautilus. But if a server has disabled the SMB1 protocol, nautilus will show an error when that server is clicked on, instead of showing the shares list.

Even with SMB1 disabled, it should still be technically possible to get a share list, since smbclient can do it:

andreas@nsnx:~$ nmblookup -A 192.168.122.101
Looking up status of 192.168.122.101
 D-NO-SMB1 <00> - B <ACTIVE>
 D-NO-SMB1 <03> - B <ACTIVE>
 D-NO-SMB1 <20> - B <ACTIVE>
 ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
 WORKGROUP <00> - <GROUP> B <ACTIVE>
 WORKGROUP <1d> - B <ACTIVE>
 WORKGROUP <1e> - <GROUP> B <ACTIVE>

 MAC Address = 00-00-00-00-00-00

andreas@nsnx:~$ smbclient -L 192.168.122.101 -N
WARNING: The "syslog" option is deprecated

 Sharename Type Comment
 --------- ---- -------
 print$ Disk Printer Drivers
 pub_no_smb1 Disk
 IPC$ IPC IPC Service (d-no-smb1 server (Samba, Ubuntu))
Reconnecting with SMB1 for workgroup listing.
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE
Failed to connect with SMB1 -- no workgroup available

andreas@nsnx:~$ smbclient //192.168.122.101/pub_no_smb1 -U ubuntu%ubuntu -m NT1
WARNING: The "syslog" option is deprecated
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

andreas@nsnx:~$ smbclient //192.168.122.101/pub_no_smb1 -U ubuntu%ubuntu -m SMB2
WARNING: The "syslog" option is deprecated
Try "help" to get a list of possible commands.
smb: \> dir
  . D 0 Fri May 3 18:16:38 2019
  .. D 0 Fri May 3 18:15:24 2019
  hello.txt N 21 Fri May 3 18:16:12 2019
  hello-from-nsnx.txt A 9 Fri May 3 18:16:38 2019

  20509264 blocks of size 1024. 13121800 blocks available

summary: - gvfs can't browse smb servers that disabled SMB1
+ gvfs can't list shares from smb servers that disabled SMB1
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed
Changed in gvfs:
status: Unknown → New
Changed in gvfs (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
BloodyIron (bloodyiron) wrote :

I too am experiencing this in Ubuntu 19.04.

Revision history for this message
BloodyIron (bloodyiron) wrote :

So... any word on this bug? :S Still getting it.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Looks like I missed a notification in https://gitlab.gnome.org/GNOME/gvfs/issues/307, I'll followup there

Revision history for this message
BloodyIron (bloodyiron) wrote :

So I just upgraded to 19.10 and I am _STILL_ having this issue. I have had this issue now through two whole major releases! SMB1 being turned off _SHOULD NOT BREAK THIS_. SMB1 is a _MAJOR_ security threat, and this really needs to get fixed!

I've been reporting this failure since April of 2019 :/ (started in another bug report)

Revision history for this message
BloodyIron (bloodyiron) wrote :

And as a reminder, my "solution" is to:

1. trigger the error by trying to browse to an SMB share with SMB1 disabled on the server-side
2. "pidof gvfsd-smb-browse"
3. "kill $PID" from above (regular kill, not -9)

It then works, I can actually get to shares.

I have to do this after _every_ reboot.

tags: added: desktop-lts-wishlist
Revision history for this message
BloodyIron (bloodyiron) wrote :

Can we please get this addressed already? This issue persists in 19.10 (haven't tested in 20.04 yet due to unrelated reasons)

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

This will only get better once another discovery service is used, since SMB1 won't come back.

https://github.com/christgau/wsdd is something we could look into

Revision history for this message
BloodyIron (bloodyiron) wrote :

But once I nicely kill the process, I not only can connect to the share, I can still discover network shares. So, I don't really know how to explain that.

Revision history for this message
JORGETECH (jorgetech) wrote :

I believe the real issue is that libsmbclient is still using the SMB1/NT1 protocol as the maximum, the issue should be solved upstream since SMB1 is deprecated (disabled by default in newer Samba server versions).

Revision history for this message
BloodyIron (bloodyiron) wrote :

Really hope this gets solved soon, have to kill the process after browsing shares every time I reboot.

Revision history for this message
BloodyIron (bloodyiron) wrote :

STILL getting this error in Ubuntu 20.04. Just upgraded to 19.10 and I get this error immediately. How exactly is this not already upstreamed and fixed already??? >:|

Revision history for this message
Jonas Islander (wbbap-reg03) wrote :

Can confirm the bug is still present in Ubuntu 20.04.

Revision history for this message
Malte Deiseroth (deisi) wrote :

This Bug is embarrassing.

Revision history for this message
BloodyIron (bloodyiron) wrote :

Why has this STILL not been rolled out to 20.04??? It was fixed for 19.10, but still not for 20.04...

Changed in gvfs:
status: New → Fix Released
Revision history for this message
BloodyIron (bloodyiron) wrote :

When is this expected to hit main repos?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Which change do you expact to be made availble? The issue there is due to clients not handling the fact that the old unsecure protocal is disabled by default now, that's not coming back though...

Revision history for this message
BloodyIron (bloodyiron) wrote :

Oh I dunno, maybe the "Fix Released" part? You do realise there is code out there that fixes this that hasn't hit 20.04, right? It was solved in later 19.10, now broken in 20.04.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The upstream bug closing seems buggy since they pointed it as a duplicate of https://gitlab.gnome.org/GNOME/gvfs/-/issues/506 and that doesn't make much sense. Unsure also there was anything solved in 19.10, it's just that the situation is confusing and comments don't always speak about the same issue

Revision history for this message
Sebastien Bacher (seb128) wrote :

Ignore the comment about the duplicate status, https://gitlab.gnome.org/GNOME/gvfs/-/issues/506 is about a request to implement a new protocol which is what is needed, updating the reference so the status is correct

Changed in gvfs:
status: Fix Released → Unknown
Revision history for this message
BloodyIron (bloodyiron) wrote :

The issue went away for me in 19.10 not long after I saw reports that a fix was released. And same system, the issue came back when I upgraded to 20.04.

Revision history for this message
BloodyIron (bloodyiron) wrote :

I AM STILL GETTING THIS ISSUE TO THIS DAY. WILL THIS EVER BE FIXED? This issue was reported over 1.5 YEARS ago and a fix was already made, but HAS NOT BEEN RELEASED TO UBUNTU 20.04 WHICH IS THE LONG TERM SUPPORT VERSION. WHEN WILL THIS BE FIXED?

Revision history for this message
Jim Adamson (adamsojc) wrote : Re: [Bug 1828107] Re: gvfs can't list shares from smb servers that disabled SMB1

I second that!!
This is pathetic.

On November 24, 2020 3:58:16 PM EST, BloodyIron <email address hidden> wrote:
>I AM STILL GETTING THIS ISSUE TO THIS DAY. WILL THIS EVER BE FIXED?
>This
>issue was reported over 1.5 YEARS ago and a fix was already made, but
>HAS NOT BEEN RELEASED TO UBUNTU 20.04 WHICH IS THE LONG TERM SUPPORT
>VERSION. WHEN WILL THIS BE FIXED?
>
>--
>You received this bug notification because you are subscribed to the
>bug
>report.
>https://bugs.launchpad.net/bugs/1828107
>
>Title:
> gvfs can't list shares from smb servers that disabled SMB1
>
>Status in gvfs:
> Unknown
>Status in gvfs package in Ubuntu:
> Triaged
>
>Bug description:
> After bug #1778322 is fixed (just needs a gvfs rebuild with newer
> samba), samba machines will start to show up again in the "windows
> network" tab in nautilus. But if a server has disabled the SMB1
> protocol, nautilus will show an error when that server is clicked on,
> instead of showing the shares list.
>
> Even with SMB1 disabled, it should still be technically possible to
> get a share list, since smbclient can do it:
>
> andreas@nsnx:~$ nmblookup -A 192.168.122.101
> Looking up status of 192.168.122.101
> D-NO-SMB1 <00> - B <ACTIVE>
> D-NO-SMB1 <03> - B <ACTIVE>
> D-NO-SMB1 <20> - B <ACTIVE>
> ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
> WORKGROUP <00> - <GROUP> B <ACTIVE>
> WORKGROUP <1d> - B <ACTIVE>
> WORKGROUP <1e> - <GROUP> B <ACTIVE>
>
> MAC Address = 00-00-00-00-00-00
>
> andreas@nsnx:~$ smbclient -L 192.168.122.101 -N
> WARNING: The "syslog" option is deprecated
>
> Sharename Type Comment
> --------- ---- -------
> print$ Disk Printer Drivers
> pub_no_smb1 Disk
> IPC$ IPC IPC Service (d-no-smb1 server (Samba,
>Ubuntu))
> Reconnecting with SMB1 for workgroup listing.
> protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE
> Failed to connect with SMB1 -- no workgroup available
>
>andreas@nsnx:~$ smbclient //192.168.122.101/pub_no_smb1 -U
>ubuntu%ubuntu -m NT1
> WARNING: The "syslog" option is deprecated
> protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE
>
>andreas@nsnx:~$ smbclient //192.168.122.101/pub_no_smb1 -U
>ubuntu%ubuntu -m SMB2
> WARNING: The "syslog" option is deprecated
> Try "help" to get a list of possible commands.
> smb: \> dir
>. D 0 Fri May 3 18:16:38
>2019
>.. D 0 Fri May 3 18:15:24
>2019
>hello.txt N 21 Fri May 3 18:16:12
>2019
>hello-from-nsnx.txt A 9 Fri May 3 18:16:38
>2019
>
> 20509264 blocks of size 1024. 13121800 blocks
> available
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/gvfs/+bug/1828107/+subscriptions

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Revision history for this message
Sebastien Bacher (seb128) wrote :

To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/project/about-ubuntu/conduct. Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

There is no fix available at the moment there, unsure why it worked for you in 19.10, you could try again to check if that's still working...

Upstream would also be a better place to ask if work is planned on a solution

Revision history for this message
BloodyIron (bloodyiron) wrote :

Getting frustrated because a bug that has existed so long and is key to network security (connection with SMB1), and has gone ignored for over 1.5 years, is not bad conduct. SMB1 was disabled because of it's egregious security issues, and having no solution for things like this as a result is unacceptable.

Yes, I know this is volunteer work, but this ticket should not be marked Triaged as no work has actually been done on it, and quite frankly, this should be marked with a higher priority. This kind of functional behaviour is only going to promote the re-enabling of SMB1 on systems, which is the complete opposite of what anyone wants.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug isn't ignored but implementing a new protocol is not trivial, also you are commenting on the wrong place, Ubuntu isn't writting that software. Stating that volunteers or companies not doing work for you for free is unacceptable is probably not going to bring you far though...

On the bug status, see https://wiki.ubuntu.com/Bugs/Bug%20statuses

Triaged is used to describe issues which are understood, there is an inprogress for work that has started

Changed in gvfs (Ubuntu):
importance: Medium → High
Revision history for this message
BloodyIron (bloodyiron) wrote :

There's no way the solution to this is implementing a new protocol to replace SMB, that would be absurd. The discoverability and connectivity works when the process is terminated and restarted. Clearly this is achievable.

Revision history for this message
Craig W. (avsdev) wrote :

Not to put too fine a point on it, but actually that is exactly what this requires. Microsoft phased out the SMBv1 protocol, (NetBios is dead, long live NetBios), in favour of their new protocol: Web Services Dynamic Discovery (WSD). There has been a lot of discussion and work as to exactly HOW WSD should be implemented for SAMBA and gvfs and what to do in future if Microsoft do another flip of the switch.

Granted this has taken a lot of time, but as previously mentioned, all of this discussion and development is dependent on people gratuitously handing over their free time. If you want up to date support and to demand for things to be done, might I politely suggest you fork out for a Red Hat enterprise subscription.

Revision history for this message
BloodyIron (bloodyiron) wrote :

Um, no. Microsoft did not deprecate SMB v1 for WSD, they did it because it has a blatant security flaw in it : https://techcommunity.microsoft.com/t5/storage-at-microsoft/stop-using-smb1/ba-p/425858

Furthermore, SMB v2 and v3.x has been out for years, as modern implementations of the protocol, _not_ WSD.

And again, I can browse to my SMB shares just by killing and restarting the gvfsd-smbd process, so clearly this has nothing to do with WSD at all, since that's not in play in my environment at all (I know this because my FreeNAS system doesn't serve WSD).

Revision history for this message
Sebastien Bacher (seb128) wrote :

> I can browse to my SMB shares just by killing and restarting the gvfsd-smbd process

you should register a new bug then because that's not what that one is about, quoting the title
'gvfs can't list shares from smb servers that disabled SMB1'

Revision history for this message
Craig W. (avsdev) wrote :

In the very same article you linked: https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows

With SMBv1 being removed, Network Browser (which depended on SMBv1) was removed, all of which relied on NetBios being used for discovery. (Hence, NetBios is dead, long live NetBios).

Microsoft's replacement for NetBios discovery is *drumroll please*: WSD.

I'm completely speculating here but:
Your initial start up effect is probably gvfsd-smbd doing something like a Browser Tree scan of last known hosts. This actively goes to the host asking about available protocols, shares etc. This is NOT discovery. You could argue "well if it already knew about it, how does it lose it?" and that is a fair question, to which the answer might well be "Don't want to do an expensive back n forth poll, would rather use a discovery protocol", and now we are back to the discussion of needing a discovery protocol: WSD.

Revision history for this message
BloodyIron (bloodyiron) wrote :

I don't use Windows for serving SMB, I was simply linking the reason for deprecation. FreeNAS, and other non-windows systems serve SMB v2 and higher for network shares, and WSD is not present, relevant, or desired in those configurations. WSD is not the solution, nor replacement, and SMB v2 and v3 have existed for longer than WSD. Yes, netbios was used previously, but clearly after killing the process I can reach them without SMB v1, just not after the first boot.

And just because that's the workaround, does not make it warrant another thread...

Revision history for this message
Craig W. (avsdev) wrote :

My apologies for sidetracking this far trying to explain differences between discovery and browsing but there seems to be a lot of mixing the 2 as one. The fact that you have "discovered" a server you wish to "browse" is irrelivant for this bug (afaik you shouldn't have been able to discover it as there are currently no working mechanisms to do so in LTS versions judging from the open bug reports). If however you are experiencing a crash whilst attempting to browse a share of the discovered host, that is relevant and is to do with the way SMB protocol versions themselves are being handled.

WRT the rest of the discussion:

SMBv1 leveraged NetBios to do discovery, (as did WINS which was a fallback discovery method). With SMBv1 removed/disabled, all of the NetBios discovery is also removed/disabled. Therefore, a discovery protocol is needed. Enter WSD. SMBv2 and SMBv3 use WSD to discover hosts on the network, (incidentally WSD was designed for SMBv2 during the development of Vista to remove the dependancy on NetBios).

If you know the address of a host serving SMBv2 or SMBv3 already (via WSD, any other discovery protocol, off by heart), you can just do an SMB request against that address:
smbclient --list=<<SERVER>> --user=Anonymous -N

>The discoverability and connectivity works when the process is terminated and restarted. Clearly this is achievable.
> Yes, netbios was used previously, but clearly after killing the process I can reach them without SMB v1, just not after the first boot.

This is still probably nothing more than a cached entry, start-up check of previously known hosts, or initial broadcast. Some of which may or may not be unintentional from a security perspective, so as @seb128 said, file another bug report against them if you so wish.

Revision history for this message
C. Jeffery Small (loyhz2ay-jeff-h670zbts) wrote :

Just to add another voice to the crowd, I'm on Xubuntu 20.04 and I just ran across this problem myself.

I am using the Nemo file browser, but the same thing occurs with Nautilus and Thunar. I didn't notice the problem for a long while because I had three legacy Windows machines on the network (all running Windows 10 at this point) and had made file browser bookmarks to the important shares long ago. These bookmarks have continued to work to this day without issue. I got a new Windows 10 machine a few weeks ago and was having the problem everyone reports of not being able to connect ("Failed to retrieve share list from server") on the new machine, even though all the existing bookmarks were still functioning file. All of the Windows 10 machines were able to see one another without problem.

Then I ran across this thread and tried Bloodyiron's suggestion of killing the gvfsd-smb-browse process. Immediately I was able to connect to the new machine using Nemo. I quickly created some needed bookmarks to the important shares and now I can communicate using the file browser and expect the new bookmarks to be as reliable as the others. So I would suggest this bookmark method to others as a workaround.

This supports Craig W's comment about the difference between discovery and browsing. When I run "smbclient -L //<ip_address> -U <user>", it reports all of the shares on the target, whether Windows or Linux, with the closing message: "SMB1 disabled -- no workgroup available" as expected.

Unfortunately, this is only a one-way solution. All of the legacy Windows 10 machines can see and access the Samba shares on the Xubuntu box, but I haven't yet figured out a way to get the new Windows machine to access these same shares, with or without gvfsd-smb-browse running. Every connection attempt is rejected and I haven't found useful messages in the logs. If I figure out a solution, I'll post here, and I'm open to suggestions.

I agree with the general sentiment that for a service as important as this, there isn't any real excuse for this thing dragging out for two years as it has.

Revision history for this message
C. Jeffery Small (loyhz2ay-jeff-h670zbts) wrote :

Regarding my previous comment, disregard the issue about Windows 10 having problems accessing the Samba shares. This turned out to be a strange password problem with samba. Resetting the user's password to the same value that it already was immediately cleared the issue and all windows machines could once again see the shares.

Revision history for this message
DanW (danw999) wrote :

Hi all, just wondering if there is any update on this at all? I would just like to add that this is a big issue. I am in an environment where I wish to disable SMB1 but this bug makes it extremely inconvenient for users browsing the network. Given that having SMB1 enabled is a security risk, I would like to echo that we should not have to rely on turning on SMB1 in order to browse the network. One of the reasons I am attempt to push more of Linux environment is for security itself, which is ironic given this bug actually causes a security issue. Thank you.

Revision history for this message
iandol (iandol) wrote :

> I can browse to my SMB shares just by killing and restarting the gvfsd-smbd process

This magic solution has fixed my problems connecting my 21.04 Ubuntu clients to a Synology NAS, thank you @BloodyIron (wasting ~60 minutes of time trying to find a work around).

While waiting for the proper upstream fix if it ever appears, is there no way to add this workaround into Gnome? When trying to connect to an SMB and getting a failure, restart gvfsd-smbd in the background and then when the user tries again, voila, it works without a problem.

I understand Gnome is open-source and I am grateful for all the work of the volunteers who maintain it!

Changed in gvfs:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.