From 67599df951997f4f6bdd03f92929a38192bec9b2 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 5 Oct 2026 14:54:38 +0200 Subject: [PATCH] Issues 303, 304; 240 resolved, 242 located MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 303: a media server's previews were reached through a link its container never mounted — fixed by mounting them. 304: settings set replaces the whole layer with nothing to read it first and no history. 240 is fixed by mesh-controller#47; 242 has backups running and records what the rollout taught. (First opened as 245 and 246; main has since taken both numbers, and 302 was the last.) --- .../00-report.md | 39 ++++++++++++++++ .../00-report.md | 45 +++++++++++++++++++ 2 files changed, 84 insertions(+) create mode 100644 04-ISSUES/303-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md create mode 100644 04-ISSUES/304-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md diff --git a/04-ISSUES/303-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md b/04-ISSUES/303-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md new file mode 100644 index 00000000..f899a56f --- /dev/null +++ b/04-ISSUES/303-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md @@ -0,0 +1,39 @@ +--- +status: resolved +opened: 2026-10-05 +located-in: [mesh-media-catalog modules/plex] +fixed-by: mesh-media-catalog#2 +amended-design: +--- + +# 303 — A media server's previews were reached through a link its container never mounted + +## What was observed + +On the home server the media server's scrub previews — 423 GB, about 57 000 preview files, one per +video — had not grown in seven months: the newest was from the day its preview folder was moved off +the server's own disk onto the large storage pool. The server's log repeated, live, that it could not +create a directory under its preview folder. + +## Why + +The move left the preview folder as a **symbolic link** inside the server's configuration directory, +pointing at the pool. The container mounts the configuration directory and the media libraries, and +not the pool's path, so inside the container the link pointed at nothing: the server could neither +show the previews it had nor make new ones, and said so only in its own log. Nothing the mesh reports +showed it — the container ran, and answered. + +It is the failure the mesh's rule against symbolic links exists for: a link resolves differently in +every place that reads it, and a container is such a place. + +## Resolution + +The previews are a directory of the module, mounted at the server's preview path; where that +directory lives on a machine is the machine's placement setting, here the pool path the files were +already in. The link was removed at the cutover, the container recreated, the preview folders visible +inside it again and the log's errors gone. The previews are not backed up, by the operator's choice. + +## How it is checked + +The catalogue check that every mount is declared passes over the module. On the machine: the preview +folder seen from inside the container lists the same folders as the pool path. diff --git a/04-ISSUES/304-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md b/04-ISSUES/304-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md new file mode 100644 index 00000000..8350bf57 --- /dev/null +++ b/04-ISSUES/304-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md @@ -0,0 +1,45 @@ +--- +status: open +opened: 2026-10-05 +located-in: [mesh-controller cmd/mesh-controller (settings), mesh-controller internal/inventory (SetSettings)] +fixed-by: +amended-design: +--- + +# 304 — Setting a module's settings replaces the whole layer, and nothing shows it first + +## What was observed + +An operator's agent set one placement — where a media server's preview folder lives on one machine — +with `settings set {"places": {…}} --node `. The command answered that the setting +was recorded. The machine's plan then mounted the server's configuration from an empty default +directory: the node's layer had held the placements of three other directories, eight media +accesses, a public exposure, four endpoints and the account's ids, and every one of them was gone. + +Caught before any push, by reading the plan. The previous layer was read back from the controller +database's nightly dump — the backups that issue 242 asked for, a few hours old. + +## Why + +The layer is a statement of the whole, by design (the inventory's `SetSettings`: "replacing rather +than merging … removing a key is done by leaving it out"). That design is sound; what is missing +around it is everything that makes it safe to use: + +- **There is no way to read a layer.** `settings` has `set` and `clear`, no `show`; the console verb + likewise. To change one key, a person must already know every other key in the layer. +- **There is no history.** The row is updated in place; the previous values exist nowhere but a + database backup. +- **The answer does not say what was dropped.** "places" was reported as set; the six keys removed + were not mentioned. + +## What would fix it + +1. A way to read a layer — `settings show [--node]` and the same on the verb. +2. `set` answers with what changed: keys added, changed and **removed**, so dropping one is never + silent. A removal could even require saying so. +3. The previous value kept: a settings history row per change, so an undo needs no backup. + +## Status + +Open. Until it is fixed: read the layer (from the store, read-only) before setting it, and compare +the node's plan before and after.