felhom.eu/documentation/backlog/FOLLOWUP-nas-automount-guest-reboot-reassert.md

Status 2026-10-03 (backlog triage): SHIPPED — agent v0.84/v0.85 (CAMPAIGN-3). Kept here as history because CONTEXT.md, controller/network-storage-nas.md and the controller's CONTEXT.md link to this path.

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.