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.