mute09
Member
- Joined
- Sep 11, 2025
- Messages
- 4
- Thread Author
-
- #1
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
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
Solution
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...
- Joined
- Mar 14, 2023
- Messages
- 97,306
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
- If you use UFW:
(If you don’t run a firewall, nothing else to do.Code:sudo ufw allow 3702/udp sudo ufw allow 5357/tcp sudo ufw allow 5358/tcp
- 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.
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
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).
- On OMV: run
- Ensure the hostname is unique on your LAN (no other device named LENOVO).
- Try forcing the interface:
sudo systemctl edit wsddand add an override likeExecStart=/usr/bin/wsdd -i eth0 -H LENOVO(replace interface/hostname), thensystemctl daemon-reload && systemctl restart wsdd. - Temporarily stop UFW to rule out firewall:
sudo ufw disable(test, then re‑enable).
mute09
Member
- Joined
- Sep 11, 2025
- Messages
- 4
- Thread Author
-
- #3
Implemented Suggestions from the AI ForumShort 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)
2) Open firewall for WSD
- 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
3) Keep Avahi if you like
- If you use UFW:
(If you don’t run a firewall, nothing else to do.)Code:sudo ufw allow 3702/udp sudo ufw allow 5357/tcp sudo ufw allow 5358/tcp
4) Fix your Samba security baseline (remove SMB1)
- 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.
Your current min protocol lines enable SMB1 (NT1). Replace them:
Then: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
Code:sudo testparm sudo systemctl restart smbd nmbdWhat to expect and how to verify
If it still doesn’t appear:
- 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).
That setup will duplicate OMV’s behavior while keeping modern, secure SMB.
- Ensure the hostname is unique on your LAN (no other device named LENOVO).
- Try forcing the interface:
sudo systemctl edit wsddand add an override likeExecStart=/usr/bin/wsdd -i eth0 -H LENOVO(replace interface/hostname), thensystemctl daemon-reload && systemctl restart wsdd.- Temporarily stop UFW to rule out firewall:
sudo ufw disable(test, then re‑enable).
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
- Joined
- Mar 14, 2023
- Messages
- 97,306
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)
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).
- 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 …).
mute09
Member
- Joined
- Sep 11, 2025
- Messages
- 4
- Thread Author
-
- #5
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)
Quick diagnostics (watch these while opening File Explorer > Network):
- 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).
If it still won’t list:
- 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 …).
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
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
- 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
- Joined
- Mar 14, 2023
- Messages
- 97,306
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
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.
- 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.