Windows 11 Fails to Discover Samba Server in "Network", but Manual Access Works

Short answer​

Do this on Debian Trixie​

• Option A (wsdd, most common):
  
  Code:

  sudo apt update
  sudo apt install wsdd
  sudo systemctl enable --now wsdd

• Option B (if your repo offers wsdd2):
  
  Code:

  sudo apt install wsdd2
  sudo systemctl enable --now wsdd2

• Verify it’s running:
  systemctl status wsdd # or wsdd2

• If you use UFW:
  
  Code:

  sudo ufw allow 3702/udp
  sudo ufw allow 5357/tcp
  sudo ufw allow 5358/tcp

  (If you don’t run a firewall, nothing else to do.)

• Avahi is optional for Windows. It gives you hostname.local and helps Macs, but Windows “Network” listing comes from wsdd. No harm leaving Avahi enabled.

[global]
workgroup = WORKGROUP
server string = Lenovo Samba
security = user
map to guest = Bad User

# Modern dialects
client min protocol = SMB2
server min protocol = SMB2
# Optional hardening on recent Samba:
# disable netbios = yes

# (keep your shares as-is)
[downloads]
path = /srv/data/downloads
browseable = yes
read only = no
guest ok = no
valid users = user
force user = user

sudo testparm
sudo systemctl restart smbd nmbd

What to expect and how to verify​

• Within 10–90 seconds after wsdd starts, your server should appear under “Network” in File Explorer without needing manual \LENOVO first.
• Quick checks:
  • On OMV: run systemctl status wsdd* and you’ll likely see its wsdd service—this is the “magic” you observed.
  • On Windows (already works for OMV, so you’re fine): ensure “Network discovery” is on and Services “Function Discovery Provider Host” and “Function Discovery Resource Publication” are running (they usually are by default in Win11).

• Ensure the hostname is unique on your LAN (no other device named LENOVO).
• Try forcing the interface: sudo systemctl edit wsdd and add an override like ExecStart=/usr/bin/wsdd -i eth0 -H LENOVO (replace interface/hostname), then systemctl daemon-reload && systemctl restart wsdd.
• Temporarily stop UFW to rule out firewall: sudo ufw disable (test, then re‑enable).

ChatGPT said:

Short answer​

To make your Debian Trixie box show up automatically under Network in Windows 10/11 like OMV does, you need WS‑Discovery (WSD) on the Linux side. OMV runs a wsdd/wsdd2 service out of the box. Avahi/mDNS helps name resolution (hostname.local), but it’s wsdd that actually makes “Computer” entries appear in File Explorer on modern Windows (NetBIOS/SMB1 browsing is deprecated).

Do this on Debian Trixie​

1) Install and enable wsdd (or wsdd2)

• Option A (wsdd, most common):
  
  Code:

  sudo apt update
  sudo apt install wsdd
  sudo systemctl enable --now wsdd

• Option B (if your repo offers wsdd2):
  
  Code:

  sudo apt install wsdd2
  sudo systemctl enable --now wsdd2

• Verify it’s running:
  systemctl status wsdd # or wsdd2

2) Open firewall for WSD

• If you use UFW:
  
  Code:

  sudo ufw allow 3702/udp
  sudo ufw allow 5357/tcp
  sudo ufw allow 5358/tcp

  (If you don’t run a firewall, nothing else to do.)

3) Keep Avahi if you like

• Avahi is optional for Windows. It gives you hostname.local and helps Macs, but Windows “Network” listing comes from wsdd. No harm leaving Avahi enabled.

4) Fix your Samba security baseline (remove SMB1)
Your current min protocol lines enable SMB1 (NT1). Replace them:

Code:

[global]
workgroup = WORKGROUP
server string = Lenovo Samba
security = user
map to guest = Bad User

# Modern dialects
client min protocol = SMB2
server min protocol = SMB2
# Optional hardening on recent Samba:
# disable netbios = yes

# (keep your shares as-is)
[downloads]
path = /srv/data/downloads
browseable = yes
read only = no
guest ok = no
valid users = user
force user = user

Then:

Code:

sudo testparm
sudo systemctl restart smbd nmbd

What to expect and how to verify​

• Within 10–90 seconds after wsdd starts, your server should appear under “Network” in File Explorer without needing manual \LENOVO first.
• Quick checks:
  • On OMV: run systemctl status wsdd* and you’ll likely see its wsdd service—this is the “magic” you observed.
  • On Windows (already works for OMV, so you’re fine): ensure “Network discovery” is on and Services “Function Discovery Provider Host” and “Function Discovery Resource Publication” are running (they usually are by default in Win11).

If it still doesn’t appear:

• Ensure the hostname is unique on your LAN (no other device named LENOVO).
• Try forcing the interface: sudo systemctl edit wsdd and add an override like ExecStart=/usr/bin/wsdd -i eth0 -H LENOVO (replace interface/hostname), then systemctl daemon-reload && systemctl restart wsdd.
• Temporarily stop UFW to rule out firewall: sudo ufw disable (test, then re‑enable).

That setup will duplicate OMV’s behavior while keeping modern, secure SMB.

Click to expand...

wget https://github.com/christgau/wsdd/archive/refs/tags/v0.7.0.tar.gz
tar -xzf v0.7.0.tar.gz
cd wsdd-0.7.0
sudo cp src/wsdd.py /usr/bin/wsdd
sudo chmod +x /usr/bin/wsdd

[Units]
Description=Web Services Dynamic Discovery host
After=network. target

[Service]
Type=simple
ExecStart=/usr/bin/wsdd -i eth0 -4
Restart=always
RestartSec=5

Open the WSDD port
sudo ufw allow 3702/udp
sudo ufw allow 5357/tcp
sudo ufw allow 5358/tcp

wsdd.service - Web Services Dynamic Discovery host 
Loaded: loaded (/etc/systemd/system/wsdd.service; enabled; preset: enabled) 
Active: active (running)
Port Listening: SUCCESS
text
tcp [ipaddress]:5357 0.0.0.0:* LISTEN
udp [ipaddress]:3702 0.0.0.0:*
Firewall: SUCCESS
Ports 3702/udp, 5357/tcp, 5358/tcp are open

• sudo systemctl disable --now wsdd
• sudo rm /etc/systemd/system/wsdd.service
• sudo systemctl daemon-reload
  2) Install a packaged daemon (recommended: wsdd2, same idea OMV uses)
• sudo apt update
• sudo apt install wsdd2
• sudo systemctl enable --now wsdd2
  3) Or, if you prefer christgau’s wsdd, use this minimal unit
• sudo nano /etc/systemd/system/wsdd.service
  [Unit]
  Description=WS-Discovery host daemon
  After=network-online.target
  Wants=network-online.target
  [Service]
  ExecStart=/usr/bin/wsdd --hostname LENOVO --workgroup WORKGROUP -v
  Restart=on-failure
  [Install]
  WantedBy=multi-user.target
• sudo systemctl daemon-reload && sudo systemctl enable --now wsdd
  Notes:
• Don’t force “-i eth0” unless you’re sure that’s the real name (use ip -o link). Let it bind to all ifaces first.
• Don’t force “-4”; Windows often probes via IPv6. Keep IPv6 enabled on both ends.
• Keep UFW allows for 3702/udp and 5357/tcp (5358/tcp optional).

• sudo journalctl -u wsdd* -f → You should see “Probe from <Windows IP>”.
• sudo tcpdump -ni <iface> udp port 3702 → You should see multicast to 239.255.255.250.
• ip maddr show dev <iface> → Ensure 239.255.255.250 is listed.
  If you see probes hitting OMV but not Debian, it’s either the wrong iface (-i) or the daemon didn’t join the multicast group (fixed by the unit above). If probes are seen and replies are logged, refresh Windows’ discovery: ensure the network profile is Private and the services “Function Discovery Provider Host” and “Function Discovery Resource Publication” are Running, then close all Explorer windows and re-open Network (or restart those two services). Give it 30–90 seconds—your “LENOVO” should appear under Computers without first doing \LENOVO.

• Ensure hostname uniqueness (only one LENOVO on the LAN).
• Try the other daemon (switch wsdd ↔ wsdd2; don’t run both).
• On multi-NIC or Docker hosts, pin the correct NIC only after you’ve confirmed its name (ExecStart=/usr/bin/wsdd -i enp3s0 …).

ChatGPT said:

Great progress—you’ve got the hard parts done. When wsdd is “running” but the PC still doesn’t show under Network, it’s almost always one of these: wrong NIC binding, IPv6-only probes being ignored, or a flaky custom systemd unit.
Try this clean, known‑good setup (no interface pinning, no IPv4‑only):
1) Remove your handcrafted service (to avoid conflicts)

• sudo systemctl disable --now wsdd
• sudo rm /etc/systemd/system/wsdd.service
• sudo systemctl daemon-reload
  2) Install a packaged daemon (recommended: wsdd2, same idea OMV uses)
• sudo apt update
• sudo apt install wsdd2
• sudo systemctl enable --now wsdd2
  3) Or, if you prefer christgau’s wsdd, use this minimal unit
• sudo nano /etc/systemd/system/wsdd.service
  [Unit]
  Description=WS-Discovery host daemon
  After=network-online.target
  Wants=network-online.target
  [Service]
  ExecStart=/usr/bin/wsdd --hostname LENOVO --workgroup WORKGROUP -v
  Restart=on-failure
  [Install]
  WantedBy=multi-user.target
• sudo systemctl daemon-reload && sudo systemctl enable --now wsdd
  Notes:
• Don’t force “-i eth0” unless you’re sure that’s the real name (use ip -o link). Let it bind to all ifaces first.
• Don’t force “-4”; Windows often probes via IPv6. Keep IPv6 enabled on both ends.
• Keep UFW allows for 3702/udp and 5357/tcp (5358/tcp optional).

Quick diagnostics (watch these while opening File Explorer > Network):

• sudo journalctl -u wsdd* -f → You should see “Probe from <Windows IP>”.
• sudo tcpdump -ni <iface> udp port 3702 → You should see multicast to 239.255.255.250.
• ip maddr show dev <iface> → Ensure 239.255.255.250 is listed.
  If you see probes hitting OMV but not Debian, it’s either the wrong iface (-i) or the daemon didn’t join the multicast group (fixed by the unit above). If probes are seen and replies are logged, refresh Windows’ discovery: ensure the network profile is Private and the services “Function Discovery Provider Host” and “Function Discovery Resource Publication” are Running, then close all Explorer windows and re-open Network (or restart those two services). Give it 30–90 seconds—your “LENOVO” should appear under Computers without first doing \LENOVO.

If it still won’t list:

• Ensure hostname uniqueness (only one LENOVO on the LAN).
• Try the other daemon (switch wsdd ↔ wsdd2; don’t run both).
• On multi-NIC or Docker hosts, pin the correct NIC only after you’ve confirmed its name (ExecStart=/usr/bin/wsdd -i enp3s0 …).

Click to expand...

IMPLEMENTED​

1. Samba Configuration​

[global]
workgroup = WORKGROUP
netbios name = LENOVO
security = user
map to guest = Bad User
client min protocol = SMB2
server min protocol = SMB2

[downloads]
path = /srv/data/downloads
browseable = yes
read only = no
guest ok = no
valid users = muthi
force user = muthi

2. WS-Discovery (WSDD2) Setup​

# Installation
sudo apt install wsdd2
sudo systemctl enable --now wsdd2

# Firewall rules
sudo ufw allow 3702/udp
sudo ufw allow 5357/tcp
sudo ufw allow 5358/tcp

3. Successful Verifications​

From Debian (Lenovo):​

# WSDD2 sending multicast packets
$ sudo tcpdump -ni enp0s31f6 udp port 3702
09:37:40.800285 IP 192.168.100.25.33262 > 239.255.255.250.3702: UDP, length 651

From Windows:​

# Samba connection successful
PS> Test-NetConnection -ComputerName 192.168.100.25 -Port 445
TcpTestSucceeded : True

# ARP resolution working
PS> Get-NetNeighbor -AddressFamily IPv4 | Where-Object IPAddress -like "192.168.100.25"
IPAddress       LinkLayerAddress      State
---------       ----------------      -----
192.168.100.25  6C-4B-90-32-70-23     Reachable

Current State​

• Manual access via \\LENOVO → credential prompt appears
• Read/write access normal
• Authentication working

• Server does not appear automatically in Network Explorer
• Must access manually via address bar

• On Debian (pick the NIC you actually use, e.g., enp0s31f6):
  • sudo tcpdump -ni enp0s31f6 udp port 3702 and host 239.255.255.250
  • Now open File Explorer > Network on Windows and wait 30–60s.
    You should see packets from your Windows IP → 239.255.255.250:3702. If you only see Debian sending to 239.255.255.250 (Hello/Bye) and no probes from Windows, multicast to Debian is being blocked.

• Same L2 segment/VLAN: ensure Windows and Debian are on the exact same subnet (no routing/NAT/VM NAT).
• Wi‑Fi AP/router settings:
  • Disable “AP/client isolation,” “Wireless isolation,” or “guest network” for that SSID.
  • IGMP snooping: either disable it or enable an IGMP querier on the VLAN. Misconfigured snooping commonly drops 239.255.255.250.
  • “Multicast enhancement/DTIM/Airtime fairness” features can also interfere—toggle off to test.
• Quick A/B test: plug the Windows PC into Ethernet on the same switch as Debian. If it appears, the Wi‑Fi path is the culprit.

• Increase verbosity and pin the correct interface once you’ve confirmed its name:
  • sudo systemctl edit wsdd2
  • Add:
  • [Service]
  • ExecStart=
  • ExecStart=/usr/sbin/wsdd2 -i enp0s31f6 -n LENOVO -w WORKGROUP -v
  • sudo systemctl daemon-reload && sudo systemctl restart wsdd2
• Watch logs while opening Explorer > Network:
  • sudo journalctl -u wsdd2 -f
  • Expect lines indicating “Probe/Resolve from <Windows IP>” and “sending response”.
• Check multicast group join:
  • ip maddr show dev enp0s31f6 → should include 239.255.255.250.

• Windows often probes over IPv6 first.
• Verify Debian sees IPv6 probes:
  • sudo tcpdump -ni enp0s31f6 ip6 and udp port 3702
• Ensure UFW isn’t blocking v6 (ufw default is v6=yes). If needed:
  • sudo ufw allow proto udp to any port 3702
  • sudo ufw allow proto tcp to any port 5357
• Do not disable IPv6 on either side during testing.

• Network profile must be Private:
  • Settings > Network & Internet > Properties > set Network profile = Private.
• Services:
  • Function Discovery Provider Host and Function Discovery Resource Publication = Running (restart them).
• Firewall rule:
  • Inbound rule “Network Discovery (WSD-In)” enabled for Private. Even with firewall off you tested, re‑enable it properly for normal use.

• Stop wsdd2 and try the Python one (many OMV setups use it):
  • sudo apt install wsdd
  • sudo systemctl disable --now wsdd2
  • sudo systemctl enable --now wsdd
  • journalctl -u wsdd -f while opening Explorer > Network
• Don’t run both at once.

• Multiple NICs/bridges (Docker, VMs): bind wsdd/wsdd2 to the LAN NIC only (-i enp0s31f6).
• Duplicate hostname on LAN (another LENOVO).
• VM with NAT networking: WS‑Discovery will not traverse NAT; use bridged networking.