[!NOTE]
CT 105 bündelt den gesamten Download-Stack: Indexer, Download-Clients und Medien-Manager (Filme/Serien/Musik).
105downloads192.168.178.63| Domain | Dienst |
|---|---|
https://requests.ls-cloud.biz |
Jellyseerr (Anfragen-Portal) |
https://qbit.ls-cloud.biz |
qBittorrent |
https://usenet.ls-cloud.biz |
SABnzbd |
https://sonarr.ls-cloud.biz |
Sonarr |
https://radarr.ls-cloud.biz |
Radarr |
https://lidarr.ls-cloud.biz |
Lidarr |
https://dl.ls-cloud.biz und https://download.ls-cloud.biz |
Prowlarr (zwei Domains, gleiches Ziel) |
Alle bis auf Jellyseerr/qbit/usenet laufen hinter Authelia-2FA.
| Port | Dienst | Typ | Beschreibung |
|---|---|---|---|
9696 |
Prowlarr | systemd (nativ) | Indexer-Manager (Torrent + NZB) |
8989 |
Sonarr v4 | systemd (nativ) | Serien-Manager |
7878 |
Radarr v6 | systemd (nativ) | Film-Manager |
8686 |
Lidarr | systemd (nativ) | Musik-Manager, User lidarr (uid 994) |
5055 |
Jellyseerr | Docker | Anfragen-Portal |
8081 |
qBittorrent | Docker (via gluetun) | Torrent-Client, läuft im VPN-Netzwerk-Namespace |
8082 |
SABnzbd | Docker | Usenet-Client |
8191 |
FlareSolverr | Docker | Cloudflare-Bypass-Proxy für geschützte Indexer (seit 2026-07-14) |
Docker Compose: /opt/downloads-stack/docker-compose.yml (gluetun + qbittorrent + sabnzbd + flaresolverr)
qBittorrent läuft mit network_mode: service:gluetun → jeder Torrent-Traffic geht zwingend durch den WireGuard-Tunnel (NordVPN, Kill-Switch aktiv). Ohne laufenden/gesunden Gluetun-Container bekommt qBit keine Netzwerkverbindung — das ist Absicht, nicht kaputt.
[!WARNING]
qBittorrent nie ohne laufenden Gluetun betreiben. 2026-06-22 gab es eine Abmahnung, weil der VPN-Tunnel monatelang (OpenVPN AUTH_FAILED) deaktiviert war und Torrents über die echte Haus-IP liefen. Seit 2026-06-23 läuft WireGuard statt OpenVPN.
Sonarr: 081d0986ed1546dabb77740529ed5c3c
Radarr: 08b59f420f21404c9891e63cc31ee894
Prowlarr: 8d9b1b92750f4f48b7ae0350ab0b376e
Lidarr: 0599f134682e43568ef6a394bf61bc69
SABnzbd: 79a1e15c62214286940c805ca8d5ac5f
/srv/storage/downloads/torrents qBittorrent Downloads
/srv/storage/downloads/usenet SABnzbd Downloads
/srv/storage/media/movies/demovies Radarr – Deutsche Filme (default)
/srv/storage/media/movies/rumovies Radarr – Russische Filme
/srv/storage/media/series/deseries Sonarr – Deutsche Serien (default)
/srv/storage/media/series/ruseries Sonarr – Russische Serien
/srv/storage/media/kids Kids-Bibliothek (Filme+Serien)
/srv/storage/media/music Lidarr Root-Folder (= Navidrome-Quelle, CT131)
Sonarr/Radarr/Lidarr laufen nativ (nicht in Docker), SABnzbd/qBittorrent laufen in Docker — die *arr-Apps sehen die Docker-internen Downloadpfade (/downloads/...) nicht direkt und brauchen Remote-Path-Mappings:
Host localhost :/downloads/ → /srv/storage/downloads/torrents/ (qBittorrent)
Host 192.168.178.63 :/downloads/ → /srv/storage/downloads/usenet/ (SABnzbd)
[!TIP]
Bei manuellem NZB-Push direkt an SABnzbd immer die echte Container-IP (192.168.178.63) nutzen, nielocalhostin der NZB-URL — SABnzbd läuft in einem eigenen Docker-Netzwerk-Namespace,localhostdort zeigt ins Leere.
flaresolverr auf Proxy UND Indexer setzen, sonst bleibt der Indexer trotz laufendem FlareSolverr geblockt)[!WARNING]
Tag-Falle (gefunden 2026-07-11): Ein Tag auf einem Indexer/Download-Client, das keine einzige Serie/kein Film im gleichen Tag hat, macht die Komponente für die komplette Bibliothek unsichtbar — ganz ohne Fehlermeldung im UI (nur im Debug-Log als zu niedrige „X active indexers"-Zahl sichtbar). Bei „Indexer sollte eigentlich Treffer haben, findet aber nichts":GET /api/v3/indexerund/api/v3/downloadclientauftagsprüfen.
URL: https://requests.ls-cloud.biz
Login: admin@ls-cloud.biz / Admin123!
pct status 105
curl -I http://192.168.178.63:9696 # Prowlarr
curl -I http://192.168.178.63:8989 # Sonarr
curl -I http://192.168.178.63:7878 # Radarr
curl -I http://192.168.178.63:8686 # Lidarr
curl -I http://192.168.178.63:5055 # Jellyseerr