# 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.` 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.` 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.` 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.` 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.