GNOME Bugzilla – Bug 700794
Duplicated icons of samba shares
Last modified: 2018-09-21 17:24:13 UTC
Created attachment 244971 [details] Duplicated Samba shares on nautilus. As of the GNOME 3.8 release, browsing network shares on Nautilus yields duplicate icons for Samba shares. Using: avahi 0.6.31 gvfs 1.6.2 nautilus 3.8.1 samba 4.0.5 Steps to reproduce: Setup a simple samba share, click on 'Browse Network' on Nautilus. Clickin on one icon the window title says 'Windows shares on <machine name>' and on the other it says 'Windows shares on <machine ip address>'. PS: This was marked as a dupe of Bug 535514 but that report was of a very old Nautilus version. I yet don't know if this is a problem on Nautilus or gvfs code.
*** Bug 698891 has been marked as a duplicate of this bug. ***
By the way, this is the dump of testparm: [global] server string = MAXWELL Samba Server log file = /var/log/samba/%m.log max log size = 50 printcap name = /etc/printcap dns proxy = No idmap config * : backend = tdb hosts allow = 192.168.0.0/255.255.255.0, 127.0.0.1 hosts deny = 0.0.0.0/0 [homes] comment = Home Directories read only = No browseable = No [printers] comment = All Printers path = /var/spool/samba printable = Yes print ok = Yes browseable = No [tmp] comment = Temporary file space path = /tmp read only = No guest ok = Yes
I though up a workaround that works (altough 'smbtree' outputs nothing...) - it is by using the option 'name resolve order = host' on the [global] section of smb.conf.
Nevermind, after logging via 'Windows Shares' the problem returns. It seems that nautilus/gvfs parses the avahi mDNS information and smbtree twice
Is the service published twice? What is the output of: avahi-browse -a
$ avahi-browse -a + wlan0 IPv4 MAXWELL Microsoft Windows Network local + wlan0 IPv4 maxwell SFTP File Transfer local + wlan0 IPv4 HP PSC 1500 series @ maxwell Internet Printer local + wlan0 IPv4 maxwell [84:4b:f5:dc:11:55] Workstation local + wlan0 IPv4 maxwell SSH Remote Terminal local + wlan0 IPv4 HP PSC 1500 series @ maxwell UNIX Printer local + wlan0 IPv4 HP PSC 1500 series @ maxwell _ipps._tcp local
Given that the samba service is not being published by avahi, we can probably rule out avahi or the dns-sd backend.
So where the problem may reside?
I cannot reproduce the problem. What is the output of: gvfs-ls -a "standard::*" network:///
$ gvfs-ls -a "standard::*" network:/// dnssd-domain-MAXWELL._smb._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f0a5c009a10 standard::target-uri=smb://maxwell.local:445/ standard::symbolic-icon=GThemedIcon:0x7f0a5c007320 dnssd-domain-maxwell._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=maxwell standard::icon=GThemedIcon:0x7f0a5c005ad0 standard::target-uri=sftp://maxwell.local:22/ standard::symbolic-icon=GThemedIcon:0x7f0a5c005d50 smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7f0a5c0048c0 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon:0x7f0a5c00db60 smb-server-MAXWELL 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f0a5c00e990 standard::target-uri=smb://MAXWELL/ standard::symbolic-icon=GThemedIcon:0x7f0a5c00d700
Created attachment 269953 [details] 'Browse network' in Fedora In Fedora 20 this does not happen: $ gvfs-ls -a "standard::*" network:/// dnssd-domain-MAXWELL._smb._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL standard::icon=GThemedIcon:0x7fe22c009e10 standard::target-uri=smb://maxwell.local:445/ standard::symbolic-icon=GThemedIcon:0x7fe22c008720 dnssd-domain-gauss._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=gauss standard::icon=GThemedIcon:0x7fe22c005990 standard::target-uri=sftp://gauss.local:22/ standard::symbolic-icon=GThemedIcon:0x1b64c10 dnssd-domain-maxwell._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=maxwell standard::icon=GThemedIcon:0x7fe22c00dc70 standard::target-uri=sftp://maxwell.local:22/ standard::symbolic-icon=GThemedIcon:0x7fe22c00db50 smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7fe22c00da60 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon:0x7fe22c010000
Thanks for your bugreport. It is weird, the outputs looks like correct. In both cases there are only 4 items, not 6 as you have on the first screenshot. If gvfs-ls showed it correctly, the problem could be at nautilus probably. So I close the bug if it is working correctly. If you still see the problem in the future, please reopen.
AFAIC, this only happens in Arch Linux. Screenshot 1: - Two samba and two ssh servers, on both hosts 'gauss' and 'maxwell'. The 'maxwell' box has Arch Linux, while 'gauss' has Slackware 14. The screenshot was taken from 'maxwell'. Screenshot 2: - Only one samba server on 'maxwell' and one ssh host on 'gauss'. The 'maxwell' box is still running Arch Linux while 'gauss' has Fedora 20. The screenshot was taken from 'gauss'. Which are the build flags for the Fedora package? That might solve the problem in Arch...
My bad, on screenshot 2 'maxwell' also runs a ssh server. So its samba and ssh shares are displayed correctly... on the Fedora machine.
Ok, so it isn't working in Arch Linux, reopening... Output in the Comment 12 is from Arch, right? dnssd-domain-MAXWELL._smb._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f0a5c009a10 standard::target-uri=smb://maxwell.local:445/ standard::symbolic-icon=GThemedIcon:0x7f0a5c007320 smb-server-MAXWELL 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f0a5c00e990 standard::target-uri=smb://MAXWELL/ standard::symbolic-icon=GThemedIcon:0x7f0a5c00d700 So there are two items for "MAXWELL (File Sharing)", one from smbbrowse and one from dnssd.
(In reply to comment #17) > Ok, so it isn't working in Arch Linux, reopening... > > Output in the Comment 12 is from Arch, right? > Yes, it is from my Arch Linux box.
Created attachment 271202 [details] [review] filter out smb domains Hmm we can filer out smb domains from dnssd, but don't know it is good idea. Could we get different smb domains from dnssd backend in comparation to smb backend? Why we don't filter them out currently?
(In reply to comment #19) > Created an attachment (id=271202) [details] [review] > filter out smb domains > > Hmm we can filer out smb domains from dnssd, but don't know it is good idea. > Could we get different smb domains from dnssd backend in comparation to smb > backend? Why we don't filter them out currently? I tried to compile with this patch but I got an error: --- gvfsbackendnetwork.c: In function ‘recompute_files’: gvfsbackendnetwork.c:441:19: error: ‘scheme’ undeclared (first use in this function) scheme = g_uri_parse_scheme (link_uri); ^ gvfsbackendnetwork.c:441:19: note: each undeclared identifier is reported only once for each function it appears in Makefile:2319: recipe for target 'gvfsd_network-gvfsbackendnetwork.o' failed make[4]: *** [gvfsd_network-gvfsbackendnetwork.o] Error 1 make[4]: Leaving directory '/home/lmello/Documents/pkgbuilds/gvfs/src/gvfs-1.18.3/daemon' Makefile:2786: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/lmello/Documents/pkgbuilds/gvfs/src/gvfs-1.18.3/daemon' Makefile:1145: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/lmello/Documents/pkgbuilds/gvfs/src/gvfs-1.18.3/daemon' Makefile:512: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/lmello/Documents/pkgbuilds/gvfs/src/gvfs-1.18.3' Makefile:443: recipe for target 'all' failed make: *** [all] Error 2 ---
AFAIK, it would be possible to have a share that is published through dnssd but not browseable (i.e. browseable = no in smb.conf). This would cause problems if all smb shares are blindly filtered from dnssd. Possibly a better fix would be to have a smart way of comparing the target URIs for equality and then removing duplicates there.
Created attachment 273085 [details] [review] filter out smb domains (In reply to comment #20) > (In reply to comment #19) > > Created an attachment (id=271202) [details] [review] [details] [review] > > filter out smb domains > > > > Hmm we can filer out smb domains from dnssd, but don't know it is good idea. > > Could we get different smb domains from dnssd backend in comparation to smb > > backend? Why we don't filter them out currently? > > I tried to compile with this patch but I got an error: Sorry, there is missing declaration. I amended it wrongly before...
(In reply to comment #21) > AFAIK, it would be possible to have a share that is published through dnssd but > not browseable (i.e. browseable = no in smb.conf). This would cause problems if > all smb shares are blindly filtered from dnssd. Possibly a better fix would be > to have a smart way of comparing the target URIs for equality and then removing > duplicates there. Hmm, that's good point (don't know those details). We have to find way how to compare those uris...
(In reply to comment #23) > (In reply to comment #21) > > AFAIK, it would be possible to have a share that is published through dnssd but > > not browseable (i.e. browseable = no in smb.conf). This would cause problems if > > all smb shares are blindly filtered from dnssd. Possibly a better fix would be > > to have a smart way of comparing the target URIs for equality and then removing > > duplicates there. > > Hmm, that's good point (don't know those details). We have to find way how to > compare those uris... Well, Ondrej's patch works for me. I put 'browseable = no' in one of my shares and it didn't show up on Nautilus, yet browsing through 'Windows Network' gave me my workgroup and my samba server, without that share of course. But isn't it how it is supposed to work? Of course I'm not opposed if somebody come up with a better way of filtering those samba URIs, but so far, so good.
Created attachment 273106 [details] Nautilus' 'browse network' with Ondrej's patch With Ondrej's patch, here's what I got configuring two samba shares, one with 'browseable = no' (which didn't show up on Nautilus) and one with the default 'browseable = yes' and the output from smbtree and gvfs-ls --- $ smbtree Enter lmello's password: WORKGROUP \\MAXWELL Samba Server \\MAXWELL\PSC_1500 HP PSC 1500 series \\MAXWELL\IPC$ IPC Service (Samba Server) \\MAXWELL\music Music --- $ gvfs-ls -a "standard::*" network:// dnssd-domain-maxwell._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=maxwell standard::icon=GThemedIcon:0x7fe8b00076f0 standard::target-uri=sftp://maxwell.local:22/ standard::symbolic-icon=GThemedIcon:0x7fe8b0009f00 smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7fe8b00046a0 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon:0x1539980 smb-server-MAXWELL 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL standard::icon=GThemedIcon:0x7fe8b0004b90 standard::target-uri=smb://MAXWELL/ standard::symbolic-icon=GThemedIcon:0x7fe8b000d6a0 --- $ cat /etc/samba/smb.conf (...) [tmp] comment = Temporary file space path = /tmp read only = no guest ok = yes browseable = no [music] comment = Music path = /home/lmello/Music read-only = yes guest ok = no (...) --- A Nautilus screenshot is attached. Is this how it's suppose to behave?
That's behavioral I suppose by the patch. However is the share seen by gvfs (by dnssd) if you don't apply my patch and set "browsable = no" as mentioned Ross in the Comment #20?
(In reply to comment #26) > That's behavioral I suppose by the patch. However is the share seen by gvfs (by > dnssd) if you don't apply my patch and set "browsable = no" as mentioned Ross > in the Comment #20? You mean in Comment #21? Right, I downgraded and set up two samba shares exactly like in Comment #25. Without the patch, here's the output I got: --- $ gvfs-ls -a "standard::*" network:// dnssd-domain-MAXWELL._smb._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f9360009a10 standard::target-uri=smb://maxwell.local:445/ standard::symbolic-icon=GThemedIcon:0x7f9360007320 dnssd-domain-maxwell._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=maxwell standard::icon=GThemedIcon:0x7f93600058d0 standard::target-uri=sftp://maxwell.local:22/ standard::symbolic-icon=GThemedIcon:0x7f9360005b50 smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7f9360004aa0 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon:0x7f936000dd60 smb-server-MAXWELL 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f936000e990 standard::target-uri=smb://MAXWELL/ standard::symbolic-icon=GThemedIcon:0x7f936000d900 --- I hope this helps...
By the way, without the patch, the share [tmp] with 'browseable = no' is not seen in Nautilus.
Looks like it is working as intended in this case. The share isn't published thru dnssd if 'browseable = no'.
Ok now I upgraded to GNOME 3.12. On 'Browse Network' in Nautilus I cannot get ANY (sshd and smb) shares on my local machine to show up. I have no other machines connected to my network, is this supposed to happen? I mean, Nautilus only show shares from other machines? On the command line: $ gvfs-la -a "standard::*" network:/// smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7ffbf00080c0 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon0x7ffbf0008090 And smbtree spits nothing on the console.
Looks like problems outside gvfs, if smbtree nor avahi doesn't print your shares now...
Yes, avahi-browse -a shows no output either... I guess both samba and avahi need to be recompiled again in Arch Linux...
No, it is a firewall problem. I disabled the firewall and restarted avahi: $ gvfs-ls -a "standard::*" network:/// dnssd-domain-MAXWELL._smb._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f6370009690 standard::target-uri=smb://maxwell.local:445/ standard::symbolic-icon=GThemedIcon:0x7f63700080c0 dnssd-domain-maxwell._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=maxwell standard::icon=GThemedIcon:0x25d7a30 standard::target-uri=sftp://maxwell.local:22/ standard::symbolic-icon=GThemedIcon:0x7f6370003a70 smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7f637000d930 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon:0x7f637000d870 smb-server-MAXWELL 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f637000eb00 standard::target-uri=smb://MAXWELL/ standard::symbolic-icon=GThemedIcon:0x7f637000fa40 Arch uptated gvfs to 1.20.1 Anyway I remembered to open UDP port 5353 for avahi in my firewall setup... isn't it this port to enable avahi anyway? Something changed...
I, I forgot that my network changed and I had to modify my firewall. Everything is OK now no duplicates on Nautilus. However, smbtree still spits nothing... so when I fix this problem on my machine without Ondrej's patch I suppose the duplicated samba shares would appear again...
Yes, indeed. My network provider changed, so did my LAN's subnet. I reconfigured both my firewall and smb.conf. Without Ondrej's patch the samba shares are shown twice on gvfs 1.20.x --- $ smbtree Enter lmello's password: WORKGROUP \\MAXWELL Samba Server \\MAXWELL\lmello Home Directories \\MAXWELL\PSC_1500 HP PSC 1500 series \\MAXWELL\IPC$ IPC Service (Samba Server) \\MAXWELL\tmp Temporary file space \\GAUSS \\GAUSS\Users \\GAUSS\IPC$ Remote IPC \\GAUSS\C$ Default share \\GAUSS\ADMIN$ Remote Admin --- $ gvfs-ls -a "standard::*" network:/// dnssd-domain-MAXWELL._smb._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f88dc009690 standard::target-uri=smb://maxwell.local:445/ standard::symbolic-icon=GThemedIcon:0x7f88dc0080c0 dnssd-domain-maxwell._sftp-ssh._tcp 0 (shortcut) standard::is-virtual=TRUE standard::display-name=maxwell standard::icon=GThemedIcon:0x7f88dc0036a0 standard::target-uri=sftp://maxwell.local:22/ standard::symbolic-icon=GThemedIcon:0x7f88dc003a10 smb-root 0 (shortcut) standard::is-virtual=TRUE standard::display-name=Windows Network standard::icon=GThemedIcon:0x7f88dc00d930 standard::target-uri=smb:/// standard::symbolic-icon=GThemedIcon:0x7f88dc00d870 smb-server-GAUSS 0 (shortcut) standard::is-virtual=TRUE standard::display-name=GAUSS standard::icon=GThemedIcon:0x7f88dc00ed00 standard::target-uri=smb://GAUSS/ standard::symbolic-icon=GThemedIcon:0x7f88dc00eca0 smb-server-MAXWELL 0 (shortcut) standard::is-virtual=TRUE standard::display-name=MAXWELL (File Sharing) standard::icon=GThemedIcon:0x7f88dc0100c0 standard::target-uri=smb://MAXWELL/ standard::symbolic-icon=GThemedIcon:0x7f88dc010a90 ---
It's been 2 years already... somebody please review Ondrej's patch?
Comment on attachment 273085 [details] [review] filter out smb domains It was basically reviewed by Comment 21. We should not blindly filter out all smb entries from dnssd results, maybe soup_address_equal_by_ip may be used for comparing ips...
Just a note that the following dconf changes may be probably used as a workaround in your case... Do not show dnssd results in network://, just link to dnssd://: gsettings set org.gnome.system.dns_sd display-local separate Do not show dnssd results in network:// at all: gsettings set org.gnome.system.dns_sd display-local disabled Restore default settings to show both in network://: gsettings set org.gnome.system.dns_sd display-local merged
*** Bug 783917 has been marked as a duplicate of this bug. ***
Any further patches would need to make sure that NetBios and mDNS hostnames are resolved before being compared for duplication, but the original hostnames should still be used in the "links" to those servers, to avoid hardcoded IP addresses in bookmarks and such.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/205.