Frank
e7f0d93c86
The docs-fact census wave re-read the live hosts and re-keyed every page it could: runtime/payload identities, ports, sizes, ledger figures, unit state, and the retirement banners that drifted as the fleet moved. The wave was interrupted mid-run, so this commit carries only what passed the integrity gates: every touched page parses (front matter or H1+status convention intact, balanced fences, no truncated tables, trailing newline), the docs_completeness and link-integrity seams are green, and bats is 384/384. Numbers that this session proved on live hosts are keyed to the measured value, not the page's earlier claim.
7.5 KiB
type, description, tags, timestamp
| type | description | tags | timestamp | ||
|---|---|---|---|---|---|
| reference | Seerr is the unified request manager for the *arr stack (the maintained `seerr-team/seerr` successor to the archived Overseerr/Jellyseerr line). |
|
2026-09-02 |
Seerr
Seerr is the unified request manager for the *arr stack (the maintained seerr-team/seerr successor to the archived Overseerr/Jellyseerr line). It is meant to route approvals to Sonarr/Radarr/Lidarr/Readarr on FrankBook-Pro and push downloads to qBittorrent. It is not launched: shared/homepage/services.json ships the card with wip: "down", showLink: false and the description "Work in progress: not open to family users yet", and /srv/homepage/status.json (2026-10-18) still reports it wip-down even though the container is up. Treat every "Frank's household uses it" framing as future tense.
Host: Dankclaw — Hostname: seerr.franksdank.cloud (Caddy, guarded) — Docs: https://github.com/seerr-team/seerr
Facts (verified live 2026-09-01, re-verified 2026-10-18)
| Item | Value |
|---|---|
| Image | ghcr.io/seerr-team/seerr:v3.4.1 (unit pin dankclaw/seerr/quadlet/seerr.container:32; live container reference podman inspect seerr 2026-10-18). Runs as the in-image node user, uid 1000 (podman top seerr user uid) |
| Port | 5055 (container), published 127.0.0.1:5055 only (seerr.container:34; ss -ltn shows 127.0.0.1:5055 and no 0.0.0.0 bind, 2026-10-18) |
| Data | /home/dank/Containers/seerr/data → /app/config (SQLite settings store, seerr.container:35; the live dir exists and is owned by uid 100999 — see UID mapping) |
| Unit | dankclaw/seerr/quadlet/seerr.container → seerr.service; Restart=always/RestartSec=5 (:38-39), [Install] WantedBy=default.target (:42-43), installed under ~/.config/containers/systemd/ and reported generated / active with Linger=yes (2026-10-18) — boot-persistent |
| Network | dankclaw_default (post-auth listener reachability); live address 10.89.1.12 on the 10.89.1.0/24 bridge (podman inspect seerr, podman network inspect dankclaw_default 2026-10-18) |
| Guard | Caddy TLS edge → Anubis :8923 → Authentik outpost provider seerr-proxy (unverified 2026-10-18: the provider name lives in Authentik's own DB) → Caddy :8017 @seerr handler → seerr:5055 (dankclaw/Caddyfile:149-150 for the challenged vhost, :371 for the post-auth reverse_proxy seerr:5055) |
| DNS | Pi-hole addn-hosts only: 192.168.0.143 seerr.franksdank.cloud (dankclaw/pihole/addn-hosts:46). The public Porkbun A record was deleted on 2026-09-02, so the name resolves on the LAN (→ 192.168.0.143) and not on the WAN — re-checked 2026-10-18: a public-resolver query for seerr.franksdank.cloud returns no A record, while ai.franksdank.cloud returns the WAN address. Seerr is internal-only by construction |
Why loopback-only publishing
Seerr is browser-facing; the only sanctioned user path is the guard chain (Caddy → Anubis → Authentik SSO). PublishPort=127.0.0.1:5055:5055 keeps the app off the LAN entirely while still letting the homepage probe agent and host-local checks reach it — the same loopback convention as other guarded hosts (see Homepage Design Grilling).
There is no health endpoint to point at: measured on 2026-10-18, GET http://127.0.0.1:5055/ answers 307 (redirect into the app) and GET /api/v1/version answers 404 — Seerr does not expose that path, so do not wire it as a health probe. The homepage card probes 127.0.0.1:5055 and is marked wip: "down", which is why the card stays hidden while the container is up.
Guard chain fix (2026-09-02)
The seerr-proxy provider was provisioned by script with no flows and no
Application — silently broken in two ways: the null flows wedged the
embedded outpost's config deserializer (taking every guarded vhost down at
the next outpost reload), and the missing app bounced post-login to
authentik's own user UI instead of Seerr. Both backfilled live: the three
standard flows copied from a known-good provider, plus an application
(seerr-guard) linked to the provider. Verified by the hardened SSO sweep
(tests/e2e/specs/13-sso.spec.ts) — see Authentik for the two
provisioning rules this incident established.
*arr wiring
Seerr reaches the *arr services on FrankBook-Pro (192.168.0.112, gluetun-NetNS stack inside the Mac's podman machine VM) by IP-based base URLs (http://192.168.0.112:<port>), configured inside Seerr's own web settings — not in env or quadlet. The .lan hostname variant was deliberately dropped: dankclaw/pihole/addn-hosts carries no frankbook-pro.lan record (verified against the file, 2026-10-18), and IP bases match the Mac stack's verified LAN reachability. (unverified 2026-10-18: 192.168.0.112 is offline at this census — ping fails and the arr probes report down in /srv/homepage/status.json, so LAN reachability from Seerr could not be re-measured; the quadlet header's "resolved via the Pi-hole addn-hosts record frankbook-pro.lan" is stale for the same reason — no such record exists.) API keys live in each arr's config.xml on the Mac and are entered through Seerr's settings store. (unverified 2026-10-18: the keys are inside Seerr's SQLite store, not readable from the repo.)
OIDC single-sign-on for Seerr (Authentik OIDC provider + Seerr OIDC config) remains an open option; the guard chain already authenticates the front door, so this is an in-app setting deferred to Frank's first-run session.
UID mapping gotcha
The container runs as node (uid 1000 in-image — podman top seerr user uid 2026-10-18). Rootless podman's mapping on this host is 0 → 1000 (size 1), 1 → 100000 (size 65536) (/proc/<pid>/uid_map of the running container; podman unshare cat /proc/self/uid_map agrees), i.e. container uid N ≥ 1 → host uid 100000 + N - 1, so uid 1000 → 100999. That is the owner the data tree actually carries: ls -n /home/dank/Containers/seerr/data shows 100999 100999 on db/, logs/ and the files the app writes (2026-10-18). The first deploy chowned the data dir to 100999 + 1 (= 101000) and crash-looped with EACCES mkdir /app/config/logs. Rule: read the real mapping from a running container's /proc/<pid>/uid_map before chowning bind roots for non-root images.
Deployment
./scripts/deploy.sh dankclaw --service seerr (seerr is a registered service in scripts/deploy.sh:143). The deployer pre-creates the bind-source dir, installs the unit, and restarts. First visit after deploy: complete the Seerr local-admin setup wizard (the guard chain bounces through Authentik first). TLS issuance for a new vhost fires at Caddy reload (dns-01) — allow ~15 s before the first HTTPS probe.
Citations
- Seerr image and volume contract: https://github.com/seerr-team/seerr (official docs recommend
/app/configpersistence) - Quadlet unit:
dankclaw/seerr/quadlet/seerr.container(image pin:32, loopback publish:34, volume:35,Restart=always/WantedBy:38-43) - Guard chain:
dankclaw/Caddyfile:149-150(challenged vhost) anddankclaw/Caddyfile:371(post-authreverse_proxy seerr:5055) - DNS:
dankclaw/pihole/addn-hosts:46; public-resolver query forseerr.franksdank.cloud(no record), 2026-10-18 - Homepage state:
shared/homepage/services.json(Seerrcard,wip: "down") and/srv/homepage/status.json2026-10-18 (wip-down) - Host evidence 2026-10-18:
podman ps,podman inspect seerr,podman top seerr user uid,ss -ltn,curl 127.0.0.1:5055/→ 307,curl 127.0.0.1:5055/api/v1/version→ 404,systemctl --user is-enabled/is-active seerr