Issue 149: whose the data is, not only where

The media modules must run as the owner of the data they access; the data
already says who that is. Proposes ${access:<id>:uid|gid} instead of user
management in the mesh (ADR 0051).

04-ISSUES/149-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md

@@ -0,0 +1,71 @@
+---
+status: open
+opened: 2026-09-29
+located-in:
+  - mesh-controller internal/catalogue/dir_into.go (dirsFor: a stated path or <data root>/<module>/<id>, nothing else)
+  - mesh-controller (accesses: the path is the manifest's literal)
+fixed-by:
+amended-design:
+---
+
+# 149 — An adopted machine's data cannot be placed where it is
+
+## What was observed
+
+Preparing ace's media modules (plex, sonarr, radarr, lidarr, bazarr, nzbget, qbittorrent, bookshelf)
+for migration. ace is adopted; its data is where the predecessor put it and **must stay there**:
+
+- the library and download spool: `/storage/media/*`, `/storage/downloads` — a separate ZFS pool,
+  ~40 TB, the operator's shared data (ADR 0051);
+- plex's own state: `/mnt/plex/{config,data,temp}` — 133 GB on a second disk;
+- large configuration directories held in place: lidarr 46 GB, radarr 17 GB, sonarr 3.2 GB.
+
+The catalogue's manifests name `/services/media/*` (as `accesses`) and `/services/<m>/config` (as
+owned directories), which is novox's layout, not ace's, and not a value a definition may carry.
+
+## What was decided, and what exists
+
+[ADR 0112](../../02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md) (accepted) says
+exactly what is needed:
+
+> *Where* it is on the machine is the assignment's. A node has a default layout, and an assignment may
+> place a directory elsewhere: on a second disk, or where an adopted machine's data already is.
+
+> [ADR 0051]: an access keeps its shape and its semantics; its path moves from the definition to the
+> assignment.
+
+What the control plane implements (`dirsFor`): a directory is either a path the manifest states, or
+`<data root>/<module>/<id>` under the node's one data root. There is **no per-assignment placement of
+one directory**, and an `access` path is the manifest's literal — no setting reaches either.
+
+## Consequence
+
+Every module whose data an adopted machine already holds somewhere other than the default layout can
+only be migrated by (a) writing the machine's path into the manifest — which 0112 forbids and which
+is wrong on the next machine — or (b) moving the data into the placed layout in a window. (b) is
+acceptable for a 40 MB configuration and impossible for a 40 TB library the operator has ruled must
+never be moved, copied or re-owned.
+
+The same gap covers ownership: the predecessor runs ace's media stack as `1001:2000`; a manifest's
+`owner` is one value for every machine.
+
+## What would be right
+
+The two assignment halves 0112 decided: a setting that places a declared directory (by id) at a given
+path on this node, and a setting that says where an access's data is — both validated like
+`endpoints` (unknown ids refused), and an access placed by the assignment still never created,
+chowned or removed.
+
+## Addendum 2026-09-30 — whose the data is, not only where
+
+The same modules need to run **as the owner of the data they access**: linuxserver images take
+`PUID`/`PGID`, and ace's library is `media:media` (`1001:2000`, group members `ace`, `n8n`, `media`).
+A manifest default is one value for every machine, and an assignment's settings do not reach a
+container's environment. Adding user and group management to the mesh would contradict ADR 0051 —
+the mesh owns nothing about the operator's data.
+
+The data already says whose it is, and the host already looks at it when it confirms an access exists.
+Proposed: expose that as a fact the module can ask for, like `${port:…}` — e.g. `${access:<id>:uid}`
+and `${access:<id>:gid}`, read from the accessed path on the machine — so a media module declares
+`PUID=${access:media:uid}` and is right on every machine without the mesh creating, naming or
+chowning anyone.