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