felhom.eu/documentation/audits/R108-network-app-namespace-2026-07-30.md

AUDIT — R-108: network storage may not host an app's data namespace (2026-07-30)

Shipped: controller v0.187.0 (felhom-controller 2f27a36), live on both demo boxes. D5's precondition is met.

---

1. Baselines, established separately

component	value	how
controller on main	0.186.0 → shipped 0.187.0	top of CHANGELOG.md
controller on demo-felhom 9201	0.186.0 (pre-fix — used as the BEFORE)	docker ps --filter name=felhom-controller
controller on demo-hp 9201	0.185.1 (was drifted one release behind)	same
golden-baked controller	0.186.0	hub_settings.artifact_golden_version
agent (both demo boxes)	0.118.1	hosts.agent_version, hub-side
hub	0.83.0	deploy/hub image tag
felhom.eu HEAD	70f8494	—

R-120's gate holds: golden 0.186.0 == newest fleet-reported controller 0.186.0 at session start, so compareVersions(golden, newest) == 0, not < 0. It will now REFUSE until the golden is re-baked to 0.187.0 — deliberate and correct: the fleet has moved past the golden, which is exactly the drift the gate exists to catch. No golden re-bake was performed (out of scope; not required for this fix).

R-121 (agent-on-box drift): CLOSED for the demo fleet. Both boxes report 0.118.1 and the manifest vouches 0.118.1 — no drift. sess-f (0.116.0) and drill-r50 (0.113.0) remain behind and were not touched.

---

2. §2 citation reconfirmation — all six hold, line numbers moved

register citation	now at	verdict
handlers.go:2450-2460 local userdata-scoped	:2464-2465	holds
handlers.go:2432 network share-ROOT, download: true	bind :2437; download: true at internal/infra/infra.go:328	holds
settings.go:904-914 no IsNetwork() filter	GetSchedulableStoragePaths, :926-936	holds
handlers.go:674-679 migrate targets unfiltered	:673-678	holds
storage_handlers.go:410-424 migrate-app unguarded	:416-425	holds
storage_handlers.go:397 sibling refuses — the precedent	handleStorageMigrate, :404 — refuses BOTH source and target	holds, and is stronger than cited

---

3. The §3.1 ruling — REFUSE the placement, KEEP the browse bind

"Scope the bind" is not implementable. Establishing that is what inverted the fix:

1. The share-root :rslave bind is load-bearing, not an oversight. Its own doc comment records a Phase-0 probe (2026-07-22) proving an in-container access through an rslave bind wakes the idle automount trigger. Narrow it and NAS access itself breaks.
2. There is no userdata/ layer to scope to. deployedAppsOnPath (internal/web/netstorage_handlers.go) documents that apps on a share store <share-root>/<app> — the local <drive>/userdata|appdata|backups convention does not apply to shares at all.
3. Creating one is forbidden: "Never a skeleton, never any write toward the NAS — Felhom conventions must not be written onto a customer's own NAS."

The browsing surface being immovable is precisely why the backup tree must never be placed under it. Tier 2 had already reached that conclusion for its own targets (F-6C-1, internal/backup/tier2.go); R-108 closes the PRIMARY namespace, the last remaining route.

This needed an operator decision (it removes a capability going forward) and got one. Evidence supplied with the question: zero apps on network storage across all six hub customers including Peti — verified from every stored DR-recipe app half; only hdd_1 and nvme-1tb, both local drives. demo-hp's Felhom-Share holds only the customer's own files (.DS_Store, test file.txt, teszt/) and no backups/. Nothing stranded, no migration owed.

Two capabilities were separable and only one was removed:

• browse a NAS through FileBrowser (R-67) — KEPT, byte-identical.
• host an app's data namespace on a NAS — REFUSED.

---

4. The exposure chain, confirmed at source

namespaceRoot(drivePath) returns any non-system drive path AS-IS (internal/backup/backup.go:262-263), so an app's namespace root is its HDD_PATH; the recovery unit is <HDD_PATH>/backups/primary/<stack>/ (internal/appbackup/paths.go). On a NAS that lands inside the share, which FileBrowser binds whole with download: true.

This was documented, deliberate behaviour — not an accident. controller/README.md carried "NAS backup locality (v0.118.0, CAMPAIGN-3 Part 4 — decision A): a NAS-resident app's tier-1 artifacts live on the NAS itself". R-108 supersedes decision A; the README now says so, and the NAS-outage window that block warned about is gone with it.

---

5. §3.2 — the surface set is FIVE, not four

#	surface	state before	in the register?
1	deploy POST (internal/api/router.go)	accepted any caller-supplied HDD_PATH; only other validation is os.Stat existence (internal/stacks/deploy.go)	understated — the row says "the dropdown has no filter", but the dropdown is a UI list; this is the boundary
2	per-app migrate target list (internal/web/handlers.go)	unfiltered	yes
3	handleStorageMigrateApp	no guard	yes
4	handleStorageDecommission mode=migrate, the TARGET	refuseNetworkLifecycle guarded only req.Where (the SOURCE) — a whole namespace could be decommissioned ONTO a NAS	NO — found by enumerating
5	the FileBrowser bind	share ROOT + download: true	yes — deliberately unchanged, now pinned by a test

Also found and filed, not fixed: storageDriveList() (internal/web/handler_export.go) does not filter network paths, so a .fab bundle (plaintext secrets, optional password) can be exported onto a NAS → R-126. The register already noted this as R-108's "second effect, independent of D5"; it is now its own row so it did not vanish with R-108's closure. It is not a D5 precondition: an explicit customer-chosen export destination is not a browsing surface reaching a backup tree.

No gap was found in the §10.1 swept set. Every other row in that table was re-read and still holds.

---

6. Fail-closed, and why it needed a function rather than an IsNetwork() call

/mnt/felhom-drives holds both storage kinds in-guest — .../nvme-1tb is a local drive, .../Felhom-Share is a NAS — so a path prefix cannot classify. Kind is the only discriminator and it exists only on a registered path. Therefore an unregistered path under that root is un-classifiable, and un-classifiable refuses. Every share is registered under that root by construction, so the network set is completely covered without touching drives. Empty HDD_PATH (SSD-resident) stays allowed; a nil registry refuses.

---

7. Live evidence — same box, before and after, through the real endpoint

Method: POST /api/storage/migrate-app — the exact endpoint the storage UI's migrate button invokes — authenticated with the session cookie and the X-CSRF-Token the page carries, against the controller's container IP with the mandatory Host header. No browser exists on DooPlex; this is the endpoint-level method, and no server logic is skipped. The app name is deliberately non-existent, so the call is safe on both code paths (pre-fix it fails on the app name; post-fix it is refused earlier).

demo-felhom — the same box across the upgrade

BEFORE  (controller 0.186.0)                     the target was NEVER EXAMINED
  target=/mnt/felhom-drives/Felhom-Share   -> 409  {"error":"alkalmazás nem található: r108-probe-nonexistent"}
  target=/mnt/felhom-drives/not-registered -> 409  {"error":"alkalmazás nem található: r108-probe-nonexistent"}

AFTER   (controller 0.187.0)                     refused at the target
  target=/mnt/felhom-drives/Felhom-Share   -> 400  "A megadott tárhely nem azonosítható regisztrált
                                                    meghajtóként, ezért alkalmazás adatkönyvtáraként nem
                                                    használható. Válasszon a listából csatlakoztatott meghajtót."
  target=/mnt/felhom-drives/not-registered -> 400  (same — fail-closed)
  target=/mnt/felhom-drives/hdd_1          -> 409  {"error":"alkalmazás nem található"}   <- guard PASSED THROUGH

Pre-fix, both paths sailed into MigrateApp and failed only on the app name — with a real app name the migration would have started. That is the defect, live. Post-fix both are refused, and the real local drive still reaches MigrateApp (409, a different code and message), which is the not-over-broad proof.

demo-hp — the box with a REGISTERED network share

target=/mnt/felhom-drives/Felhom-Share   -> 400  "Hálózati tárhelyen (NAS) nem futtatható alkalmazás
                                                  adatkönyvtára — a NAS megosztás tallózásra és
                                                  médiatárolásra használható. Válasszon csatlakoztatott
                                                  meghajtót."
target=/mnt/felhom-drives/not-registered -> 400  (undeterminable reason — fail-closed)
target=/mnt/felhom-drives/nvme-1tb       -> 409  app not found  <- guard PASSED THROUGH

The network-specific reason fires here because the share is registered with kind=network; on demo-felhom the same path is unregistered and correctly gets the fail-closed reason instead. The two messages differing per box is the predicate demonstrably reading real state, not a constant.

Non-effect — the state after the refused calls (demo-hp)

storage registry:
  path=/mnt/felhom-drives/nvme-1tb      kind=drive    migrated_to=-  decommissioned=False
  path=/mnt/felhom-drives/Felhom-Share  kind=network  migrated_to=-  decommissioned=False
app HDD_PATH:  /mnt/felhom-drives/nvme-1tb          (unchanged)
share backups/: ls: cannot access '.../Felhom-Share/backups': No such file or directory

No migrated_to, nothing decommissioned, no job id or started flag returned, HDD_PATH unchanged, and no backups/ tree on the share.

R-67 preserved — the FileBrowser compose, diffed across the deploy

- /mnt/felhom-drives/nvme-1tb/userdata:/srv/nvme-1tb            <- drive:   userdata-scoped
- /mnt/felhom-drives/Felhom-Share:/srv/Felhom-Share:rslave      <- network: ROOT (deliberate)
- /mnt/sys_drive/felhom-data/userdata/import:/srv/beolvasas

diff of demo-hp's generated compose before vs after 0.187.0: IDENTICAL. The capability the ruling preserves is preserved byte-for-byte, not merely "probably unaffected".

---

8. Tests

9 new, all asserting the non-effect. The refusal tests run against a Server with a deliberately nil stackMgr: a guard that fails to fire reaches the mutation and panics rather than passing quietly. Asserted: no job id, no started flag, no MigratedTo, and for decommission that the source was not soft-marked. Fixtures are demo-hp's real two-class storage set (both paths under the same mount root — the trap).

Seams named (R-125). The FileBrowser tests inject at fbPathDeps (isMount/classify/ ensureSkeleton) and run the real buildFileBrowserPaths; the bind-string construction — what the assertion is about — is not injected. Not covered by that span: RenderFileBrowserConfig and the compose template downstream, closed by the live compose diff in §7. The handler tests inject nothing — real handler, real settings store, httptest.

Red-proofs: 4, each mutation asserted to have landed before the run:

#	mutation	caught by
1	drop the migrate-app target guard	panic on nil stackMgr — execution reached the mutation
2	drop the decommission migrate-target guard	panic, same shape
3	let an unregistered path under the mount root fall open	3 tests, incl. the live-shaped handler case
4	userdata-scope the share (break R-67)	the regression guard, quoting the broken bind

Suite rc=0, 27 packages, 0 FAIL (run separately from every commit); go vet rc=0; template_id_gate.py and emoji_gate.py both OK.

---

9. §7 — the sentence this task exists to produce

D5's precondition IS met. An app's data namespace can no longer be placed on network storage, so no backups/ tree can exist inside FileBrowser's share-root bind; every other read surface was already clear in the §10.1 sweep. Nothing in 07-backup-architecture.md §10.1 blocks D5 any more.

What remains is scheduling, not blocking. .fab-export-onto-NAS (R-126) is open but is not a D5 precondition — it is an export destination the customer chooses, and D5 moves secrets into the local recovery unit, not into .fab.

---

10. Four-artifact update

artifact	what changed
architecture/07-backup-architecture.md	§10.1 retitled CLOSED, with the ruling, the reasoning and the D5 sentence; the network-share table row flipped YES→NO with the reason it is closed at the placement rather than the bind; the exposure chain annotated with the fifth surface and the deploy-POST correction; §7.3 retitled UNBLOCKED; §10.2 register row collapsed + R-126 added; open question F answered
architecture/00-capability-map.md	new §D row, PROVEN-LIVE, citing this audit — with the un-exercised legs named explicitly (deploy POST + decommission refusals are unit-tested, not live-fired)
backlog/ROADMAP.md	R-108 collapsed to a shipped one-liner; R-126 added
backlog/OPEN-ITEMS.md	R-108 dispositioned; D5 given its own row as READY/UNBLOCKED (it had existed only inside other rows' prose — the R-123 pattern); R-126 registered

---

11. What did NOT happen, and why

• D5 not implemented — explicitly fenced; this unblocks it only.
• No customer data migrated — none needed it (zero apps on network storage).
• The share-root bind not narrowed — deliberate, and §3 is the argument.
• R-126 filed, not fixed — it is a separate surface with its own decision (filter the destination, or force the bundle password), and folding it in would have widened a security fix mid-flight.
• No golden re-bake — out of scope. Consequence to be aware of: the golden bakes 0.186.0 while the fleet now runs 0.187.0, so R-120's vouch gate will REFUSE the next artifact vouch until the golden is re-baked. That is the gate working as designed, not a regression.
• sess-f and drill-r50 not upgraded — neither was named as a venue; drill-r50 is fenced.
• No live-fire of the deploy-POST or decommission refusals — both are unit-tested with non-effect assertions; live-firing them needs a real app deploy and a real decommission on a box with a registered share, which is a destructive drill this task did not authorise. Named in the capability-map row.
• Nothing written to demo-hp's local-lvm; drill-r50, guest 9201 on other hosts and Peti's cluster untouched; neither demo box re-targeted; no AttachDrive call.