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

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

I too am experiencing this in Ubuntu 19.04.

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

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

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)

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.

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

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

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.

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).

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

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??? >:|

Can confirm the bug is still present in Ubuntu 20.04.

This Bug is embarrassing.

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

When is this expected to hit main repos?

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...

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.

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

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

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.

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?

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.

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

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.

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

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.

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.

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).

> 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'

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.

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...

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.

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.

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.

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.

> 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!

Xubuntu 22.04.1 after upgrading from 20.04

In order to get multiple Windows 10 systems to "discover" the samba shares on two different Xubuntu systems, I had to re-enable SMB1 protocol on all the Windows systems. Microsoft apparently keeps disabling this on system updates.

As reported above, old Windows mapped drive assignments made to Ubuntu samba shares have continued to work over time, but new shares cannot be seen unless SMB1 is enabled. of course, this should all just work using newer secure protocols.

For a significant piece of server software, the fact that this hasn't been addressed long ago is a real mystery.

Sill present in Ubuntu 22.04.
Cannot browse samba shares from my NAS. Can connect if I provide the full path without browsing.

Inspired by BloodyIron's comments above, I investigated this issue and was able to develop a patch that solves this problem for my use case: browsing NAS devices running TrueNAS and OpenMediaVault. It appears that the gvfsd-smb-browse process is left in a bad state after attempting to mount a workgroup, which occurs either when attempting to open an URL like smb://WORKGROUP/ or during network discovery in gvfsd-network. My patch simply disables workgroup discovery/browsing functionality, leaving *browsing* functionality intact for servers that are *discovered* via DNS-SD (mDNS). This does not address the issue of discovering Windows 10 servers that advertise themselves only via WS-Discovery, but appears to work fine for devices that advertise themselves using mDNS, allowing those devices to be successfully browsed.

I note that workgroups are an obsolete concept in a post-NT1 (post-SMB1) world, so the offending code should eventually just be yanked out, along with the addition of support for WS-Discovery in Linux. My patch does not address the root cause, as whatever is going wrong while attempting to mount a workgroup should result in a recoverable error. I traced gvfsbackendsmbbrowse.c:do_mount() up to the point at which smbc_opendir() is called without any surprises, whereupon things went south. I did not investigate any further, but if I were to do so, I'd be inclined to take a look for an unreleased lock.

The attachment "Disable broken workgroup discovery/browsing" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Fresh install of Ubuntu 22.04 and still happening

WILL THIS EVER GET FIXED????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

It's been FIVE YEARS since this first came up (other bugs), and SMB1 has been off for security reasons for many years now. This User eXperience is completely garbage, frankly. And no user should realistically be expected to have to open a cli and kill gvfsd-smb-browse just because we don't have a proper implementation for this.

It truly begs the question, WHY DOES THIS WORK WHEN THAT PROCESS IS RESTARTED?

If restarting it "fixers" it, then why on earth does it break in the first place? And why isn't this already fixed?

For humans in the future, use this command for convenience:

killall gvfsd-smb-browse

And then ctrl+r for future quick recall (in the CLI of your desire).

@BloodyIron, please see: https://github.com/christgau/wsdd

I suggest you install as it is a significantly better work-around than constantly killing the daemon. It is intended to be released in the next Debian (bookworm) release as a package, I do not know if Ubuntu will also be including it in their next release. Whether Nautilus will use it or not, I could not answer to that - I have long since switched to using Thunar without any issues.

With regards to "If restarting it 'fixers' it, then why on earth does it break in the first place?" I suggest you see one of the replies here: https://gitlab.gnome.org/GNOME/gvfs/-/issues/307 and further reading here: https://gitlab.gnome.org/GNOME/gvfs/-/issues/506

This is about a bug in this piece of software, and not about finding another piece of software to take its place. wsdd, as you proposed, is not included by default in Ubuntu.

The point of seeking a fix for this issue is so that the UX, out of the box, is better than it is now.

Users should not have to install another tool to get this basic functionality working.

I would like to remind those reading that this issue was posted ALMOST FOUR YEARS ago. And the "temporary workaround" is to kill the process so it reinitalises.

Can we PLEASE get this fixed already?!?!?!?

@ BloodyIron It looks like the problem you are experiencing is the same issue as I have had. I think the reason that it works after you kill gvfsd-smb-browse is that your FreeNAS server is advertising itself via mDNS, and gvfsd will see that. You don't need SMB1 or WSDD for gvfsd to discover your NAS. But it is also looking for a "Windows Network" (i.e. the Windows "network neighborhood" or workgroup that shows up as a separate subfolder) using SMB1, and that fails if the server does not provide SMB1. Crucially, however, it fails in a way that leaves the gvfsd-smb-browse process in a bad state where it fails to allow browsing of the server even though it has been discovered via mDNS. I encourage you to take a look at my patch, or to use the PPA at https://launchpad.net/~wmaddox3rd/+archive/ubuntu/gvfs-smb-sharelist-patch. It does indeed look like there is a bug here in that attempting discovery via SMB1 somehow breaks browsing of the server discovered via mDNS.

See also my remarks here: https://gitlab.gnome.org/GNOME/gvfs/-/issues/307#note_1632096

Upgraded to Ubuntu 23.04 and the issue persists... Will this ever get fixed? This is now over 4 years old.

The SMB1 code should be entirely removed from the stack. It’s insecure and
deprecated everywhere.

On Tue, May 2, 2023 at 8:56 AM BloodyIron <email address hidden>
wrote:

> Upgraded to Ubuntu 23.04 and the issue persists... Will this ever get
> fixed? This is now over 4 years old.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1881780).
> https://bugs.launchpad.net/bugs/1828107
>
> Title:
> gvfs can't list shares from smb servers that disabled SMB1
>
> Status in gvfs:
> New
> 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
>
>

SMB1 is disabled on the server/NAS end. And I'm using the out of the box experience for Ubuntu 23.04. The UX of this whole situation is effectively broken. And while I know that I can just "killall gvfsd-smb-browse" to trigger it to restart, that's not the whole point of why this needs to be fixed.

This needs to be fixed, yes, because of the security aspect. But primarily because a user shouldn't have to worry about having to kill gvfsd-smb-browse just to reach an SMB network share using an actually secure protocol version.

So again, what's the hold-up here? SMB1 is off, and has been for years.

STILL having this problem! Also, the gnome issue of #506 is NOT RELEVANT! As this issue PREDATED WSD IN TOTALITY.

Like, how more clear do I REEAALLLYYYY need to make this? I kill the gvfsd-smb-browse process, and IMMEDIATELY I can browse SMB shares when SMB1 is disabled. CLEARLY the application is capable, however is unwilling to cooperate until it gets restarted (gvfsd-smb-browse). This has NOTHING to do with WSD in impact, or even as a solution! WSD _IS NOT PRESENT ON MY NETWORK_.

Hell, we even have another thread _claiming_ that this was fixed in much earlier versions of Ubuntu (which clearly it wasn't): https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1778322

Again, also, _THIS HAPPENS OUT OF THE BOX FOR ALL UBUNTU DESKTOP INSTALLATIONS CURRENT AND FOR THE PAST 4+ YEARS_.

It's looking like maybe the most relevant GNOME issue thread is : https://gitlab.gnome.org/GNOME/gvfs/-/issues/307

(Holy cow! 6 years originally posted! Yikes!)

Also, there looks to be two open MRs in #307 (linked above) which might help. One is for use of WSD (which as demonstrated isn't relevant, in my case anyways), and the other, something about SMB server cache (which I'm a touch dubious of, but I'm asking for details).

Ondrej really carrying the torch there though! :)

Given that a restart of the application is helping and fixes this temporarily. This reminds be of a known issue in rygel, where disable IGMP snooping is the solution if network bridges are involved and rygel can only be discovered after a restart. https://wiki.gnome.org/Projects/Rygel/FAQ

Not saying that this would help anything here. I just want to raise awareness that this might also be caused by other external factors along the network.

@deisi , That certainly is something for valid consideration. In my use-case there is no network bridging going on, just to clear that up. The NAS and the client are on the same network (two non-routing switches exist between them), on the same CIDR IP range, same DHCP server involved, same DNS, same internet access. So nothing is really sticking-out for me in that regards that could be relevant for my scenario. But I'm open to even more ideas I had not considered :^) as I really just would love this solved lol.

The upstream ticket got closed and Ondrej asked someone to open a new ticket if they still get the issue, could anyone do that on gitlab?

Ondrej actually means if we see issues with gvfs v1.50.5 that we should open a new issue, to clarify. That suggests (implicitly, not explicitly) that v1.50.5 of gvfs has (might?) an appropriate fix.

I have no idea when this will hit a version of Ubuntu I can test this on. But it sounds promising!

Yeah I've confirmed with the release notes ( https://gitlab.gnome.org/GNOME/gvfs/-/commit/ca9c22c4c41afe8ce4cc4a0bae376e9d2850f0a5 ) that the fix (hopefully the one that actually solves this properly) is in gvfs v1.50.5! "smbbrowse: Fix empty device listing after unrelated mount failure (Ondrej Holy)".

Ondrej goes on to report that "GVfs 1.50.x is meant for GNOME 42+." so v1.50.5+ should eventually land in Ubuntu repos probably! As for how that whole workflow works I know nothing about that. So yay! Can't wait to apply that code all over my compies! \o/

The change to try is probably https://gitlab.gnome.org/GNOME/gvfs/-/commit/293365f6

The fix is already in the version which is in Ubuntu 23.10, could you try from a iso if that's resolved there for you?

@seb128 just booted into a live ISO for Ubuntu 23.10, just to test without installing etc, and still getting the "Failed to retrieve share list from server: Invalid argument" that I get on other systems :(