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
107 lines
8.2 KiB
Markdown
107 lines
8.2 KiB
Markdown
# 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.
|