Files

T

admin 9b95f88e8c audit(Q1c): NAS automount trigger does NOT survive a guest reboot (empty-dir FAIL) + follow-up

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

2026-07-11 15:43:26 +02:00

2.7 KiB

Raw Blame History

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

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

2.7 KiB Raw Blame History