Windows ist ein ziemlich altes Betriebssystem, das etliche Wandlungen unterworfen wurde. Zwar wird Kompatibilität groß geschrieben - was durchaus Vorteile bei Updates mit sich bringt - allerdings auch Nachteile beinhaltet. Microsoft beendet gerne Kompatibilität, wenn es um Sicherheitsbedenken geht. Genau dieses Problem ereilt Windows-Benutzer, wenn sie auf Linux-Server zugreifen möchten, auf denen Samba ihre Verzeichnisse offerieren. Eine Verbindung zu derartigen Freigaben ist meist problemlos möglich, allerdings sind die Server in der Netzwerkumgebung ohne besondere Konfiguration in der Netzwerkumgebung von Windows 10 und 11 nicht sichtbar.
Das Problem ist die Methode, wie Windows bisher und aktuell Rechner im Netzwerk findet. Während alte Versionen sich auf Netbios verließen, wirft Windows spätestens seit Version 10 dieses Vorgehen über Bord. Netbios wurde in früheren SMB-Versionen verwendet und ist in aktuellen Samba-Servern enthalten. Doch was nützt ein Protokoll, welches heute nicht mehr unterstützt wird?
Windows 10 und 11 nutzen neuerdings den Web Discovery Service, der völlig unabhängig vom SMB-Protokoll ist und deshalb auch nicht in Samba enthalten. Es existiert jedoch ein eigener Daemon, der diese Funktion nachrüstet. Er ist in den Repositories von OpenSuSE enthalten und muss per Myrlyn oder zypper installiert werden. Die Crux liegt nicht in der Konfiguration dieses Dienstes, der gut in OpenSuSE integriert ist, sondern in der Konfiguration einer Firewall in Form von firewalld. Zur Installation öffnet man ein Terminalfenster und gibt
zypper in wdss
ein. Damit wird der benötigte Dienst grundsätzlich auf den Server verfrachtet. Die Konfiguration des Dienstes beschränkt sich auf die Datei /etc/sysconfig/wsdd. Hier muss die Workgroup oder Domain eingetragen werden, die Samba aufspannt. Achtung: für Workgroup und Domain gibt es separate Einträge und nur einer sollte verwendet werden. Da in heutigen Servern meist noch virtuelle Maschinen oder Docker-Container laufen, ist es fast unumgänglich, auch die Netzwerkschnittstelle zu definieren, auf denen der Dienst laufen soll. Virtuelle Schnittstellen (tun/tap) von OpenVPN sollten ausgesperrt bleiben, da das zu Fehlfunktionen führen kann. Hinterlistig ist Windows auch in der Art der Auflösung. Beim Starten des Dienstes "posaunt" der WDSS-Dienst seinen Namen per Broadcast ins Netz. Somit bekommt Windows davon Kenntnis. Allerdings ist der Initiator beim Refresh oder nach einem Reboot des Windows-Clients Windows alleine. Dafür wird ein anderer Weg beschritten, der über Multicast abgewickelt wird. Ist dieser Weg nicht richtig konfiguriert, verschwindet der Linux-Server wieder aus der Auflistung, weil er sich nicht meldet.
Nun geht es an die Konfiguration des Dienstes wdss in der Firewall. Unter den Diensten sind einige Einträge vordefiniert, die freigeschaltet werden müssen:

Wer sich auf diese Einträge beschränkt, der findet zukünftig seinen Server nur einmalig in der Netzwerkumgebung von Windows-Clients, nämlich wenn der Dienst das erste Mal gestartet wird. Nach einem Reboot des Windows-Clients oder einem manuellen Refresh der Netzwerkumgebung ist dieser wieder unsichtbar.
Als nächstes muss das Protokoll igmp freigeschaltet werden. Dazu wird auf den Reiter Protokolle gewechselt und das Protokoll über Hinzufügen eingerichtet:

Im nächsten Schritt muss das Multicast-Routing in der Firewall konfiguriert werden. Dazu dient der Reiter Umfassende Regeln:

Da der aufploppende Konfigurationsdialog beim Drücken von Hinzufügen komplizierter aufgebaut ist, hier die Einstellungen in diesem Dialog:

Das muss für die UDP-Ports 3702 und 37020 gleichermaßen eingefügt werden.
Zum Abschluss müssen noch Quellports freigeschaltet werden. Dazu wird auf den Reiter Quellports umgeschaltet und diese 4 Einträge hinzugefügt:

Jetzt muss das ganze in die permanente Umgebung übernommen werden. Dazu dient im Menü Optionen - Runtime auf dauerhaft:

Damit ist die Konfiguration des Firewalld-Dienstes erledigt und wird können uns dem Start des Dienstes zuwenden:
Um den Dienst zu aktivieren, d. h. auch nach dem nächsten System-Reboot des Servers automatisch zu starten ist in einem Terminal die folgende Zeile zu benutzen:
sudo systemctl enable wsdd
Zum eigentlichen Start wird die Zeile
sudo systemctl start wsdd
verwendet. Ob der Dienst läuft und das auch fehlerfrei zeigt die Zeile
sudo systemctl status wsdd

Zur Überprüfung, ob alles reibungslos verlaufen ist, öffne nun auf einem Windows10/11-Rechner die Netzwerkumgebung. Der Rechner sollte jetzt in der Umgebung angezeigt werden. Dann einen Refresh ausführen und prüfen, ob der Rechner weiterhin in der Liste angezeigt wird.
