Bug 2218401

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.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.