admin
0c4886958e
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nhk3eBHT8Mg5L8c2aj57aU
54 lines
3.3 KiB
Markdown
54 lines
3.3 KiB
Markdown
# 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.
|