Description of problem: The Nautilus file browser cannot access SAMBA, and does not see the share. Version-Release number of selected component (if applicable): nautilus-3.28.1-23.el8.x86_64 How reproducible: every time Steps to Reproduce: 1. Configure Samba share using SMB1 (NT1/CISF) on the Samba server and min protocol to SMB1 on the client it works. 2. If SMB2 and above protocol is used Nautilus file browser cannot access SAMBA 3. Actual results: The Nautilus file browser cannot access SAMBA if SMB2 and above protocol is used. Expected results: The Nautilus file browser should able to access SAMBA if SMB2 and above protocol is used. Additional info:
Vikramsingh, can you please link the customer case to this bug?
If I understand the report correctly, the "smb://ip_or_host/" locations in Nautilus still work fine, just the devices are not automatically discovered thru the "Other Locations" view and the "Windows Network" folder in Nautilus, am I right? There are 3 protocols to discover (SAMBA) devices: - NetBIOS - This is used for the "Other Locations" view and the "Window Network" folder in Nautilus but it requires NT1 protocol. So it is expected that this doesn't work when NT1 is disabled. - mDNS - This is also used to add devices in "Other Locations" in Nautilus. The "multicast dns register = yes" server option should ensure that the server announces itself over this protocol. Is avahi-daemon.service enabled on the server? I think this is currently the only way to achieve that without the NT1 protocol. - WS-Discovery - This is used by Windows 10 machines, but it is not yet supported in GNOME. However, work on this functionality already started: https://gitlab.gnome.org/GNOME/gvfs/-/issues/506.
Please allow me to answer, as the topicstarter. 1)Actually, direct access using IP, or SMB name is possible from Nautilus, but it requires installing Gnome tweaks, and tweaking it for showing the editable address box. So from a new desktop user perspective that is quite complicated. 2)It makes (1) more complicated that the default blank address line there is deceptively offered as "smb:///", which prevents accessing when continuing it as "smb:///ip-address", or "smb:///NBT-NAME". One "/" should be stripped out from the default address. Now closer to the real problem: 3) > NetBIOS: - Yes, "NT1" is not allowed in smbd. I am not sure why it automatically prevents nmbd from collecting netbios_name-broadcasts. For Windows machines it is not an obstacle. > mDNS: The "multicast dns register = yes" server option is present in sbb.conf. So theoretically it should work. But it does not. >Is avahi-daemon.service enabled on the server? systemctl list-units | grep avahi avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack avahi-daemon.socket loaded active running Avahi mDNS/DNS-SD Stack Activation Socket >WS-Discovery systemctl list-units | grep wsdd wsdd.service loaded active running Web Services Dynamic Discovery host daemon So, from 3 said methods, 2 methods should provide the "network discovery" functionality to Nautilus. And the first method should actually keep working, by common sense, because it is not related do file-serving. But Nautilus becomes completely blind when "server min protocol = SMB2"
there is a typo: sbb.conf ->smb.conf
Thanks for your response. > 1)Actually, direct access using IP, or SMB name is possible from Nautilus, > but it requires installing Gnome tweaks, and tweaking it for showing the > editable address box. So from a new desktop user perspective that is quite > complicated. It is definitely not necessary to install GNOME Tweak for this purpose: - The preferred way is to open "Other Locations" from the GNOME Files sidebar and enter the address in the "Connect to Server" bottom bar. - You can also use "Ctrl+L" to show the location entry temporarily. > 3) > > NetBIOS: > - Yes, "NT1" is not allowed in smbd. I am not sure why it automatically > prevents nmbd from collecting netbios_name-broadcasts. For Windows machines > it is not an obstacle. I am convinced that it is because Windows is using WS-Discovery for this purpose, not NetBIOS discovery (see https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). This is also the reason, why you need wsdd service to see the RHEL devices there. We could backport the following upstream change that forces NT1 usage on the client side (https://gitlab.gnome.org/GNOME/gvfs/-/commit/6c8bc39f570ea82cf14e83ce7d1dbdbe569d09d1), but it still needs to be allowed on the server, however, I suppose that's not what you want. > > mDNS: > The "multicast dns register = yes" server option is present in sbb.conf. So > theoretically it should work. But it does not. > >Is avahi-daemon.service enabled on the server? > systemctl list-units | grep avahi > avahi-daemon.service loaded active running Avahi > mDNS/DNS-SD Stack > avahi-daemon.socket loaded active running Avahi > mDNS/DNS-SD Stack Activation Socket We have to find out why it doesn't work because I think this is the only way for now until WS-Discovery support is implemented. Maybe firewall is blocking it, can you please try "firewall-cmd --add-service=mdns"? Does "avahi-browse _smb._tcp" shows something then?
>It is definitely not necessary to install GNOME Tweak Oh. Ok. You know such tricks. >I am convinced that it is because Windows is using WS-Discovery Apparently. And probably multiple methods at once because it also sees Printers, Routers, and media devices. >firewall-cmd --add-service=mdns Got it! It did not work with reloading the firewall, but after rebooting it was fixed! Thank you! Sorry for bringing it to the bug tracker. Just a not obvious configuration step. //I hope to see WSD support preconfigured in future distributions because, well, it is an essential thing nowadays. BTW >avahi-browse _smb._tcp no such command. Is it a wrong behaviour?
SORRY. It is not over yet. Resources appeared in "other locations". But not in the "Windows networks". So I see an incomplete list generally build of ARMADILLO devices.
P.S. Windows10 on the other hand does not see Armadillo devices. So this situation is completely bizzare; I can not even guess why, byt it is completely wrong.
> >avahi-browse _smb._tcp > no such command. Is it a wrong behaviour? The avahi-tools package needs to be installed first. But if you see those devices in the "Other Locations" view now, then its output is irrelevant. > Resources appeared in "other locations". > > But not in the "Windows networks". This is how it works currently. All discovered mDNS services from the local domain are shown directly in the "Other Locations" view. The "Windows Network" folder is purely NetBIOS based, so it is expected that it is empty. > So I see an incomplete list generally build of ARMADILLO devices. If something is missing, then it probably doesn't advertise itself over mDNS? Does it?
yum install avahi-tools Updating Subscription Management repositories. Last metadata expiration check: 2:28:07 ago on 2023年07月04日 15時39分10秒. No match for argument: avahi-tools Error: Unable to find a match: avahi-tools Is it the official RHEL8 repository? I have epel enabled. >This is how it works currently. So, it still does not see ANY Windows 10~11 machine in the network. Naturally, all the Win10~11 have NT1 removed by default. But they see each other! And I see the same Win10~11 machines from Nautilus when "min server protocol = NT1" This makes no sense and is completely wrong.
To make this clear: Config↓ Sees→ self RHEL Win Armadillo Printer Media SAMBA min SMB2 O ? x O x x SAMBA min NT1 O ? O O x x Windows 10 O O Same WG x O O You see, it is not right.
> > So I see an incomplete list generally build of ARMADILLO devices. > > If something is missing, then it probably doesn't advertise itself over mDNS? Does it? I've spent some time looking at whether Microsoft supports mDNS to announce its services, but it seems it doesn't not currently, unfortunately. Although it seems they are working on it (see https://www.ctrl.blog/entry/windows-mdns-dnssd.html). But I am convinced that there must be some third-party solution to achieve that... > yum install avahi-tools > Updating Subscription Management repositories. > Last metadata expiration check: 2:28:07 ago on 2023年07月04日 15時39分10秒. > No match for argument: avahi-tools > Error: Unable to find a match: avahi-tools > > Is it the official RHEL8 repository? I have epel enabled. I thought it should be part of the AppStream repository, hmm. > And I see the same Win10~11 machines from Nautilus when "min server protocol > = NT1" So it seems it is not fully disabled on the server and then the https://gitlab.gnome.org/GNOME/gvfs/-/commit/6c8bc39f570ea82cf14e83ce7d1dbdbe569d09d1 change should help here. Would you be interested to have this backported to RHEL?
When I was researching, I had an impression that starting from some later subreleases of Windows 10x64, around 2020, mDNS is supported both ways. Not in x86 version. BTW, with Armadillo, it seems that it is a Linux without wsdd, so it does not appear in Windows 10. So, even if Windows doese not broadcast mDNS for some reason, it should do the same work with WSD, and wsdd is installed in our RHEL8. Does it mean that Nautilus does not support WSD based discovery, or wsdd does not provide the data to Avahi, or is current Nautilus release broken?
As I wrote in comment 4 already, WSD is not yet supported by GNOME/Nautilus. The wsdd daemon just makes the Linux device visible but doesn't work the other way around.
Yes. Thank you for explaining. But I should point it out again, https://techcommunity.microsoft.com/t5/networking-blog/mdns-in-the-enterprise/ba-p/3275777 "Starting with Windows 10 1703 (released on April 5, 2017) Microsoft has included native support for multicast DNS, or mDNS." So, multiple articles state that mDNS is actually supported by windows and should work. Some older state that it is supported only in x64 version, but later articles do not mention any CPU command-set relation. I guess, there is somenting with compatibility.