docs: DIAG — Megosztás reload loop root-caused (b5d78d1 phase coercion) + SMB endpoint is the guest, not .162

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nhk3eBHT8Mg5L8c2aj57aU
2026-07-20 10:11:58 +02:00
parent 1e1181939b
commit 0c4886958e
2 changed files with 320 additions and 0 deletions
@@ -0,0 +1,53 @@
+# 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.