felhom.eu/REPORT-diag-sharing-2026-07-20.md

REPORT — Megosztás diagnosis (2026-07-20)

Topic-scoped report (parallel-session rule: shared REPORT.md untouched).

Run: RUNBOOK "Megosztás diagnosis — SMB unreachable from Mac + sharing-page reload loop". Read-only diagnosis. No code changes, no version bumps, no builds, no restarts.

Deliverable: documentation/audits/DIAG-sharing-2026-07-20.md.

Verdicts

• Reload loop — ROOT-CAUSED (HIGH). sharingStatusHandler (sharing_handlers.go:246, added in b5d78d1, controller v0.147.0, 2026-07-19) coerces idle → running whenever the samba container is alive. sharing.html L320–326 treats running as a one-shot job-success edge and calls location.reload() 1.2 s later. The first tick() fires synchronously on every page load, so the page reloads forever. Unconditional for any customer with sharing enabled — the Megosztás page is currently unusable. Proven live: 6 consecutive /sharing/status polls all returned {"phase":"running","running":true}, and the controller log shows no ensure job ran at all, so the phase is manufactured by that line rather than left over from a stuck job.
• smb://192.168.0.162 — ROOT-CAUSED. .162 is the Proxmox host and never was an SMB endpoint. smbd runs in guest 9201 and binds 192.168.0.104:445. nc from the host: .104:445 open, .162:445 refused. Wrong target, stale Finder favourite.
• smb://FELHOM — OPEN, narrowed. NetBIOS resolution works on the wire (nmblookup -B 192.168.0.255 FELHOM → 192.168.0.104 FELHOM<00>), but the stack advertises no mDNS/Bonjour (nothing on udp/5353; the R-6 spike selected smbd + nmbd + wsdd only) — the mechanism macOS Finder prefers. Closing this needs one probe from the Mac (smbutil lookup FELHOM / dns-sd -B _smb._tcp), listed in the audit's Mac test matrix.
• H2 (container down/crash-looping) — RULED OUT at the first probe: felhom-samba Up 3 h, clean logs, smbd/nmbd/wsdd all bound as infra/samba.go intends, live smb.conf matches the renderer with no baked address literal, no PVE firewall in the path.

Findings (full table + evidence in the audit doc)

S-1 HIGH reload loop (XS fix: latch a sawInFlight flag in the JS; red-proof required) · S-2 MED the UI never shows the connect address, only \\FELHOM — customers guess IPs · S-3 MED no mDNS advertisement (image slice, needs republish) · S-4 LOW ensure-job phase never resets — fold into the async-job-feedback roadmap item · S-5 INFO the guest's LAN IP is DHCP, so any displayed address must be read live, never cached.

Recommended packaging: S-1 as an immediate patch task (it bricks a shipped page), S-2 alongside it if the guest IP is reachable from the sharing handler, S-3 as its own slice.

Also noticed

The remote site's LAN is 192.168.0.0/24 — the same prefix as the DooPlex home LAN that the Tailscale subnet router advertises (192.168.0.180 shows FAILED in felhom-pve's neighbour table). A successful ping 192.168.0.162 therefore does not by itself prove the Mac is on the remote segment; the Mac matrix starts by confirming which network it is on.

Actions taken

None. Every command was a read, except a POST /login to obtain a session for the status polls. No secrets are recorded in either document.