admin
9b95f88e8c
Supervised live proof on the demo (agent 0.82.0 + controller 0.115.0): after pct reboot 9201 the autofs trigger does not re-propagate into the guest; an in-guest access sees an empty dir and does not trigger the host mount. Root cause: shared->slave propagation + no agent network-mount reassert on guest reboot. FAIL protocol honored (nothing repaired live); fix spec'd in backlog. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PSK5g6qYLknKj8u3QAFEr6
50 lines
2.7 KiB
Markdown
50 lines
2.7 KiB
Markdown
# FOLLOW-UP — NAS automount trigger does not survive a guest reboot (agent reassert gap)
|
|
|
|
**Opened:** 2026-07-11 · **Severity:** HIGH (data-safety-adjacent for media apps) · **Class:**
|
|
implementation (felhom-agent, likely a small felhom-controller health-surface follow-on).
|
|
**Evidence:** `documentation/audits/SPIKE-nas-dsm-2026-07-11.md` §Q1c (supervised live proof on the
|
|
demo, agent 0.82.0 + controller 0.115.0, operator GO).
|
|
|
|
## The bug
|
|
|
|
After a **customer guest reboot**, a configured NAS share's autofs trigger is NOT present in the
|
|
guest's fresh mount namespace, and an in-guest access **does not** trigger the host mount — the app
|
|
sees an **empty directory** at the NAS path instead of the share content. The host-side automount is
|
|
intact and `active (waiting)`; the controller's per-share health still reads `idle`/`ok` (it inspects
|
|
the HOST automount, not the guest-visible mount), so the UI looks healthy while the guest cannot
|
|
reach the share.
|
|
|
|
## Why
|
|
|
|
`mp8 /mnt/felhom-drives` is `shared` (host) → `shared,slave` (guest). Slave propagation only carries
|
|
mount events that occur AFTER the slave bind is (re)established. The host autofs trigger was mounted
|
|
BEFORE the guest's post-reboot bind, so it is absent from the guest's new namespace. The agent has no
|
|
network-mount reassert on the guest-reboot path (contrast the drive path's `ReassertGuestBinds`).
|
|
|
|
## Impact
|
|
|
|
A media app (jellyfin/*arr/immich) restarting with the guest sees an empty library; an app that
|
|
prunes/cleans a suddenly-empty library could destroy metadata. Silent because the operator UI shows
|
|
the share healthy.
|
|
|
|
## Proposed fix
|
|
|
|
1. **felhom-agent — `ReassertNetworkMounts` on guest reboot** (mirror `ReassertGuestBinds`): after a
|
|
guest (re)start, re-establish each configured network automount so a fresh `enable --now` (or an
|
|
explicit re-propagation) lands the trigger in the running guest's namespace. This is the real fix.
|
|
2. **felhom-controller — health cross-check (follow-on):** per-share health should also verify the
|
|
GUEST-visible mount, not only the host automount, so the UI stops reporting idle/ok for a
|
|
guest-unreachable share.
|
|
|
|
## Interim workaround (manual, until #1 ships)
|
|
|
|
Re-add the share (remove + add via the UI): `EnsureNetworkMount` re-runs and the fresh automount
|
|
enable propagates the trigger into the running guest. A guest reboot on a customer box currently
|
|
requires re-touching NAS shares.
|
|
|
|
## Current demo state (left as-found per the FAIL protocol — NOT repaired live)
|
|
|
|
The demo's `nas-media` share (192.168.0.180:/mnt/5_hdd/felhom-data) has its host automount active but
|
|
the guest sees the empty bind dir. No media app is bound to it (experimental). Re-add to restore, or
|
|
leave for the fix's live validation.
|