felhom.eu/documentation/audits/qbittorrent-2026-10-12/README.md

# Download clients for the catalog — qBittorrent and Transmission (2026-10-12)

**Why.** Radarr, Sonarr and Seerr have been in the catalog for months and **none of them downloads
anything** — they decide what to fetch and hand it to a download client. There was no download
client. Radarr's own template said so in its prerequisites („Letöltő kliens szükséges (pl.
qBittorrent — külön telepítendő)") while the website promised „Automatikus film letöltő… a filmek
automatikusan a könyvtáradba kerülnek". Operator ruling, 2026-10-12: add them.

**Where this run got to. Both are PUBLISHED** — `app-catalog-felhom.eu` `9081a47`, the two templates
and their two complete onboarding records in one commit, with the README and FIRST-ADMIN rows, the
fixtures for both venues and the website cards. Each was measured twice before that: on the bench
(LXC 9401 on demo-hp) and on scratch guest 9202 **through the product**.

## What is in here

| | |
|---|---|
| `bench/` | qBittorrent on LXC 9401: image, telemetry, entrypoint, first admin, storage, ownership, health, memory, a real download, the config as the app rewrote it, and `MV-qbittorrent/` — the harness verdict for the ladder step |
| `transmission-bench/` | the same twelve questions asked of Transmission, plus `MV-transmission/` |
| `box/` | guest 9202 through the product: the two box walks, the per-app box verdicts under `qbittorrent/` and `transmission/`, the app logs, `verify-fixes.json` (the proof the defects below are gone) and `teardown-newapps.json` |
| `tools/` | `boxwalk_newapps.py` (deploy + stranger + sign-in + lock-out through traefik) and `verify_fixes.py` (the re-measure). Both reuse the 2026-09-30 harness for the session, CSRF and setup gate |

## Six defects, each found by measuring and fixed before publication

1. **qBittorrent was unreachable on its own public name.** `WebUI\ServerDomains` with a comma list
   makes the app answer 401 „Invalid Host header" to everything, its own name included; semicolons
   work **through the API** (the four-way test: comma 401/401, single 200/401, semicolon 200/200, `*`
   200/200). Nothing upstream documents the separator.
2. **…and the config file's own dialect drops the extra entries anyway.** A semicolon list seeded
   into `qBittorrent.conf` comes back from the app's first read-write cycle as the public name
   **alone**, after which the controller's health probe — which dials by container name — is refused
   („Invalid Host header … 'qbittorrent:8080'"). The list moved into `after_install`, where the API
   honours it, and the marker is printed only after both the list and the UPnP flag are read back.
3. **Both clients asked the household's router to open a port.** qBittorrent logs
   `UPnP/NAT-PMP support: ON` and tries a mapping; Transmission ships `"port-forwarding-enabled": true`.
   The box opens no port at home (`../architecture/01-topology-and-trust.md` §7), so both are off now.
   qBittorrent's seeded `Session\UseUPnP=false` **is written and then ignored at first start** — the
   app reported `"upnp": true` with that very line in its config — so it goes through `after_install`,
   which the app does honour: `ON` at 17:21:51, **`OFF` at 17:21:56** (`box/verify-fixes.json`).
4. **Transmission could never become healthy.** It answers 401 on every path once authentication is
   on, so `curl -f` always failed (`exit 22`). The probe accepts 200 or 401 now, with a negative
   control that still fails.
5. **Transmission's host whitelist refused its own healthcheck** (400 to `Host: 127.0.0.1`). The
   local names are admitted beside the public one.
6. **Two fixtures were reading the wrong thing.** The box fixture looked for a cookie named `SID`;
   qBittorrent 5.x names it `QBT_SID_<port>`. The Transmission fixture read the session id with an
   `awk` that matched the header NAME on a second line and so got 400 on every RPC; it uses an
   anchored `sed` now, with the payload on stdin.

**And one finding that was not a defect.** The first box walk looked like a household lock-out.
Stranger and household ran from the same machine, so a shared ban could not be told from a
per-visitor one. Re-run from two addresses: the stranger is banned (`401 401 401 401 401 403`, and
403 on the right password) while **the household signs in at the same instant (204)**. qBittorrent
reads the real visitor address through the proxy headers; its log names `192.168.0.180`, not traefik.
Transmission does not ban at all.

## Does a download work with no inbound port? Measured, yes

The operator's question. With port mapping off and neither peer port published, each client was given
one real torrent (Big Buck Bunny, Blender Foundation, CC BY) through its **own** interface:

| | finished | where the files landed |
|---|---|---|
| qBittorrent | yes, inside a minute — `progress: 1`, `downloaded: 276610512` | `…/media/torrents/Big Buck Bunny/` (`bench/09-download.txt`) |
| Transmission | yes — `percentDone: 1.0`, `status: 6` (seeding) | `…/media/transmission/complete/Big Buck Bunny/` (`transmission-bench/05-download.txt`) |

Both files are the completed-state snapshots, which is why their peer counts read 0: the swarm work
was over. The tunnel is not involved either way — Cloudflare carries the app's **web page** inbound,
while peer traffic goes out through the household's own router by NAT. What a closed port costs is
incoming peers (slower on sparse swarms, less upload), and the app text now says so.

## State left behind — three layers, verified

- **Machine (guest 9202):** both apps removed **through the product** (`POST …/stop` then
  `…/remove` with the drive data), `deployed: false` for both, the two config volumes gone, no
  container left, and the two download folders deleted from the scratch drive by name. The guest's
  standing apps (filebrowser, paperless) are untouched and running. `box/teardown-newapps.json`.
- **Catalog pointer:** the controller is back on the **live** catalog from this run's own saved copy
  (`controller.yaml.pre-newapps1012`), the cache removed with it (R-615 — `repo_url` alone is inert),
  and the restoration is proven from a **different channel than the controller's own verdict**
  (R-286): the sha256 of `qbittorrent`, `transmission` and `grocy`'s `.felhom.yml` on the box equals
  the sha256 of the same files at the published `origin/main`, with a decoy pair that must differ and
  does. The config names the drill repo zero times.
- **Host (demo-hp):** bench LXC 9401 has no containers and no volumes and is **stopped**, as it was
  found. The drill catalog `admin/app-catalog-drill` is reset to the live `main` (`9081a47`), so it
  carries the published templates and no work in progress.
- **Hub:** nothing to undo — 9202 reports to no hub by its own configuration (the config header says
  hub reporting OFF, no tunnel, no agent local API).