Navigation section

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

mute09

mute09

Member
Joined
Sep 11, 2025
Messages
4
Problem Summary
The Samba server on Debian Trixie did not appear automatically in Windows Network Explorer, unlike on Armbian Bookworm + OMV which appeared directly and prompted for credentials.

Root Cause Analysis
Environmental Differences:
Windows 11 24H2 (OS build 26100.6584)
Debian: Samba 4.22.3, manual configuration
Armbian Bookworm + OMV 7.xx: Samba 4.17.12, managed by OMV with special configuration

Key Findings:
OMV uses "configuration deception" - multicast dns register = no in smb.conf but avahi-daemon is actively running

OMV appears due to avahi/zeroconf, not NetBIOS

Windows 10/11 prefers mDNS over NetBIOS for network discovery

Implemented Solutions
Samba Configuration on Debian:
ini
[global]
workgroup = WORKGROUP
netbios name = LENOVO
security = user
map to guest = Bad User
client min protocol = NT1
server min protocol = NT1
local master = yes
preferred master = yes
os level = 65

[downloads]
path = /srv/data/downloads
browseable = yes
read only = no
guest ok = no
valid users = user
force user = user
Steps Taken:
User management: sudo smbpasswd -a user

Permission setup: chown -R user:user /srv/data/downloads

Avahi installation: sudo apt install avahi-daemon avahi-utils

Windows credential cleanup in Credential Manager

Achieved Results
Authentication working - credential prompt appears

Share accessible via \\LENOVO or \\[ipaddress]

Read/write access functions properly

Network discovery still requires manual initial access

Key Insights
Modern Windows prefers mDNS over NetBIOS

OMV uses avahi even though config shows mDNS disabled

Windows caching behavior affects network discovery

Samba version differences affect compatibility

Conclusion
Lenovo now works with proper security (requires authentication) even though it doesn't appear automatically in the network list. For automatic appearance like Rock-3A, further investigation is needed into how OMV manipulates avahi and Samba behavior.

Current state: Secure and functional, though requires manual initial access via \\LENOVO.

My target is to duplicate the behavior of smb managed by OMV, I ask for an explanation or solution from seniors, please
 

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.
 

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...
Implemented Suggestions from the AI Forum
Installation of WSDD (Web Services Dynamic Discovery)

Download and install wsdd manually

Bash: 
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

Create a systemd service
sudo nano /etc/systemd/system/wsdd.service
Contents of wsdd.service:
INI: 
[Units]
Description=Web Services Dynamic Discovery host
After=network. target

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

[Install]
WantedBy=multi-user.target
2. Firewall configuration
Bash: 
Open the WSDD port
sudo ufw allow 3702/udp
sudo ufw allow 5357/tcp
sudo ufw allow 5358/tcp

Implementation Results
WSDD Status: SUCCESS
Bash: 
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

Observed Results
What HAS SUCCESSED:
WSDD service is running perfectly

Port is open and listening

Samba remains accessible via \\LENOVO manually

Authentication prompt works normally

What HAS NOT SUCCESSFUL:
Server does not appear automatically in Network Explorer

Still requires manual access via the address bar
 

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 …).
 

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​

INI: 
[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​

Bash: 
# 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​

✅ WSDD2 running and sending multicast packets
✅ Port 445 accessible from Windows
✅ ARP resolution working (192.168.100.25 reachable)
✅ Function Discovery services running on Windows
✅ Firewall disabled for testing

From Debian (Lenovo):​

Bash: 
# 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:​

Code: 
# 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​

✅ Basic Functions Working:

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

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

Nice work—everything points to discovery traffic not completing, not Samba. Let’s zero in on WS‑Discovery path end‑to‑end.
Checklist (in order)
1) Prove Windows probes reach Debian
  • 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.
2) If no probes are seen → fix L2 multicast on your LAN
  • 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.
3) If probes are seen → ensure wsdd responds on the correct NIC and stacks
  • 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.
4) Cover IPv6 as well
  • 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.
5) Windows-side confirmations
  • 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.
6) Try the other daemon if responses look wrong
  • 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.
7) Edge cases that break discovery
  • 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.
If you run step 1 and share the tcpdump snippet when you open Explorer > Network, we can tell in one pass whether it’s the LAN dropping multicast or the daemon not replying.
 

You must log in or register to reply here.
Back
Top