Comment 40 for bug 1828107

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.