From 90b89aa1c9633c2f5c8fd66bb471bd28c89227d8 Mon Sep 17 00:00:00 2001 From: jochens Date: Wed, 30 Sep 2026 13:53:32 +0200 Subject: [PATCH] =?UTF-8?q?Issue=20169:=20the=20consumer's=20half=20?= =?UTF-8?q?=E2=80=94=20the=20host=20mounts=20the=20share,=20a=20mount=20is?= =?UTF-8?q?=20a=20resource=20of=20the=20consuming=20module,=20not=20a=20cl?= =?UTF-8?q?ient=20module?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../00-report.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md b/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md index 60c28ba..f19d679 100644 --- a/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md +++ b/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md @@ -82,6 +82,30 @@ the catalogue beside the modules (a seat definition registered like a manifest), saying which seats it implements. This is the first role with an obvious second implementation, which is what makes it the exemplar for that mechanism. +## The consumer's half: the machine mounts it (2026-09-30, third round) + +A binding tells a consumer *where* the share is; it does not put the files on its machine. A +consumer on another node needs the export **mounted by the host, at a directory the consumer +declares, before its container starts**, and unmounted when the requirement goes. That is a host +action, not something a container reads from a file. + +**Not a client module.** A node-wide `nfs-client` with a list of mounts in its settings is fstab +with a manifest around it: consumers would stop requiring `nfs-share` and couple on a path again, +unassigning a consumer would leave its mount behind, and a person is back in the loop deciding +which machine mounts what — the thing the binding removes. + +**A mount is a resource of the consuming module.** The vocabulary (directory, file, package, +container, service, process, network, archive, user, access) has no `mount`. It can be assembled +today — a `package` (nfs-utils), a `file` writing a systemd `.mount` unit with +`What=${bound:nfs-share:at}:${bound:nfs-share:path}` and `Where=${dir:library}`, a `service` +enabling it after the overlay is up — but the honest form is a **`mount` resource kind**: the host +mounts from the binding, refuses a mountpoint the module did not declare (ADR 0091's three ways a +path can be), and unmounts on undeclare. The nfs and samba modules are then the *server* side only. + +**Identity crosses the wire.** `sec=sys` NFS trusts the client's uid, so a consumer must run as the +library's owner on the server (ace: `media`, 1001:2000) — hq 153's `${access::uid}` proposal +extended to a mount, `${mount::uid}`, read from the mounted tree. + ## Open questions for the decision - Whether an NFS export over the overlay is an `internal` reach of the same endpoint or a second