felhom.eu/documentation/audits/SPIKE-nas-dsm-2026-07-11.md

SPIKE — Synology DSM pass of the NAS recipes (virtual-dsm), validated through the v0.114 pipeline

Date: 2026-07-11 · Class: Spike (timeboxed 90 min; finished in ~55 incl. teardown). Goal: replace the "Debian-simulated NAS" caveat with REAL DSM evidence for the consumer recipes, answer the DSM hardlink question (the Q5 caveat), and spot-check the error taxonomy against DSM's strings. Output = this doc + the guidance-copy edit list (lands with controller v0.115.0). Rig: vdsm/virtual-dsm container on DooPlex, macvlan network with its own LAN IP 192.168.0.199 (standard ports 445/2049 — the locked mount recipes cannot use alternate ports; the ping+neigh-verified-unused IP from the earlier spikes). DSM 7.2 (VirtualDSM), storage on a spike-named scratch volume. Setup wizard + all DSM config driven via claude-in-chrome; throwaway credentials, never committed. Everything below ran through the REAL demo add pipeline (guest 9201, controller v0.114.0 + agent v0.81.0, the exact /api/storage/netstorage/add + status-poll the UI invokes — anti-F9).

Verdict table

#	Recipe	Result	Evidence
1	NFS consumer recipe — DSM squash "Map all users to admin", rw, host IP rule	PASS end-to-end — add done in 4 s; uid-1000 probe: write/mkdir/rename/hardlink (links=2)/delete all OK; guest view 65534:65534 (nobody); chown clean EPERM; chmod succeeds — byte-for-byte the Debian Route-A profile
2	NFS WRONG case — same share, squash "No mapping"	PASS (refused as designed) — verify mounts, the uid-1000 probe refuses → not_writable + the Route-A Hungarian message (computed 101000), full rollback (zero units left). The June pin holds on real DSM
3	SMB plain user — DSM user + rw on the share, NO server-side uid config	PASS end-to-end — done in 4 s; guest view forced 1000:1000/0664; hardlink WORKS on DSM SMB (links=2) — the Q5 caveat CLOSES for Synology (DSM 7.2 Samba/btrfs)
4	Taxonomy spot-check — wrong SMB password / wrong share name	IDENTICAL classification — smb_auth / smb_share; no DSM-specific strings fell to mount_failed

DSM menu paths + exact wording (for the guidance)

• Enable NFS (OFF by default, and capped at NFSv3 by default!): Control Panel → File Services → NFS tab → check "Enable NFS service" → Maximum NFS protocol: NFSv4.1 → Apply. ⚠ This is a REQUIRED guidance step: the felhom mount is vers=4.1; a DSM left on the NFSv3 default refuses it (the add would fail mount_failed-class). SMB needs nothing (on by default).
• NFS rule: Control Panel → Shared Folder → <share> → Edit → NFS Permissions tab → Create → Hostname or IP: the Felhom host IP → Privilege: Read/Write → Squash: "Map all users to admin" (dropdown options verbatim: No mapping / Map root to admin / Map root to guest / Map all users to admin / Map all users to guest) → Save. The mount path (what goes in the felhom form's export field) is displayed on the same tab: /volume1/<share>.
• SMB user: Control Panel → User & Group → Create → (wizard) → at "Assign shared folders permissions" tick Read/Write on the share. That is ALL — no force-user anywhere.

Guidance-copy edit list (rides controller v0.115.0 — Part B)

1. SMB paragraph: unchanged in substance; may cite "DSM: Vezérlőpult → Felhasznál..." — keep it one line: user + Read/Write a megosztáson (validated on DSM 7.2).
2. NFS simple recipe: name DSM's dropdown verbatim — „Map all users to admin” as the concrete Synology wording for the map-all-users option; add the REQUIRED step "NFS szolgáltatás bekapcsolása + Maximum NFS protocol: NFSv4.1" with the File Services path; add that the export path is /volume1/<megosztás> and is shown on the NFS Permissions tab.
3. The closing caveat line narrows from "Synology/QNAP útmutató készül" to QNAP only: A QNAP felületére szabott lépésről lépésre útmutató készül. — Synology is now validated. QNAP stays a stated caveat — no emulator exists; nothing was fabricated.
4. The *arr/hardlink note (network-storage-nas.md): Synology SMB hardlink = CONFIRMED WORKING (DSM 7.2); the "re-verify per appliance" caveat now applies to QNAP/others only.

Observations (not acted on)

• virtual-dsm's NAT (container 192.168.0.199 → inner VM 172.30.0.199) forwards NFS/SMB fine; the verify pipeline's TCP pre-probe, mount, and uid-1000 probe all behaved as on a bare server.
• DSM's first-boot wizard pushes Synology-account/2FA/analytics screens — all skippable; the update-options page was set to manual (a spike VM must not self-update mid-test).
• The demo box now carries the operator's own permanent nas-media share (192.168.0.180:/mnt/5_hdd/felhom-data, health ok) — untouched by this spike; it is the Part E (Q1c restart) subject.

Q1c — NAS automount trigger survival across a guest restart: FAIL (the dangerous empty-dir case)

Supervised (operator GO 2026-07-11), on the fully-updated stack (agent 0.82.0 + controller 0.115.0), using the operator's own nas-media share (read-only). This closes the open Q1c item from SPIKE-nas-verify-2026-07-11 §Q1.

Method + result:

1. Pre-state: nas-media idle (host autofs trigger active-waiting; the trigger WAS visible in the guest's /proc/mounts, having propagated when the automount was enabled while the guest ran); apps healthy.
2. pct reboot 9201 (the sudoers-granted verb).
3. Post-boot, no access yet → pct exec 9201 -- grep nas-media /proc/mounts = NO_GUEST_TRIGGER (the host trigger is intact + active, but it did NOT re-propagate into the guest's fresh namespace).
4. In-guest ls /mnt/felhom-drives/nas-media → an EMPTY directory (nobody:nogroup, just ./..) and the access did NOT trigger the host mount (no nfs4 host-side afterward). This is exactly the WRONG outcome the June spike flagged: a media app (jellyfin/*arr) restarting after a guest reboot sees an empty library, not the NAS content — and an app that "cleans up" a suddenly-empty library could destroy metadata.
5. Apps recovered healthy (controller/traefik/cloudflared/filebrowser Up); the controller's NAS list still reports nas-media health: idle because it reads the HOST automount state — so the UI looks fine while the guest cannot actually reach the share (a silent, misleading gap).

Root cause: mp8 /mnt/felhom-drives is shared (host) → shared,slave (guest). Slave propagation only carries mount events that happen AFTER the slave relationship is (re)established. The host's autofs trigger for nas-media was mounted BEFORE the guest's post-reboot bind, so it is not present in the guest's new namespace; and the agent has no network-mount reassert on guest reboot (no netmount/reassert lines in the boot journal) — unlike the drive path's ReassertGuestBinds.

FAIL protocol honored — NOTHING repaired live. State left as found: the nas-media host automount stays configured + active; the guest sees the empty bind dir until the share is re-added (remove+add re-runs EnsureNetworkMount; the fresh enable --now propagates the trigger into the running guest) or an agent-side reassert lands. Follow-up task (evidence = this section): felhom-agent should re-propagate/re-establish network automounts into the guest after a guest restart — mirror ReassertGuestBinds for the network-storage class (a ReassertNetworkMounts on the guest-reboot path). Until then, document that a customer guest reboot requires re-touching NAS shares, and consider having the controller's per-share health cross-check the GUEST-visible mount, not only the host automount, so the UI stops showing idle/ok for a guest-unreachable share.

Teardown — verified

dsmsmb/dsmnfs removed via the real remove endpoint (list shows only nas-media); felhom-pve: zero dsm* units/creds/mountpoints, reset-failed clean. DooPlex: dsm-spike container removed, dsm-spike-net macvlan removed, ~/dsm-spike scratch deleted; port probes DEAD (5000 + 445 refused). Throwaway DSM credentials died with the VM.