Warum Windows Samba-Server unsichtbar macht

Frische Umsteiger auf Windows 11 wundern sich aktuell, warum ihre Netzwerk-Shares auf NAS- oder Linux Samba-Servern¹ nicht mehr in der Netzwerkumgebung erscheinen. Es geht nur um die Sichtbarkeit. Bei direkter Eingabe eines Shares funktioniert alles reibungslos.

Es ist kompliziert - the Microsoft Way

Die Ursache liegt in der Netzwerk-Discovery und ich muß etwas weiter ausholen, bis ich zur Lösung komme.

Es ist auffallend, wie Microsoft in den vergangenen Jahrzehnten hier nie eine klare Linie entwickelt hat. Bis Windows 10 (1709) existierte ein bunter Strauß von Diensten und Protokollen, die alle thematisch etwas mit der Netzwerk-Discovery zu tun hatten, zugleich aber auch wieder nicht. Es ist kompliziert, schon gar nicht intuitiv oder konsistent:

• NetBIOS/SMBv1 Dienst²
• Simple Service Discovery Protocol (SSDP)³
• Universal Plug and Play Device Host (UPnP)⁴
• Link-Local Multicast Name Resolution (LLMNR)⁵
• Function Discovery Resource Publication (FDRP) oder “FD-Services”⁶
• Web Services for Devices (WSD), WS-Discovery mit der zugehörigen WSDAPI⁷

Für die Sichtbarkeit von Rechnern und Freigaben in der Netzwerkumgebung relevant sind NetBIOS, LLMNR, FDRP und WSD. Die übrigen sind eher für Audio- und Videogeräte wichtig. Mit Windows 10 (1709) begann Microsoft, NetBIOS/SMBv1 nicht mehr als Standard zu installieren. Parallel wird inzwischen ausdrücklich empfohlen, LLMNR zu deaktivieren.⁸

WSD ist de facto Windows-only

Web Services for Devices (WSD) ist formal ein offenes Protokoll und könnte von jedem implementiert werden. Es gibt aber gute Gründe, warum das niemand macht. Mit seinem Overhead an SOAP und XML und viel Legacy ist WSD technisch betrachtet in den frühen 2000er Jahren stecken geblieben. Für kleine und mittlere Netze ist es überdimensioniert, zu komplex und trägt ein inhärent großes Parsing- und Implementierungsrisiko. Best Practice in Enterprise-Netzen für das Hardening ist die Deaktivierung.⁹

Außerhalb der Windows-Blase nutzt es kaum jemand. Linux, MacOS, Unix und auch nahezu alle Hersteller von Webcams, Storages und sonstigen IoT-Netzwerkgeräten setzen alle auf RFC-standardisierte Zeroconf-Methoden,¹⁰ namentlich sind es mDNS, Bonjour oder Avahi,¹¹ die auf Multicast-Mechanismen setzen.¹²

Warum Microsoft sich gegen alle positioniert hat, muss man nicht verstehen. Ein schönes Beispiel für die “not-invented-here” Fallacy.¹³ Im letzten Moment sprang Microsoft mit Windows 10 (1709) schliesslich doch noch auf den mDNS-Standard auf. Ganz Microsoft-typisch unvollständig und nicht zu Ende gedacht.¹⁴ Denn obwohl mDNS SMB-Server und Shares in der Netzwerkumgebung sichtbar machen könnte, nutzt Microsoft es nicht.¹⁵ Diese Funktionalität bleibt FDRP vorbehalten, und das auch nur für Windows-Geräte. Andere Geräte und Systeme mit Samba werden ignoriert. Wie geschrieben, es ist kompliziert.

Das Bindeglied zwischen Samba und Windows

Hier kommt das Paket wsdd ins Spiel. Es macht Samba-Server und die auf diesen befindlichen Shares in der Windows-Netzwerkumgebung wieder sichtbar.¹⁶

Vorteil dieser eleganten Lösung: Sowohl die Samba-Konfiguration als auch die Windows-Systeme müssen nicht angepasst werden. Es genügt, wsdd aus dem Standard-Repository der jeweiligen Linux-Distribution zu installieren, Port 3702/UDP in der Firewall freizugeben und mit systemctl unter einem nicht‑privilegierten Dienstkonto zu aktivieren.

Hanlon oder nicht?

Microsoft hat in den letzten Jahren fast alle traditionellen Discovery-Mechanismen abgeschafft. Das ist auch gut so. Leider hat Microsoft es versäumt, eine konsistente Alternative zu schaffen. Gängige Internetstandards werden im Jahr 2025 nicht vollständig unterstützt und lassen Linux-Samba-Server aus den Netzwerkumgebungen der Anwender verschwinden. Absicht oder Inkompetenz, das muss Hanlon entscheiden.¹⁷

In diesem Sinne,
Euer Tomas Jakobs