# 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.