docs: DIAG addendum 2 — S-3 fixed (samba 1.1.0 mDNS + v0.152.0 copy); Finder sidebar stays OPEN
Capture disproved addendum 1's guess: macOS DOES send a correct NBNS query and IS answered correctly in 140us; it simply never acts on it. Records the proven per-client matrix and keeps sidebar discovery explicitly unproven.
This commit is contained in:
@@ -218,7 +218,7 @@ starts with "which network am I actually on".
|
||||
|---|---|---|---|---|---|
|
||||
| **S-1** — **FIXED v0.151.0** | **HIGH** | `/sharing` reload-loops forever for every customer with sharing enabled — the page is unusable. `sharingStatusHandler` reports `running` as a level; the JS treats it as a one-shot success edge and calls `location.reload()`. | `sharing_handlers.go:246` (blame `b5d78d1`), `sharing.html` L320–326, 6× identical `phase:"running"` poll | **XS.** Make the JS reload only when it has *observed a transition* — latch a `sawInFlight` flag on the first tick and reload on `running` only if it is set; otherwise just paint the success alert and stop. Server-side alternative (also XS): report the coerced level as a distinct phase (`running_steady`) the JS renders but never reloads on. Prefer the JS latch — it keeps the honest "liveness wins" contract the handler comment states. **Needs a red-proof:** a template/JS test or handler test asserting a fresh page load with a live container does not schedule a reload. | no — plain bug fix |
|
||||
| **S-2** — **SHIPPED v0.151.0** | **MED** | The UI never tells the customer *where* to connect. `sharing.html` L32/L61 show only `\\FELHOM`; there is no IP anywhere on the page, so a customer who cannot resolve the name has nothing to fall back on and will guess (Viktor guessed the Proxmox host IP). | `sharing.html` L30–32, L61; symptom 1 itself | **S.** Render the guest's current LAN address beside the name: `\\FELHOM` *(vagy `smb://192.168.0.104`)*, sourced from the same place the dashboard already knows the guest IP. Add a one-line macOS hint (Finder → Ugrás → Csatlakozás a szerverhez). | no |
|
||||
| **S-3** — **OPEN** | **MED** | No mDNS/Bonjour advertisement. `smbd + nmbd + wsdd` covers Windows (WSD) and legacy NetBIOS, but macOS Finder's preferred path is Bonjour — `FELHOM.local` does not resolve and the share never appears in the Finder sidebar. Likely the whole of symptom 1b. | nothing on udp/5353 (§ Phase A); container log daemon list; `infra/samba.go` header comment citing the R-6 spike | **S–M.** Add avahi-daemon (or `wsdd`'s mDNS sibling) to the felhom-samba image publishing `_smb._tcp`, host-net so multicast reaches the LAN. Re-runs the R-6 spike's constraint set — treat as a slice, not a hotfix. Confirm with the Mac matrix first (below) so we fix the mechanism that is actually failing. | yes — image change + republish |
|
||||
| **S-3** — **FIXED v0.152.0 / samba 1.1.0** | **MED** | No mDNS/Bonjour advertisement. `smbd + nmbd + wsdd` covers Windows (WSD) and legacy NetBIOS, but macOS Finder's preferred path is Bonjour — `FELHOM.local` does not resolve and the share never appears in the Finder sidebar. Likely the whole of symptom 1b. | nothing on udp/5353 (§ Phase A); container log daemon list; `infra/samba.go` header comment citing the R-6 spike | **S–M.** Add avahi-daemon (or `wsdd`'s mDNS sibling) to the felhom-samba image publishing `_smb._tcp`, host-net so multicast reaches the LAN. Re-runs the R-6 spike's constraint set — treat as a slice, not a hotfix. Confirm with the Mac matrix first (below) so we fix the mechanism that is actually failing. | yes — image change + republish |
|
||||
| **S-4** — **CORE SHIPPED v0.151.0** | **LOW** | Success-state semantics: the ensure job's phase never returns to `idle` after a terminal phase, and `SambaRunning()` masks that anyway. Harmless today only because S-1's fix removes the consumer that cared. Worth folding into the **unified async-job feedback** roadmap item the `samba_ensure_job.go` header already names. | `samba_ensure_job.go` (no reset path); handler line 246 | Fold into the roadmap item; no standalone task. | no |
|
||||
| **S-5** — **SHIPPED v0.151.0** | **INFO** | The guest holds its LAN address by **DHCP** (`ip=dhcp`, lease ~54 min at probe). Any printed IP is not stable across a lease change or a site move, which weakens S-2 unless the page re-reads it live (it should — render it, never persist it). | `pct config 9201`; `valid_lft 3251sec` | Render live, never cache. Consider a DHCP reservation at the customer's router as a documented install step. | no |
|
||||
|
||||
@@ -297,3 +297,82 @@ still is Viktor's to give — a browser is the one method not available here.
|
||||
**Tests:** 23/23 packages green (twice). Three red-proofs recorded — reinstating the coercion,
|
||||
deleting the serve-once clear, and memoizing the derived address each turned the corresponding test
|
||||
red, then were restored.
|
||||
|
||||
---
|
||||
|
||||
## Addendum 2 — 2026-07-20, controller v0.152.0 + felhom-samba 1.1.0 (S-3 closed)
|
||||
|
||||
### The finding that redirected the fix: macOS asks, is answered correctly, and ignores it
|
||||
|
||||
Addendum 1 recorded S-3 as "no mDNS, and macOS probably no longer does NetBIOS". **The second half
|
||||
was wrong**, and a packet capture on the box settled it. On a bare `smb://FELHOM` from the operator's
|
||||
Mac (`192.168.0.11`):
|
||||
|
||||
```
|
||||
11:18:30.222080 192.168.0.11.52844 > 192.168.0.255.137 UDP len 50 (NBNS query)
|
||||
name = EGEFEMEIEPENCACACACACACACACACACA → "FELHOM" + 9 pad + suffix 0x20
|
||||
i.e. FELHOM<20>, the File Server Service suffix — exactly right for SMB
|
||||
11:18:30.222220 192.168.0.104.137 > 192.168.0.11.52844 UDP len 62 (NBNS response, +140 µs)
|
||||
flags 0x8580 → response, authoritative, RCODE=0 (no error), ANCOUNT=1
|
||||
TTL 259200, NB_FLAGS 0x0000 (unique, B-node), RDATA 192.168.0.104
|
||||
```
|
||||
|
||||
**A textbook-correct positive answer, delivered in 140 microseconds — and macOS never opened a TCP
|
||||
connection.** It retried once at 11:18:30.718, was answered again, and gave up. Sixteen seconds
|
||||
later, at 11:18:46, the same Mac queried `FELHOM.local` over mDNS and went straight to `445`.
|
||||
|
||||
So NetBIOS on macOS feeds legacy browsing, not `smb://` URL resolution. **The bare `smb://<NÉV>`
|
||||
cannot be made to work from a Mac by any change on our side**, and nmbd — the thing the R-6/S4b
|
||||
spike was right to insist on — was never the broken part. It is exactly what serves Windows.
|
||||
|
||||
Investigated and dismissed: the box answers **twice** per broadcast query, because nmbd holds
|
||||
`0.0.0.0:137`, `192.168.0.104:137` and `192.168.0.255:137`, and a subnet broadcast is delivered to
|
||||
two of them. That is standard Samba behaviour, and a duplicated correct answer is still a correct
|
||||
answer that macOS declined to use.
|
||||
|
||||
### The proven matrix
|
||||
|
||||
| Client | Working form | Served by |
|
||||
|---|---|---|
|
||||
| Windows | `\\FELHOM` | nmbd (+ wsdd for the Network view) |
|
||||
| macOS | **`smb://FELHOM.local`** | avahi/mDNS — new in samba 1.1.0 |
|
||||
| Any | `smb://192.168.0.104` | direct |
|
||||
|
||||
### Shipped
|
||||
|
||||
* **felhom-samba 1.1.0** — avahi + dbus added. `avahi-daemon.conf` and the `_smb._tcp` service file
|
||||
are templated from `FELHOM_SERVER_NAME` at entrypoint, so renaming the server re-advertises under
|
||||
the new name. Static service file rather than smbd's `multicast dns register`, because `smb.conf`
|
||||
is bind-mounted READ-ONLY and owned by the controller's renderer — and it allows publishing
|
||||
`_device-info._tcp` too. Both daemons are **non-fatal on failure**: a discovery gap must not turn
|
||||
into a sharing outage.
|
||||
* **controller v0.152.0** — the connect card's Mac line was `smb://<NÉV>`, i.e. the one form that
|
||||
provably cannot work. Now `smb://<NÉV>.local`. The Windows line stays the flat `\\<NÉV>`. This was
|
||||
a **copy defect introduced by v0.151.0 the same day**, not merely a missing feature.
|
||||
|
||||
### Live validation (endpoint-level + on-the-wire from a second machine)
|
||||
|
||||
```
|
||||
mDNS from felhom-pve (shipped image, not the spike):
|
||||
FELHOM.local (A) -> A 192.168.0.104 (from 192.168.0.104)
|
||||
_smb._tcp (browse) -> PTR FELHOM._smb._tcp.local (from 192.168.0.104)
|
||||
|
||||
daemons in felhom-samba:1.1.0: smbd · nmbd · wsdd · dbus-daemon · avahi-daemon: running [FELHOM.local]
|
||||
|
||||
GET /sharing -> smb://FELHOM.local smb://192.168.0.104 \\FELHOM
|
||||
GET /sharing/status x2 -> phase:"idle", running:true (v0.151.0 contract still holding)
|
||||
```
|
||||
|
||||
Operator confirmation from the Mac: **`smb://FELHOM.local` connects and prompts for credentials.**
|
||||
(Username is `felhom`, the household account — the Mac prefills the local account name, which will
|
||||
be rejected.)
|
||||
|
||||
### STILL OPEN — Finder-sidebar discovery
|
||||
|
||||
**Not claimed as shipped.** The `_smb._tcp` record is published and answers browse queries on the
|
||||
wire, but FELHOM did **not** appear in the operator's Finder sidebar. That Finder window showed no
|
||||
Network/Bonjour section at all, which points at **Finder Settings → Sidebar → Locations** rather
|
||||
than at the box — but it is unverified either way, so it stays open. Next step is one look at that
|
||||
setting, and `dns-sd -B _smb._tcp` on the Mac to confirm the advert is seen client-side. Zero-typing
|
||||
discovery was the original ambition of the R-6 spike and is still not demonstrated.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user