# 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 → \ → 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/`. - **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/` 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. ## 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.