felhom.eu/REPORT-filebrowser-memory-ci-2026-10-17.md

REPORT — FileBrowser never on its default password (D11 = A), real memory amounts (D10 = A), CI failure mail, STATUS (2026-10-17)

Written in ASD-STE100 Simplified Technical English. Brief: the operator's „D11 = A, D10 = A, D12 = key set" task (2026-10-17). Design read first: 01-topology-and-trust.md §5 (now carries the [DESIGN] paragraph), 02-controller-module-map.md (the app page, R-513 states), controller stacks/infra.go, stacks/deploy.go memoryVerdict. Evidence: documentation/audits/filebrowser-memory-ci-2026-10-17/.

Plain words first

• FileBrowser never answers on its default password any more (controller 0.327.1, the floor for every box since 12:06 UTC). FileBrowser's own password setting cannot do this: it overwrites the household's own password at every restart (measured). So the box keeps FileBrowser off the internet until it has checked it.
• One mistake in my release, found and fixed: 0.327.0 made files.<domain> time out on demo-hp and on the N100 for about 21 minutes. 0.327.1 fixed it by the normal update path. No data touched; the N100's diary has the line.
• The install check uses real memory amounts (your D10 = A), and its message and the install page now say what to do. No box is over. The page and the check now show the same numbers (they did not before).
• R-1129 was my mistake from earlier today. The CI failure mail always worked: the „ALARM FAILED" text I found was the CI printing its own script before running it. Your key change did no harm. A forced test mail went to admin@felhom.eu at 10:48:54 UTC (CC saw it arrive in the catch-all). Please confirm you have it — subject „[felhom CI] FORCED TEST, not a real failure - gates FAILED in admin/felhom.eu".
• STATUS: the other session had already given its decision a new number; D10, D11, D12 are now marked decided. Tester 1's four leftover mount units are removed.

1. FileBrowser (R-1126)

• Spike (1a), at the pinned tag gtstef/filebrowser:1.5.6-stable: the admin password can come from auth.adminPassword (backend/common/settings/auth.go:52) or FILEBROWSER_ADMIN_PASSWORD (backend/common/settings/config.go:923-926); there is no password-file form. It is applied at EVERY start: validateUserInfo (called at each start, backend/cmd/root.go:144) resets the admin user's password when the setting is set (backend/cmd/user.go:50-57, „Resetting admin user to default username and password").
• Measured on 9202:
  • With the variable set, the default login was refused from the first answer.
  • But a password the household set in FileBrowser was overwritten at the next restart: own login 401, the variable's password 200 (P1/A1b-env-password-spike.txt).
  • So Path 1 fails the brief's condition, and Path 2 is built.
  • Also seen: FileBrowser 1.5.6 limits login tries (429 after 8 fast tries) — a small guard of its own.
• Path 2, with one change from the brief's sketch: FileBrowser starts on its own network, not on traefik-public; the box joins it there after the check, by container ID. files.<domain> is a file route to filebrowser:80 by name, which resolves only while it is joined.
  • Why the network decides: any container re-created by anyone starts unpublished.
  • Why by ID: the commit's security review found a check-then-connect race when connecting by name; fixed before the release.
• 0.327.0 used Docker labels, and that failed on two boxes. Traefik kept the address it chose at container start, on the wrong network, so files.<domain> timed out on demo-hp and the N100. 0.327.1 replaced the labels with the file route.
• 9202 probes from outside, through Traefik (P1/):
  • rc.2 (labels): 143 probes, the default login never 200; 404 while unpublished.
  • 0.327.1-rc.1 (file route): 140 probes, never 200; 502 while unpublished, then the page 200 and the default refused.
• Box walk on 0.327.1: all three boxes, through Traefik and publicly: files.<domain> page 200, default login 401.
• Tests, each red-proved:
  • TestFileBrowserRender_R1126_NotPublicAtStart (no traefik-public, no labels, the route);
  • TestFileBrowserGate_PublishedOnlyAfterTheCheck;
  • TestFileBrowserGate_ConnectsTheCheckedContainerById.

2. Memory (R-1125)

Every box the hub knows (4, no customer box; hosts and customer_configs read; P2/B1-boxes.txt):

Box	Guest	Usable	Committed today → after
demo-hp	25,898 MB	25,514	2,478 → 3,682
demo-felhom	12,288	11,904	622 → 622
Tester 1	4,096	3,712	680 → 840
Tester-2	11,691	11,307	0 → 0 (no app; last report 2026-10-04)

No box is over; there was no STOP.

The refusal, before and after:

• Before: „Nincs elég memória az alkalmazás telepítéséhez. Szükséges: … Elérhető: … (… ebből … használt …)" — no advice.
• Now (check and page):
  • HU: „Nincs elég memória ehhez az alkalmazáshoz a már telepítettek mellett: kell 150 MB, szabad 50 MB (…). Távolíts el egy alkalmazást, amelyre nincs szükséged, vagy használj több memóriájú gépet."
  • EN: „There is not enough memory for this app next to the apps already installed: … Remove an app you do not need, or use a machine with more memory."
• The install page shows its own memory box first; it now says the same.

Found and fixed: the page used /proc's host-wide figures, the check the guest's committed requests. On 9202 the page said 12,637 MB „needed" against the check's 2,648. Now both read stacks.InstallMemory.

Promises: an ASCII grep of the website, the estimator and the dashboard templates for 8 GB/8GB/8 GiB (control: the estimator data names an 8 GB box) found no promise that the household set fits 8 GB. The estimator says it does not (P2/B3-promise-grep.txt).

The change: catalog 1af6ea7, 23 requests (P2/B4-requests-applied.txt). Also fixed:

• REUSE.md said „display-only", which was untrue;
• paperless-ngx's „display hint" comment;
• the README memory column.

Step files unchanged.

Live:

• 9201: Uptime Kuma (150 MB) accepted, then removed.
• 9202 made nearly full (reserve raised, then restored): 400 in HU and EN, nothing installed. The page is blocked with the same numbers as the check (2,798 vs 2,698); screenshots P2/shots/. After the restore the page allows it.
• Tests TestR1125_* (2), red-proved. Fixtures deploy_new_blocked, deploy_new_memory_blocked re-captured as *_r1125 (only that sentence); every other fixture byte-identical.

3. CI mail (R-1129)

• Key length: all four repos' CI sees a key of length 36. A manual workflow_dispatch input force_alarm was added in all four; push runs are unchanged.
• The forced run: felhom.eu job 1997 — RESEND-ACCEPTED id=01a1497a-… at 10:48:54 UTC, to admin@felhom.eu. The Gmail catch-all holds it (10:48:55Z).
• R-1129 is closed as „not a defect":
  • my earlier reading took the script's own source line for its output;
  • every cited job had in fact sent its mail;
  • the four CLAUDE.md „emails on failure" lines were true all along.
• The controller CHANGELOG line that repeated my wrong claim is corrected.

4. STATUS and Tester 1

• STATUS:
  • The duplicate „D10" was already fixed by the cc-creds session: its decision moved to the „What works" list, and its new decisions are D13–D16.
  • D10, D11 and D12 are marked decided with your answers.
• Tester 1 (R-1124):
  • Before: four mnt-media_*.mount units, „Managed by felhom-agent", inactive, for the removed drives' UUIDs.
  • I disabled and removed them, then reloaded systemd. After: only adatlemez's units are left, and 3 minutes later the agent had not written them back.
  • But the agent still lists the four drives and logs „enrolled drive absent by UUID — will retry" every ~20 s. That needs the agent change R-1124 names, and it waits for a vouched agent release.

5. Versions, commits, fixtures

• Controller 0.327.1 (MinAgent 0.158.1, no golden), built from 71fbef6 in a fresh clean clone with that clone's own build script. The shared clone had another session's open edits, so FELHOM_REPO_DIR pointed the build at the fresh clone.
  • Test images:
    • 0.327.0-rc.1 — built, never deployed: the TOCTOU fix replaced it;
    • rc.2, rc.3, rc.4 — on 9202;
    • 0.327.1-rc.1 — on 9201 and 9202.
  • 0.327.0 was released at 11:43 UTC to the three test boxes only. Its box walk found the timeout; it was never the global floor.
  • 0.327.1: per-box floors at 12:04:44; all three on it by 12:05:23; box walk green; https-only OK. Global floor 12:06:54 UTC (303 floor_set), read back from hub.db + WAL (0.327.1=0.158.1, no per-box floor) and from the page.
  • Controller commits: e3bb775, 8f029aa, 67a4b45, a4c0d54, 0c6ce95, 71fbef6.
• Catalog: 1af6ea7. Helper (CI): 498b9139 felhom.eu, 411d776 controller, c899c82 catalog, 344c4f9 agent.
• Fixtures: 2 replaced under new names; 155 byte-identical.
• 9202 runs 0.327.1. Its settings were put back byte-identical: controller.yaml.pre-r1125 was copied back.

6. Rows

• Before: 181 (after the cc-creds session's push).
• Closed: R-1126, R-1125 and R-1129 (3).
• Opened: R-1135 (the CI mail's link uses the cluster address), R-1136 (felhom.eu CI runs longer than the 5 minutes R-265 assumes), R-1137 (a rerun may overwrite a failed job's log — unproven) (3).
• After: 181.
• R-1124 stays open, with the note above.

7. Observations

1. FileBrowser's own admin-password setting re-applies at every start. NOT-A-FINDING: the reason Path 2 was built (01 §5).
2. 0.327.0's label route timed out on demo-hp and the N100 (~21 min). NOT-A-FINDING: found by the release's own box walk, fixed in 0.327.1 the same hour; N100 diary updated.
3. A TOCTOU in the first gate (connect by name). NOT-A-FINDING: found by the commit security review, fixed before any release.
4. The install page used /proc's host-wide memory, unlike the check. NOT-A-FINDING: fixed in 0.327.0 (small).
5. R-1129's diagnosis was false (my misreading of CI logs). NOT-A-FINDING: row closed as not a defect, cause written in it.
6. The CI mail's „Run" link points at the in-cluster Gitea address. FILED: R-1135
7. felhom.eu CI runs ~6.9 minutes, past the 5 minutes R-265 assumes. FILED: R-1136
8. A CI rerun may overwrite a failed job's log. FILED: R-1137
9. The agent keeps listing decommissioned, removed drives. NOT-A-FINDING: already R-1124, note added.
10. My first 9202 probe was stopped locally but ran on in the guest and upgraded it. NOT-A-FINDING: a scratch box; the upgrade was the intended next step, its log recorded.

8. Teardown (three layers)

• Machine:
  • 9202: the probe scripts removed; FileBrowser re-created three times (scratch); its settings put back; it runs 0.327.1.
  • 9201: Uptime Kuma removed through the product (no volume left).
  • Tester 1: as in §4.
  • No throwaway container or volume left (r1126-* cleaned).
• Host: Tester 1's four mount units removed (§4); nothing else.
• Hub: per-box floors set and cleared; global floor 0.327.1 / MinAgent 0.158.1.