Fehler-Finder: Selfhosting-Fehlermeldungen nachschlagen

Fast immer fehlt der Provider-Zusatz: Eine im File-Provider definierte Middleware heißt aus Sicht der Docker-Labels name@file. Ohne Zusatz sucht Traefik sie unter den Docker-Labels – und findet nichts. Umgekehrt gilt dasselbe für name@docker.

Die $-Zeichen im bcrypt-Hash wurden von Docker Compose als Variablen interpretiert. Im Compose müssen sie verdoppelt werden ($$2y$$05$$…). Mit docker compose config siehst du den Wert, der wirklich ankommt.

Sequenzielle curl-Aufrufe sind zu langsam: Jeder Prozess baut eine neue Verbindung auf, damit bleibst du unter dem Limit. Teste parallel, etwa mit seq 40 | xargs -P 8 -I{} curl … – dann erscheinen die 429.

Traefik sieht nicht deine IP, sondern die des davorstehenden Proxys (Cloudflare, Load-Balancer). Prüfe mit traefik/whoami, was in X-Forwarded-For steht, und arbeite bei mehrstufigen Aufbauten mit ipallowlist.ipstrategy.depth.

Die Middleware heißt in Traefik v3 ipAllowList; der alte Name wurde entfernt, die Regel greift damit nicht mehr. Beim Umstieg alle Vorkommen umbenennen.

Das ist HSTS und kein Fehler: Der Browser hat sich max-age gemerkt und erzwingt HTTPS selbst dann, wenn dein Server es nicht mehr anbietet. Zum Testen hilft ein privates Fenster oder ein anderer Browser – und deshalb die Warnung zu preload oben.

Meist fehlt traefik.http.services.dockge.loadbalancer.server.port=5001. Dockge lauscht im Container auf 5001; ohne die Zeile rät Traefik. Prüfe außerdem, dass der Container im proxy-Netz hängt.

Host- und Container-Pfad des Stacks-Verzeichnisses stimmen nicht überein. Es muss /opt/stacks:/opt/stacks gemountet und DOCKGE_STACKS_DIR=/opt/stacks gesetzt sein – Dockge lässt den Docker-Daemon des Hosts arbeiten, und der kennt nur Host-Pfade.

Dann liegt er außerhalb von /opt/stacks, und Dockge zeigt „Dieser Stack wird nicht von Dockge verwaltet." Verschiebe den Ordner wie in Schritt 7 – Dockge übernimmt ihn nicht von selbst und legt auch keine Kopie an.

Erlaubt sind nur Kleinbuchstaben, Ziffern und Bindestriche, weil daraus Ordner- und Compose-Projektname werden. Meine App geht nicht, meine-app schon.

Dann wurde ./data nicht persistent gemountet – dort liegen Datenbank und JWT-Secret. Prüfe, dass /opt/dockge/data existiert und im Compose eingebunden ist.

Dockge richtet sich nach dem Browser und fällt bei unbekannten Kombinationen auf Englisch zurück; in den Einstellungen lässt sich die Sprache fest wählen.

Der erste Scan läuft nicht automatisch – das ist kein Fehler, sondern Audiobookshelfs Verhalten. Klick in der Bibliotheksansicht auf Bibliothek scannen. Bleibt sie danach leer, prüfe mit docker compose exec audiobookshelf ls -R /audiobooks, ob der Container die Dateien überhaupt sieht, und mit ls -ln /opt/audiobookshelf/audiobooks, dass alles UID 1000 gehört.

Die Dateien liegen direkt im Autoren-Ordner statt in einem gemeinsamen Titel-Ordner. Audiobookshelf gruppiert nach Autor/Titel/ – Dateien in einen Unterordner mit dem Buchtitel legen und erneut scannen.

Meist fehlt traefik.http.services.abs.loadbalancer.server.port=80. Audiobookshelf lauscht im Container auf 80; ohne diese Zeile rät Traefik und trifft daneben. Prüfe außerdem, dass der Container wirklich im proxy-Netz hängt.

Das ist normal: Das Frontend wird mit diesem festen Router-Pfad ausgeliefert, und ROUTER_BASE_PATH ändert daran zur Laufzeit nichts, weil der Pfad im Image eingebaut ist. https://DEINE_DOMAIN bleibt als Einstieg gültig.

Die Sprachwahl liegt lokal im Browser, nicht am Konto. Auf dem neuen Gerät einmal über den Benutzernamen → Language → „Deutsch" setzen.

Die Suche fragt den iTunes-Katalog ab; ein Tippfehler oder ein dort fehlender Eintrag führt zu „Keine Suchergebnisse". Nimm stattdessen die RSS-URL des Podcasts – dasselbe Feld akzeptiert beides.

Die HTTPS-Erkennung fehlt. Prüfe, dass der WORDPRESS_CONFIG_EXTRA-Block mit HTTP_X_FORWARDED_PROTO und den $$-Zeichen exakt gesetzt ist (siehe Warnung in Schritt 2), und starte den WordPress-Container neu.

Meist eine Race Condition oder ein Passwort-Mismatch. Prüfe, dass depends_on: condition: service_healthy gesetzt ist und WORDPRESS_DB_PASSWORD exakt MARIADB_PASSWORD entspricht. Logs: docker compose logs db.

Die Datenbank braucht beim allerersten Start einige Sekunden zur Initialisierung. Mit dem Healthcheck ist das abgedeckt; ohne ihn hilft ein erneutes docker compose up -d.

PHP begrenzt die Upload-Größe. Lege eine eigene uploads.ini an und mounte sie nach /usr/local/etc/php/conf.d/ mit z. B. upload_max_filesize = 64M und post_max_size = 64M.

WP_HOME/WP_SITEURL in der Compose-Datei stehen fest verdrahtet – bei einer neuen Domain dort anpassen und Container neu starten (die Werte überschreiben die Datenbank-Einstellung).

LD_CSRF_TRUSTED_ORIGINS: https://DEINE_DOMAIN fehlt oder ist falsch (muss mit https:// und ohne Pfad angegeben sein). Ergänzen und docker compose up -d (siehe Warnung in Schritt 1).

Der Healthcheck ist noch nicht healthy – Traefik leitet dann bewusst nicht. Rund 30 Sekunden nach dem Start abwarten; Status mit docker inspect -f '{{.State.Health.Status}}' linkding-linkding-1 prüfen.

Die Zielseite blockiert automatisierte Zugriffe oder antwortet zu langsam. Du kannst Titel und Beschreibung dann einfach von Hand eintragen – die Felder stehen im selben Formular.

LD_SUPERUSER_NAME/LD_SUPERUSER_PASSWORD greifen nur beim ersten Start mit leerer Datenbank. Existiert die data-Datenbank schon, ändert eine spätere Anpassung nichts. Konto nachträglich anlegen: docker compose exec linkding python manage.py createsuperuser.

Fast immer der API-Token oder die URL. Token unter Settings → Integrations neu erzeugen und exakt https://DEINE_DOMAIN als Server eintragen.

Entweder liegen keine Dateien im gemounteten music-Ordner, oder die Rechte stimmen nicht. Prüfe: docker compose logs | grep -i scan zeigt tracksImported. Ist es 0, kontrolliere den Pfad und dass der music-Ordner UID 1000 gehört (siehe Benutzer & Rechte).

Die Metadaten der Dateien sind unvollständig. Navidrome sortiert nach Tags, nicht nach Dateinamen – tagge die Dateien nach (z. B. mit Picard) und lass Navidrome erneut scannen.

Der Scan läuft nur stündlich (ND_SCANNER_SCHEDULE). Einen sofortigen Scan stößt du in der Weboberfläche über das Aktualisieren-Symbol oben an, oder du wartest bis zum nächsten Intervall.

Fast immer die Server-URL: Sie muss https://DEINE_DOMAIN lauten (mit https://, ohne Pfad). Prüfe außerdem, dass Benutzername/Passwort exakt stimmen – manche Apps verlangen zusätzlich die Aktivierung der Subsonic-Kompatibilität, die bei Navidrome standardmäßig an ist.

Die Bandbreite reicht nicht fürs Original. Transcoding für den mobilen Player aktivieren (siehe Tipp in Schritt 7).

DB_NAME: /data/hc.sqlite fehlt oder der data-Ordner gehört nicht UID 1000. Pfad setzen und chown -R 1000:1000 /opt/healthchecks/data (siehe Warnung in Schritt 2).

Häufigste Ursache: ein Umlaut in SITE_NAME (oder einer anderen Text-Umgebungsvariable). Auf reines ASCII umstellen und neu starten. Zur Diagnose vorübergehend DEBUG: "True" setzen – aber danach wieder auf False.

CSRF_TRUSTED_ORIGINS: https://DEINE_DOMAIN muss gesetzt sein – Django lehnt sonst POST-Anfragen hinter dem Reverse Proxy ab. Und ALLOWED_HOSTS muss exakt deine Domain enthalten.

Prüfe, ob der curl-Ping wirklich ausgeführt wird und die richtige UUID trifft: curl -v https://DEINE_DOMAIN/ping/UUID sollte OK zurückgeben. Auf der Detailseite siehst du im Protokoll, ob und von welcher IP Pings ankommen.

Es ist kein Integrations-Kanal zugewiesen, oder (bei E-Mail) fehlen die SMTP-Einstellungen. Unter „Integrations“ einen Kanal einrichten und dem Check zuweisen.

Der Healthcheck ist noch nicht healthy – Traefik leitet dann bewusst nicht. Nach dem Start 20–30 Sekunden warten; Status mit docker inspect -f '{{.State.Health.Status}}' stirling-stirling-pdf-1 prüfen.

Entweder wurde das Passwort schon geändert (dann das neue nutzen), oder die Konfiguration im configs-Volume ist inkonsistent. Zum Zurücksetzen die Anwendung stoppen und die Nutzerkonfiguration im configs-Ordner prüfen; im Zweifel den Ordner leeren (Achtung: setzt alle Einstellungen zurück).

Die passende .traineddata fehlt im tessdata-Volume. Die Datei von den Tesseract-Sprachpaketen holen und in den data-Ordner legen (siehe Schritt 5).

Solche Konvertierungen brauchen zusätzliche Werkzeuge (LibreOffice), die nur in den größeren Image-Varianten enthalten sind. Für den vollen Funktionsumfang die -fat-Variante des Images verwenden (stirlingtools/stirling-pdf:2.14.3-fat).

OCR und Konvertierung sind speicherintensiv. Auf einem kleinen VPS kann RAM knapp werden – dann entweder kleinere Dateien verarbeiten oder auf ein größeres Produkt wechseln.

Die Rechte am config- oder data-Ordner stimmen nicht. chown -R 1000:1000 /opt/syncthing/config /opt/syncthing/data und neu starten (siehe Warnung in Schritt 1).

Der Healthcheck ist noch nicht healthy – Traefik leitet dann bewusst nicht. Bis zu 60 Sekunden nach dem Start abwarten und den Status prüfen (siehe Warnung in Schritt 3).

Prüfe drei Dinge: Ist Port 22000 (TCP+UDP) in der Firewall offen? Hast du die ID auf beiden Geräten eingetragen (die Kopplung ist beidseitig)? Und stimmt die ID exakt (Buchstabendreher fallen leicht auf, weil eine Prüfsumme eingebaut ist)? Der Status „Getrennt“ mit korrekt eingetragenen IDs deutet fast immer auf den Firewall-Port.

Meist fehlt auf der Gegenseite die Bestätigung der Freigabe, oder die Ordner-ID stimmt nicht überein – sie muss auf beiden Geräten identisch sein. Prüfe außerdem die Schreibrechte im Zielordner.

Passwort vergessen? Du kannst es in der config.xml (<gui>-Block) zurücksetzen, indem du die <user>- und <password>-Zeilen entfernst und Syncthing neu startest – danach ist die Oberfläche wieder ohne Login erreichbar (und du setzt es sofort neu).

Der Container läuft als www-data (UID 33). Bei bind-gemountetem ./data müssen die Rechte passen: chown -R 33:33 /opt/freshrss/data (siehe Benutzer & Rechte).

Prüfe, ob CRON_MIN gesetzt ist und der interne Cron läuft: docker compose logs freshrss | grep -i cron. Manuell anstoßen kannst du jederzeit über den Aktualisieren-Knopf oben rechts oder docker compose exec -u www-data freshrss ./cli/actualize-user.php --user admin.

Die Quelle liefert kein gültiges RSS/Atom, oder die URL ist eine HTML-Seite statt des Feeds. Viele Seiten verstecken den Feed – suche im Seitenquelltext nach application/rss+xml. Unter „Statistiken → Inaktive Feeds“ findest du Problemquellen gebündelt.

FreshRSS verschlüsselt das Passwort im Browser (JavaScript). Ist JavaScript deaktiviert oder die Verbindung nicht wirklich HTTPS (Zertifikatswarnung), scheitert der Login. Über Traefik ist HTTPS gegeben – prüfe im Zweifel das Zertifikat.

FreshRSS bereinigt alte Artikel nach einer einstellbaren Frist (Standard: einige Wochen). Das ist gewollt und hält die Datenbank klein; erhöhe bei Bedarf die Aufbewahrung pro Feed in dessen Einstellungen.

systemd konnte das Programm aus ExecStart nicht ausführen; im Journal steht dazu Unable to locate executable. Entweder stimmt der Pfad nicht, oder der Datei fehlt das Ausführbar-Bit (chmod +x). Ohne führenden / sucht systemd nur in /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin (nachzusehen mit systemd-path search-binaries-default) – ein eigenes Skript unter /opt oder /root musst du deshalb mit absolutem Pfad eintragen.

Du hast eine Unit-Datei bearbeitet, aber systemd liest Änderungen nicht automatisch. Nach jeder Änderung an /etc/systemd/system/ gilt: systemctl daemon-reload.

Er wurde nicht aktiviert. systemctl enable --now DIENST.timer – und daran denken, dass der Timer den Service auslöst, du also beide Dateien brauchst (.service und .timer).

Der Unit fehlt der Abschnitt [Install] mit WantedBy=; in systemctl status erkennst du sie am static in der Loaded:-Zeile. Ohne [Install] weiß systemd nicht, wann die Unit automatisch starten soll – bei Timern gehört WantedBy=timers.target hinein.

Standardmäßig wächst es begrenzt, aber du kannst es beschneiden: journalctl --vacuum-time=14d löscht Einträge älter als 14 Tage, journalctl --disk-usage zeigt den Verbrauch.

Die häufigste Stolperfalle: HOMEPAGE_ALLOWED_HOSTS fehlt oder enthält die falsche Domain. Genau die Domain eintragen, unter der du zugreifst, dann docker compose up -d.

CPU und RAM liest Homepage aus dem Container heraus (kein Socket nötig). Zeigt disk: / das Container-Dateisystem statt der Host-Platte, binde den gewünschten Pfad zusätzlich als Volume ein (z. B. - /:/host:ro und disk: /host).

Der Name passt nicht zum Icon-Katalog. Schreibe den Dienstnamen klein und ohne Leerzeichen (nextcloud.png), oder lege ein eigenes Bild in den icons-Ordner (gemountet nach /app/public/icons) und referenziere es als /icons/name.png.

Der Wert bei container: muss der exakte Container-Name sein. Finde ihn mit docker ps --format '{{.Names}}' – bei Compose ist das meist ordner-dienst-1 (z. B. traefik-traefik-1).

Ein Syntaxfehler bricht das Einlesen ab. YAML ist einrückungsempfindlich – prüfe die Logs mit docker compose logs homepage auf error-Zeilen und achte auf konsequente Leerzeichen (keine Tabs).

Dann ist HOMEPAGE_AUTH_ENABLED gesetzt, aber Secret oder Passwort kommen leer im Container an – meist, weil die .env im falschen Ordner liegt oder eine Zeile daraus fehlt. Im Log steht dazu Password auth is enabled but required settings are missing; docker compose config zeigt dir, welche Werte Compose wirklich einsetzt.

Fast immer der IPv6-Fallstrick aus Schritt 4: Der Healthcheck fragt localhost ab, nginx lauscht aber nur auf IPv4. Auf http://127.0.0.1/ umstellen. Prüfen mit docker inspect --format '{{.State.Health.Status}}' CONTAINER.

Das ist die Traefik-404, nicht die von nginx – Traefik findet keinen passenden Router. Häufigste Ursachen: Der Container ist noch nicht healthy, die Host()-Regel enthält die falsche Domain, oder das proxy-Netz ist nicht external. Siehe das 502/404-Kapitel in Docker-Netzwerke verstehen.

Die baseURL in hugo.toml stimmt nicht mit der echten Domain überein. Hugo backt absolute URLs auf Basis dieses Werts ein – korrigieren und neu bauen.

Prüfe das date im Front Matter: Liegt es in der Zukunft, baut Hugo den Beitrag nicht (siehe Warn-Box in Schritt 3). Auch ein draft: true versteckt Inhalte im normalen Build.

Der Theme-Ordner fehlt im Build-Kontext – meist, weil er ein Git-Submodul ist, das nicht mitkopiert wurde, oder eine .dockerignore ihn ausschließt. Theme wie in Schritt 1 als echten Ordner ablegen.

Beide hängen nicht im selben benannten Netz, oder einer nutzt das Standard-bridge (kein DNS). Prüfe mit docker inspect -f '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}' CONTAINER, in welchen Netzen ein Container hängt.

Fast immer sind Traefik und die App in verschiedenen proxy-Netzen, weil das Netz doppelt angelegt wurde. external: true im Compose sicherstellen und mit docker network inspect proxy prüfen, ob beide Container gelistet sind.

Das externe Netz existiert noch nicht. Einmalig anlegen: docker network create --ipv6 --subnet fd00:cafe::/64 proxy. Lass Traefik das Netz nicht selbst erzeugen – dann entsteht es ohne IPv6, und hinter dem Proxy steht bei IPv6-Besuchern die Gateway-Adresse statt der echten IP.

Sie hängt zusätzlich in einem nicht-internen Netz (z. B. proxy). Ein Container hat die Summe der Zugriffe aller seiner Netze – die DB gehört nur ins interne Netz, nie ins proxy-Netz.

Docker vergibt 172.x-Bereiche automatisch, aber bei vielen Netzen kann der Pool knapp werden (could not find an available, non-overlapping IPv4 address pool). Ungenutzte Netze aufräumen: docker network prune.

Prüfe die Rechte des übergeordneten Verzeichnisses: Fehlt dort das x-Recht, kommst du gar nicht erst an die Datei heran, egal wie ihre eigenen Rechte aussehen. ls -ld /pfad/zum/ordner zeigt es.

Die neue Gruppe ist in der aktuellen Sitzung noch nicht aktiv – aus- und wieder einloggen (siehe Warn-Box in Schritt 7). id in der neuen Sitzung muss docker anzeigen.

Das bestimmt die umask – sie zieht Rechte von den Vorgaben ab. Der Debian-Standard umask 0022 führt zu 644 für Dateien und 755 für Verzeichnisse. Prüfen mit dem Befehl umask (ohne Argument).

Der Prozess im Container läuft unter einer bestimmten UID (oft nicht root). Setze den Besitzer des Host-Verzeichnisses passend: chown -R 1000:1000 ./data – die richtige UID nennt die Doku des Images (Umgebungsvariablen wie PUID/PGID).

Du hast -G ohne -a benutzt. -G ersetzt die Nebengruppen. Immer usermod -aG verwenden. Reparatur: die fehlenden Gruppen mit usermod -aG gruppe1,gruppe2 benutzer wieder ergänzen.

Die Fotos sind noch (oder teilweise) mit dem alten Modell indexiert – alte und neue Vektoren vertragen sich nicht. Unter Auftrags-Schlangen → Intelligente Suche den Lauf Alle starten und abwarten, bis die Warteschlange leer ist. Genau dieser gemischte Zustand entsteht auch, wenn du nur speicherst und den Neu-Index vergisst.

Bekanntes Verhalten in v3.1.0: Die Sprachangabe, die diese Modelle erwarten, lässt sich in Immich nicht setzen (siehe Warn-Box in Schritt 3). Auf ein XLM-…- oder SigLIP2-Modell wechseln und neu indexieren.

Out of Memory: Das neue Modell passt nicht mehr neben Server, Datenbank und deine übrigen Dienste. Entweder ein kleineres Modell wählen oder mehr RAM – das XLM-Basis-Modell braucht im Betrieb real rund 2 GB nur für den ML-Container.

Fast immer stimmt der Pfad nicht: Als Importpfad gehört der Container-Pfad (/mnt/archiv) hinein, nicht der Host-Pfad. Prüfe mit docker compose exec immich-server ls /mnt/archiv, ob der Container die Dateien überhaupt sieht – kommt dort nichts, fehlt der Volume-Eintrag oder das docker compose up -d nach der Änderung.

Auf Android killt die Akku-Optimierung den Hintergrund-Dienst (App ausnehmen, siehe Schritt 1); auf iOS fehlt die Hintergrundaktualisierung oder iOS priorisiert die App herunter – öfter öffnen hilft tatsächlich. Und: Standardmäßig wird nur im WLAN gesichert – unterwegs „fehlen" Fotos also nur scheinbar.

Der Server liefert das eingebaute Traefik-Notzertifikat (TRAEFIK DEFAULT CERT) aus, weil die Ausstellung fehlschlug. Fast immer: Der A-/AAAA-Record zeigt auf die falsche IP (dig DEINE_DOMAIN prüfen) oder Port 80 ist in der Firewall zu – die HTTP-01-Challenge kommt nie an. Die genaue Ursache steht in den Traefik-Logs: docker compose logs traefik | grep -i acme.

Die Test-CA von Let’s Encrypt ist noch aktiv – Browser vertrauen ihr absichtlich nicht. Staging-Zeile aus der Traefik-Konfiguration entfernen, acme.json leeren, Container neu starten (Details im Traefik-Tutorial).

Die automatische Erneuerung scheitert seit mindestens 30 Tagen – gleiche Ursachenliste wie beim ersten Fehler, nur lange unbemerkt. Falls die Meldung nur auf einem Gerät auftaucht: dessen Systemuhr prüfen, TLS ist zeitkritisch.

Rate-Limit gerissen, meist durch Experimentier-Schleifen gegen die Produktiv-CA. Auf die Staging-CA wechseln, bis das Setup steht – und acme.json ins Backup nehmen, statt Zertifikate neu auszustellen.

Dem System fehlt das Root-Zertifikat aus Schritt 3 – der Root Store ist veraltet. Auf Debian: apt update && apt install ca-certificates.

systemd-resolved (oder ein anderer DNS-Dienst) belegt Port 53. Stub-Listener abschalten wie in Schritt 1, danach docker compose up -d erneut.

Das WireGuard-Interface wg0 mit 10.8.0.1 existiert (noch) nicht – Docker kann den Port nicht an eine nicht vorhandene Adresse binden. Zuerst das WireGuard-VPN einrichten und wg0 hochfahren (ip -br addr show wg0 muss 10.8.0.1 zeigen), dann den Container starten.

Im Assistenten wurde der Admin-Port auf 80 (Vorschlag) statt auf 3000 gesetzt – Traefik leitet aber auf 3000. In ./conf/AdGuardHome.yaml unter http: die address auf 0.0.0.0:3000 korrigieren und docker compose restart.

Der Browser nutzt DNS-over-HTTPS (DoH) und umgeht damit deinen Server komplett – Firefox und Chrome haben das teils standardmäßig aktiv. In den Browser-Einstellungen „Sicheres DNS" / „DNS über HTTPS" deaktivieren. Prüfen kannst du das mit dig @10.8.0.1 … (greift immer).

Overblocking – eine Sperrliste blockt eine Domain, die die Seite wirklich braucht. Im Abfrageprotokoll die gesperrte Domain suchen, per Rechtsklick/Menü freigeben (Ausnahme) oder die zu aggressive Liste deaktivieren.

Der DinD-Dienst heißt anders als docker, aber sein TLS-Zertifikat ist auf docker ausgestellt. Nenne den DinD-Service exakt docker (wie oben) und sprich ihn über DOCKER_HOST: tcp://docker:2376 an – dann passt der Name zum Zertifikat.

Der Runner wurde mit einer internen Instanz-URL (http://forgejo:3000) registriert. Die Job-Container im DinD können diesen Namen nicht auflösen. Neu registrieren mit der öffentlichen URL https://DEINE_DOMAIN (.runner-Datei im Volume vorher löschen oder das Volume neu anlegen).

Falscher oder bereits verbrauchter Token, oder der Runner erreicht Forgejo nicht. Frischen Token holen (Schritt 1) und prüfen, dass der Runner-Container https://DEINE_DOMAIN erreicht (docker compose run --rm runner wget -qO- https://DEINE_DOMAIN/api/healthz).

Kein Runner hat ein passendes Label. Der Workflow nutzt runs-on: docker, der Runner muss also das Label docker tragen. Labels beim Registrieren prüfen; in der Runner-Übersicht werden die Labels je Runner angezeigt.

Forgejo lädt Actions aus einem konfigurierten Register (standardmäßig data.forgejo.org). Ist der Server komplett vom Internet abgeschnitten, schlägt das fehl. Ausgehenden HTTPS-Zugriff erlauben oder Actions in einem internen Register spiegeln.

Der PTR-Eintrag fehlt, ist noch nicht propagiert oder passt nicht zum A-Record. PTR im Provider-Panel auf mail.DEINE_DOMAIN setzen und mit dig -x prüfen; sicherstellen, dass mail.DEINE_DOMAIN vorwärts auf dieselbe IP zeigt.

Der DNS-Record ist falsch übernommen (wirklich abgeschnittener Schlüssel, falscher Selector) oder noch nicht propagiert. Den Wert exakt aus der Mailserver-UI kopieren, Selector im Record (SELECTOR._domainkey) mit dem im Server konfigurierten abgleichen, dann dig gegenprüfen. Dass dig den Schlüssel als zwei Blöcke in Anführungszeichen zeigt, ist dabei normal und kein Fehler – siehe Schritt 3.

Mehrere SPF-Records, oder zu viele include:-Verschachtelungen (Limit: 10 DNS-Lookups). Mit dig +short TXT DEINE_DOMAIN | grep spf1 prüfen, ob wirklich nur eine Zeile zurückkommt, auf einen SPF-Record konsolidieren und unnötige include: entfernen.

Kommt eine harte Abweisung mit 550 5.7.515 Access denied, sending domain … does not meet the required authentication level, ist es kein Reputationsproblem, sondern Microsofts Authentifizierungsregel ab 5.000 Mails pro Tag – SPF und DKIM müssen bestehen und ein ausgerichteter DMARC-Record (mindestens p=none) vorhanden sein; die Schwelle klebt an der Domain, auch wenn du später weniger sendest. Landen die Mails dagegen nur im Junk-Ordner, ist Microsoft schlicht streng mit neuen IPs: Geduld, wenig aber regelmäßig senden, ggf. Microsofts SNDS-/JMRP-Programm nutzen.

Die IP war vor dir bei einem Spammer, oder ein Postfach von dir versendet Spam. Auf den gängigen Blocklist-Checkern prüfen, bei berechtigtem Fund über das jeweilige Delisting-Formular entfernen lassen – und die Ursache (kompromittiertes Konto) abstellen.

Der Container ist noch am Hochfahren oder Port 8080 ist belegt/geblockt. docker compose ps prüfen, docker compose logs lesen und sicherstellen, dass die Firewall Port 8080 (und später 443) durchlässt. Bleibt die Log-Ausgabe nach dem Setup komplett leer, steht das Log-Ziel noch auf Log file – in der Konsole unter Settings → Telemetry → Tracers auf Console umstellen und neu starten.

Es wird nur einmal geloggt. Setze in der compose.yaml ein STALWART_RECOVERY_ADMIN=admin:DEIN_PASSWORT unter environment: und starte mit docker compose up -d neu – damit hast du ein festes Recovery-Admin-Konto.

Entweder erreicht Let’s Encrypt deinen Server nicht auf Port 443 (Stalwart nutzt die TLS-ALPN-01-Challenge über 443), oder einer der fünf Hostnamen aus Schritt 1 fehlt im DNS. Das Log nennt den Schuldigen beim Namen: ACME authentication error … NXDOMAIN looking up A for autoconfig.DEINE_DOMAIN. Fehlende Records nachtragen, Port 443 in der Firewall öffnen – Stalwart wiederholt die Zertifikatsanforderung danach automatisch.

Dein Provider sperrt ausgehenden SMTP-Verkehr. Bei netcup ist die Default-Policy „netcup Mail block" (Port 25/465/587) schuld: Im SCP unter Firewall → Policys dem Server dieses netcup-Template abnehmen – kein Ticket nötig, siehe netcup-Firewall einrichten. Ohne das ist keine Zustellung an fremde Server möglich.

Fehlender oder falscher PTR-Eintrag, kein SPF/DKIM/DMARC. Das ist kein Fehler von Stalwart, sondern Sache der DNS-/Reputations-Konfiguration – siehe das Tutorial zur E-Mail-Zustellbarkeit.

Das Paket jq fehlt. sudo apt install -y jq und den Generator erneut starten.

Auf Hosts mit aktivem IPv6 hast du die Frage nach der IPv6-fähigen Docker-Konfiguration mit n beantwortet – ohne sie läuft mailcow dort nicht, sonst droht ein offenes Relay. Lege /etc/docker/daemon.json mit {"ipv6": true} an (Docker 28 und neuer), starte Docker mit sudo systemctl restart docker neu und führe ./generate_config.sh erneut aus – oder bestätige die Frage beim zweiten Anlauf einfach mit Enter, dann erledigt der Generator beides selbst.

SOGo kennt deine Mail-Domain nicht: Es liest die Domainliste ausschließlich beim Start und wurde nach dem Anlegen der Domain nicht neu gestartet – in seinen Logs steht No authentication sources defined - nobody will be able to login. Starte SOGo über E-Mail → SOGo neustarten neu. Bleibt es dabei, hängt noch ein fehlgeschlagener Login im Cache: docker compose restart memcached-mailcow sogo-mailcow.

Let’s Encrypt erreicht deinen Server nicht auf Port 80, oder der A-Record von mail.DEINE_DOMAIN stimmt nicht. Prüfe mit docker compose logs acme-mailcow, ob der Hostname und die IP passen, und dass Port 80 durch UFW und die netcup-Firewall offen ist.

Dein Provider sperrt ausgehenden SMTP-Verkehr (üblich als Spam-Schutz). Bei netcup ist es die Default-Policy „netcup Mail block" (Port 25/465/587): Im SCP unter Firewall → Policys dem Server dieses netcup-Template abnehmen – kein Support-Ticket nötig, Details in netcup-Firewall einrichten. Ohne das kannst du keine Mails an fremde Server senden – Empfang und lokale Zustellung funktionieren trotzdem.

Auf dem Host läuft schon ein Webserver oder Reverse Proxy (z. B. Traefik). Für dieses Rezept gehört mailcow auf einen eigenen Server. Alternativ bindest du den nginx mit HTTP_BIND/HTTPS_BIND und HTTP_PORT/HTTPS_PORT auf einen lokalen Port um und stellst mailcow hinter den Proxy – das beschreibt mailcows Traefik-Anleitung. Die Mail-Ports liegen in beiden Fällen weiterhin direkt am Host.

Zu wenig RAM. Auf mindestens 6–8 GB gehen oder ClamAV in der mailcow.conf (SKIP_CLAMD=y) deaktivieren – der Virenscanner ist der größte Speicherfresser.

Die NTFY_BASE_URL passt nicht zur aufgerufenen Adresse. Sie muss exakt deine öffentliche HTTPS-URL sein (https://ntfy.DEINE_DOMAIN, ohne Slash am Ende). Nach einer Änderung docker compose up -d erneut ausführen.

Bei deny-all sind fehlende oder falsche Zugangsdaten der häufigste Fehler. Benutzer/Passwort prüfen (docker exec ntfy ntfy user list) und beim Senden -u BENUTZER:PASSWORT bzw. den Bearer-Token mitgeben. Ein 403 bedeutet, dass der Benutzer existiert, aber keine Rechte auf dieses Thema hat – dann mit ntfy access Rechte vergeben.

Browser-Push braucht erteilte Benachrichtigungsrechte und einen aktiven Service Worker; das ist unzuverlässig, sobald der Tab geschlossen ist. Für echtes „unterwegs"-Push die ntfy-App verwenden – sie hält die Verbindung im Hintergrund.

Der Container ist noch nicht bereit oder hört auf dem falschen Port. Prüfe docker compose logs ntfy und dass das Label loadbalancer.server.port=80 gesetzt ist – ntfy lauscht im Container auf Port 80 (NTFY_LISTEN_HTTP=":80").

ntfy begrenzt standardmäßig die Rate pro Absender, um Missbrauch zu verhindern. Bei einem privaten Server mit eigenen Skripten stößt du selten daran – ein Schleifen-Skript ohne Pause aber schon. Nachrichten bündeln statt im Sekundentakt zu feuern, oder die Limits gezielt über die NTFY_VISITOR_*-Umgebungsvariablen anheben (in der ntfy-Doku unter „Rate limiting" beschrieben). NTFY_BEHIND_PROXY: "true" ist Voraussetzung, damit das Limit pro echter IP statt pro Traefik-Container greift.

Du hast einen relativen Pfad benutzt, der woanders zeigt als gedacht, oder Docker hat den Pfad neu als leeren Ordner angelegt. Bei docker run Bind-Mounts immer mit absolutem Pfad angeben (/opt/app/config, nicht config). Existiert dieser Host-Pfad noch nicht, legt Docker ihn stillschweigend als leeren Ordner an – prüfe also mit ls, dass du wirklich den richtigen erwischt hast. In der compose.yaml sind ./-Pfade dagegen völlig in Ordnung – sie sind relativ zur compose.yaml und damit eindeutig. Achtung außerdem: docker run -v config:/data (ohne / oder ./ davor) ist kein Bind-Mount, sondern legt ein Named Volume namens config an.

Der Prozess im Container läuft unter einer anderen UID als der Besitzer des Host-Ordners – typisch bei Bind-Mounts. Bei Named Volumes tritt das selten auf (Docker setzt die Rechte). Bei Bind-Mounts den Ordner dem passenden Benutzer geben (chown -R 1000:1000 /opt/app/data) oder im Image die user:-Angabe der Compose nutzen.

Du hast docker compose down -v benutzt – das -v löscht die Named Volumes mit. Für einen normalen Neustart ohne -v arbeiten. -v bewusst nur einsetzen, wenn du wirklich bei null anfangen willst.

docker volume prune bzw. docker system prune --volumes entfernt Volumes, an denen gerade kein Container hängt. Bei docker volume prune sind benannte Volumes standardmäßig geschützt – gelöscht werden nur anonyme Volumes; benannte fallen erst mit --all/-a weg. (Bei docker system prune steuert -a/--all dagegen die Images, nicht die benannten Volumes.) Ein weiteres starkes Argument fürs Benennen – ein sk-demo-vol übersteht ein versehentliches docker volume prune, ein anonymes Volume nicht. Trotzdem prune mit Volumes nur laufen lassen, wenn alle wichtigen Stacks aktiv sind, oder gezielt mit docker volume rm entfernen.

Traefik hat das Let’s-Encrypt-Zertifikat noch nicht geholt, oder der DNS-Record zeigt nicht auf den Server. Prüfe mit dig statistik.DEINE_DOMAIN, dass die IP stimmt, und sieh in die Traefik-Logs. Den genauen Container-Namen aus deinem Traefik-Setup findest du mit docker ps | grep traefik, dann docker logs <container-name> (bei uns z. B. docker logs traefik-traefik-1). Die HTTP-Challenge scheitert, wenn Port 80 nicht von außen erreichbar ist – kontrolliere deine Firewall und die netcup-Firewall.

MariaDB war beim ersten Start noch nicht bereit. Gib der DB einen Moment und lade die Seite neu. Prüfe mit docker compose logs db, ob dort ready for connections steht. Erscheint stattdessen ein Zugangsfehler, passen DB_PASSWORD in der .env und die bereits angelegte DB nicht mehr zusammen – dann hilft ein sauberer Neustart mit docker compose down -v (Achtung: löscht die Daten) und docker compose up -d.

Matomo prüft aus Sicherheitsgründen, unter welchem Hostnamen es aufgerufen wird. Die Warnung erscheint, wenn du die Domain wechselst. Bestätige den korrekten Hostnamen über den Button in der Meldung – Matomo trägt ihn dann in config/config.ini.php ein.

Der Tracking-Code fehlt, ist falsch eingebaut, oder du besuchst deine Seite selbst (Matomo ignoriert dich, wenn deine IP ausgeschlossen ist). Öffne deine Website in einem privaten Fenster und prüfe im Netzwerk-Tab, ob ein Request an matomo.php rausgeht. In Matomo hilft Verwaltung → Diagnose → Tracking Fehlschläge.

Die On-the-fly-Archivierung rechnet bei jedem Aufruf. Richte den Archivierungs-Cron aus Schritt 8 ein und stelle die Berichterstellung auf Cron um.

Der eingebaute SSH-Server kollidiert mit sich selbst, weil SSH_PORT und SSH_LISTEN_PORT nicht zusammenpassen. Setze beide auf denselben Wert (hier 2222) – dann startet Forgejo sauber.

Docker führt den ersten Healthcheck standardmäßig erst nach dem interval (30 s) aus – der Container sieht also 30 s+ „ungesund" aus, obwohl Forgejo längst in ~2 s bereit ist. Die Lösung steckt schon oben in der Compose: start_interval: 2s prüft während der Startphase im 2-Sekunden-Takt und schaltet sofort auf healthy, sobald die App antwortet. (Braucht Docker 25+ / Compose v2.20+ – auf Debian 13 gegeben.)

Fast immer der falsche Port: Forgejos Weboberfläche lauscht intern auf 3000, deshalb muss loadbalancer.server.port=3000 gesetzt sein und der Container im proxy-Netz hängen.

Dann stimmen ROOT_URL, SSH_DOMAIN oder SSH_PORT nicht. Korrigiere die Werte in der Compose und starte mit docker compose up -d neu.

Der SSH-Server läuft, aber dein öffentlicher Schlüssel ist noch nicht im Konto hinterlegt (Schritt 6) – oder du hast den Port 2222 vergessen.

Prüfe im Browser (Entwicklertools → Netzwerk), ob hk.js überhaupt geladen wird und der Sende-Request danach mit Status 2xx zurückkommt. Häufigste Ursachen: Das Snippet steckt nicht im HTML, die in HitKeep angelegte Site-Domain passt nicht zum Hostnamen der besuchten Seite, oder ein Ad-/Tracking-Blocker filtert den Aufruf. Da du unter deiner eigenen Domain hostest (First-Party), greifen die meisten Blocker nicht – manche Listen kennen aber den Pfad hk.js.

Dann greift HITKEEP_TRUSTED_PROXIES nicht: Der angegebene Bereich enthält die IP deines Proxys nicht, und HitKeep wertet nur noch Traefiks Container-IP aus. Prüfe mit docker network inspect proxy, in welchem Subnetz der Proxy liegt – 172.16.0.0/12 deckt die üblichen Docker-Netze ab – und starte den Stack neu (docker compose up -d). Danach zählt wieder die echte Client-IP aus dem X-Forwarded-For-Header.

Ein 404 heißt meist, dass die Router-Regel nicht greift – prüfe, dass Host(...) deine echte Domain enthält und der Container im proxy-Netz hängt. Ein 502 deutet auf den falschen Port: HitKeep lauscht intern auf 8080, deshalb muss loadbalancer.server.port=8080 gesetzt sein.

Das ist fast immer eine Diskrepanz bei HITKEEP_PUBLIC_URL: Der Wert muss exakt der Adresse entsprechen, über die du HitKeep aufrufst (inklusive https://, ohne abschließenden Slash). Korrigiere die Variable und starte den Container neu.

Sieh in die Logs: docker compose logs -f hitkeep. Ein fehlendes oder leeres HITKEEP_JWT_SECRET ist eine typische Startbremse – erzeuge eines wie in Schritt 1 und trage es ein.

Der UDP-Port ist nicht erreichbar oder die Schlüssel passen nicht. WireGuard ist bei falschen Schlüsseln stumm – es gibt keine Fehlermeldung, nur keinen Handshake. Prüfe: sudo ufw status (Port 51820/udp offen?), die netcup-Firewall (eingehend UDP 51820), den Endpoint im Client (richtige öffentliche IP?) und dass privater und öffentlicher Schlüssel nicht vertauscht sind.

Fast immer das Routing/NAT. Ist net.ipv4.ip_forward=1 gesetzt (sysctl net.ipv4.ip_forward)? Läuft Docker mit – oder ist UFW aktiv –, greift die FORWARD-DROP-Falle aus dem Warnkasten oben; beide setzen die Forward-Policy auf DROP. Die Regeln müssen mit -I FORWARD 1 vor den bestehenden Ketten stehen. Stimmt das externe Interface im MASQUERADE (eth0 vs. etwas anderes)?

Ohne DNS =-Zeile fragt dein Gerät weiter die DNS-Server deines lokalen Netzes – im offenen WLAN sieht der Betreiber also weiter, welche Domains du aufrufst. Prüfe unter Linux mit resolvectl status, welcher DNS-Server dem Interface wg0 zugeordnet ist, oder mach einen Leak-Test (z. B. auf dnsleaktest.com): Tauchen dort fremde Resolver auf, trägst du in der Client-Konfig einen echten Resolver ein (DNS = 1.1.1.1) – oder den Server selbst (10.8.0.1), falls dort ein eigener DNS-Resolver läuft.

Ein MTU-Problem. wg-quick setzt die MTU auf 1420; in manchen Netzen (DS-Lite, bestimmte Mobilfunknetze) ist das noch zu hoch. Setz testweise MTU = 1412 oder 1280 in der [Interface]-Sektion des Clients.

Die DNS =-Zeile braucht resolvconf. Entweder sudo apt install openresolv installieren oder die DNS-Zeile entfernen, wenn du den VPN-DNS nicht brauchst.

Der Client sitzt hinter NAT/CGNAT. PersistentKeepalive = 25 in der Client-Konfig hält die Verbindung offen.

Ein VPS teilt sich die physische CPU. Prüfe die Steal Time (vmstat 1, Spalte st) und top (Zeile %st). Ist sie dauerhaft hoch, rechnen gerade Nachbarn auf demselben Host. Miss zu einer anderen Tageszeit erneut – oft ist der Unterschied dann weg.

Dir fehlt --direct=1 – dann misst fio den RAM-Cache, nicht die NVMe. Immer mit direktem I/O testen, sonst sind die Zahlen wertlos.

Nein. Das ist ein Virtualisierungs-Artefakt: Der virtio-Treiber meldet die virtuelle Disk pauschal als rotierend. Die gemessenen 100k+ IOPS und 4 GB/s beweisen, dass echter Flash-Speicher dahintersteht.

Miss gegen einen nahen, schnellen Server (z. B. Falkenstein). Ein weit entferntes Ziel oder eine langsame Gegenstelle begrenzt die Messung, nicht dein VPS. Ein einzelner curl-Stream schöpft zudem nicht immer die volle Bandbreite aus.

Normal – Benchmarks schwanken. Miss mehrfach, verwirf den ersten („warmen") Lauf und nimm den Median. Vergleiche außerdem nur gleiche Tool-Versionen und Parameter miteinander.

Dein Tag zeigt auf eine feste Version (:1.37.2) oder auf einen Major-Tag (:18), unter dem es nur ein neues Major gäbe. pull holt nur, was derselbe Tag inzwischen zeigt. Für einen Versionssprung musst du den Tag in der compose.yaml selbst anheben.

Meist ein Breaking Change oder eine fehlgeschlagene Migration. Prüfe docker compose logs, gleiche mit den Release-Notes ab. Tag auf die alte Version zurücksetzen und up -d; hat die neue Version die Daten schon migriert, das Backup aus Schritt 3 einspielen.

Prüfe, dass die Container das Label diun.enable=true tragen und Diun den Socket lesen kann (DIUN_PROVIDERS_DOCKER=true, Socket gemountet). Für neuere Versions-Tags braucht der Container zusätzlich diun.watch_repo=true – ohne das sieht Diun nur Änderungen am exakt gepinnten Tag. Und: Was Diun beim ersten Mal sieht, wird nur in die Datenbank geschrieben, nicht gemeldet (watch.firstCheckNotif ist false) – zum Testen des Meldewegs einmalig DIUN_WATCH_FIRSTCHECKNOTIF=true setzen.

docker image prune räumt nur dangling Images ab, nicht die alten getaggten Versionen. Entferne sie gezielt mit docker rmi <image>:<tag> oder – mit Bedacht – docker image prune -a. Auch der Build-Cache (docker builder prune) kann wachsen.

diun.watch_repo=true auf vielen Images fragt viele Tags ab. Setz das Watch-Intervall seltener (z. B. einmal täglich) und grenze mit diun.include_tags auf relevante Versionen ein, statt das ganze Repo abzuklopfen.

Der Bouncer cached die Entscheidungen und zieht neue im stream-Modus erst nach dem Pull-Intervall (bis zu ~60 Sekunden). Kurz warten. Wer die Reaktionszeit drücken will, senkt updateIntervalSeconds in der Middleware (Schritt 3).

CrowdSec liest die Logs nicht – und weil cscli leere Tabellen weglässt, fehlt die Zeile komplett statt Lines read: 0 zu zeigen. Häufigste Ursache: der Container startete, bevor die access.log existierte; dann steht in docker logs crowdsec die Zeile No matching files for pattern /var/log/traefik/access.log, und CrowdSec nimmt die Datei auch später nicht von allein auf – cd ~/crowdsec && docker compose restart behebt das. Prüfe sonst, dass Traefik wirklich nach /var/log/traefik/access.log schreibt (Schritt 1), dass beide Container denselben Host-Pfad einbinden und dass die acquis.yaml genau diesen Pfad nennt.

Der Bouncer konnte die LAPI beim Start nicht erreichen und blockt dann im Zweifel, statt ungeschützt durchzulassen. Im Traefik-Log steht dazu crowdsecQuery:unreachable mit der URL http://crowdsec:8080/v1/decisions/stream. Prüfe mit docker ps, dass der crowdsec-Container Up ist – sobald der nächste Pull klappt (bis zu ~60 Sekunden), gehen die Anfragen von allein wieder durch. Das ist sicher, macht CrowdSec aber zu einer kritischen Komponente: Läuft der Container nicht, ist deine Seite betroffen. restart: unless-stopped (oben gesetzt) holt ihn nach einem Server-Neustart automatisch zurück.

Sitzt ein CDN wie Cloudflare vor Traefik, sieht Traefik nur dessen IP. Dann die echte Client-IP aus dem X-Forwarded-For-Header lesen lassen: In der Middleware forwardedHeadersTrustedIPs mit den CDN-Netzen füllen – sonst sperrst du am Ende das CDN. Direkt an netcup (ohne CDN) ist hier nichts zu tun.

Traefik lädt das Plugin beim Start aus dem Netz. Prüfe, dass der Server raus darf (die netcup-Firewall sperrt ausgehend nur SMTP, UFW ebenso wenig) und dass modulename und version exakt stimmen.

Dann sieht Traefik die echte Absenderadresse gar nicht. Das passiert bei IPv6-Besuchern, wenn das proxy-Netz ohne IPv6 angelegt wurde: Docker schiebt die Verbindung dann über einen Hilfsprozess und ersetzt die Quelladresse durch die des Bridge-Gateways. In der access.log steht dann bei allen IPv6-Zugriffen dieselbe 172.x.x.x, und eine Sperre darauf trifft entweder niemanden oder alle. Leg das Netz mit --ipv6 neu an; die Anleitung dafür steht im Reverse Proxy mit Traefik.

dd fragt nicht nach und heißt nicht umsonst spöttisch „disk destroyer". Prüfe das Ziel (of=) immer vorher mit lsblk, und verwechsle nie sda mit sdb. Es gibt kein Rückgängig – im Zweifel lieber dreimal lesen.

-9 gibt dem Prozess keine Chance, sauber zu schließen. Nutze immer zuerst kill ohne -9 und gib dem Prozess ein paar Sekunden. Erst wenn er wirklich hängt, folgt die harte Variante.

Der abschließende Schrägstrich entscheidet: rsync -a /quelle/ kopiert den Inhalt von quelle, rsync -a /quelle kopiert den Ordner mit hinein. Und --delete löscht im Ziel alles, was in der Quelle fehlt. Erst mit -n testen, immer.

Das Paket ist nicht installiert. Installiere es (siehe Tipp-Box oben) oder prüfe den Namen. Manche Tools wie iotop brauchen zudem sudo, um überhaupt Daten zu sehen.

Du hast eine neue Sitzung gestartet statt dich anzuhängen. tmux ls listet laufende Sitzungen, tmux attach -t 0 hängt dich an die erste. Nur tmux allein erzeugt jedes Mal eine frische.

Traefik erreicht den Container, trifft aber den falschen Port. Jellyfin lauscht auf 8096 – prüfe das Label traefik.http.services.jellyfin.loadbalancer.server.port=8096 auf Tippfehler. Kommt stattdessen nach ein paar Sekunden ein 504 Gateway Timeout, ist der Port nicht das Problem, sondern das Netzwerk: Dann fehlt networks: [proxy], und Traefik läuft gegen eine Adresse, die es gar nicht erreichen kann.

Fast immer ein Rechte-Problem. Der Container läuft als 1000:1000 (Schritt 4), die Medien müssen also diesem Benutzer gehören: sudo chown -R 1000:1000 /mnt/media. Und: In Jellyfin muss der Container-Pfad stehen (/media/filme), nicht der Host-Pfad. Danach unter Dashboard → Geplante Aufgaben „Alle Bibliotheken scannen" starten.

Es wird transcodiert. Unter Dashboard → Wiedergabe siehst du im Aktivitätsmonitor, ob „Transcode" statt „Direct Play" steht. Stell die Client-Qualität auf Original, stell exotische Codecs auf ein breit unterstütztes Format um, oder gib dem Server mehr (dedizierte) Kerne.

Der Block Storage wurde nicht eingehängt – meist ein fehlender oder falscher fstab-Eintrag (Schritt 2). Prüfe mit df -h /mnt/media und sudo mount -a. Die Zeile muss die UUID verwenden, nicht /dev/vdb1.

JELLYFIN_PublishedServerUrl fehlt oder ist falsch. Setz sie in der compose.yaml auf https://jellyfin.DEINE_DOMAIN und starte mit docker compose up -d neu (ein restart reicht nicht, damit die Environment-Änderung greift).

Prometheus erreicht den Exporter nicht. Bei cadvisor prüfe, dass er im selben monitoring-Netz läuft und Name und Port exakt stimmen (cadvisor:8080). Beim node-Job prüfe den extra_hosts-Eintrag am Prometheus-Service und das Target host.docker.internal:9100 – ohne beides findet Prometheus den node-exporter im Host-Netz nicht. Nach Änderungen an der prometheus.yml den Prometheus-Container neu starten: docker compose restart prometheus.

Fehlen die Mounts oder privileged: true, sieht cAdvisor die Container nicht. Kontrolliere den cadvisor-Block (Mounts, devices: /dev/kmsg). Einzelne „No data"-Panels sind normal – manche Metriken (etwa CPU-Drosselung) gibt es nur, wenn du den Containern CPU-Limits gesetzt hast.

Fast immer stimmt GF_SERVER_ROOT_URL nicht. Sie muss exakt die öffentliche Adresse sein (https://grafana.DEINE_DOMAIN). Prüfe außerdem, dass die Traefik-Label loadbalancer.server.port=3000 gesetzt ist – Grafana lauscht intern auf 3000.

Meist der Zeitbereich. Ein frischer Stack hat noch keine Historie – stell oben rechts „Last 15 minutes" ein und warte ein paar Minuten, bis Daten aufgelaufen sind. Prüfe zudem, dass beim Dashboard-Import die Prometheus-Datenquelle gewählt war.

Das ist die Prometheus-TSDB. Reduziere --storage.tsdb.retention.time (z. B. auf 15d) oder überwache weniger Ziele. Das prom_data-Volume wächst mit Anzahl der Metriken × Vorhaltezeit.

Traefiks readTimeout (Standard 60 s) greift. Setz ihn wie in Schritt 4 auf 600s (oder höher) und starte Traefik neu. Das ist mit Abstand der häufigste Immich-hinter-Proxy-Fehler.

Zu wenig RAM – der Container wurde vom System beendet (Out of Memory). Gib dem Server mehr Speicher, oder deaktiviere ML, indem du den Service immich-machine-learning aus der compose.yaml entfernst. Immich läuft dann ohne Gesichtserkennung und intelligente Suche, aber Upload und Zeitleiste funktionieren normal.

Server, Machine-Learning und Datenbank müssen auf derselben Version laufen. Setz in der .env die neue IMMICH_VERSION und aktualisiere alle Container gemeinsam (docker compose pull && docker compose up -d). Ein Downgrade nach einer Migration ist nicht möglich – nur ein Rücksetzen aus dem Backup.

Immich v3 startet bei bestimmten Datenbank-Zuständen in einen Wartungsmodus. Im Log (docker compose logs immich-server) steht dann eine URL mit einem einmaligen Token (…/maintenance?token=…) – darüber meldest du dich am Wartungsmodus an und wählst „neu starten" bzw. beendest ihn. Danach ist die normale Oberfläche wieder da.

UPLOAD_LOCATION oder DB_DATA_LOCATION haben die falschen Zugriffsrechte oder liegen auf einem Netzlaufwerk. Lege beide auf einer lokalen Platte an und stelle sicher, dass Docker hineinschreiben darf.

PAPERLESS_URL ist nicht oder falsch gesetzt. Sie muss exakt deiner HTTPS-Adresse entsprechen (https://paperless.DEINE_DOMAIN, ohne Schrägstrich am Ende). Nach der Korrektur docker compose up -d.

Häufigste Ursache: Die Ordner wurden nicht vorab angelegt (Schritt 3), sondern beim ersten Start vom Docker-Daemon erzeugt – dann gehören sie root. Mit sudo chown -R $(id -u):$(id -g) ~/paperless/consume ~/paperless/export gehören sie wieder dir. Ansonsten: USERMAP_UID/USERMAP_GID passen nicht zum Besitzer des Ordners – ermittle deine Kennung mit id -u und id -g, trag die Werte ein und starte neu.

Die Hintergrundverarbeitung läuft über Redis. Prüfe, dass der broker-Container läuft, und sieh unter Dateiaufgaben nach der Fehlermeldung der fehlgeschlagenen Aufgabe.

Falsche OCR-Sprache. Setz PAPERLESS_OCR_LANGUAGE=deu (oder deu+eng für gemischte Dokumente). Nur installierte Sprachen funktionieren.

Dafür sind Gotenberg und Tika zuständig. Prüfe, dass beide Container laufen und PAPERLESS_TIKA_ENABLED=1 samt der beiden Endpoint-Variablen gesetzt ist.

OCR ist rechenintensiv, und Paperless nutzt standardmäßig alle Kerne. Auf kleinen Servern kannst du die Last drosseln, indem du die Zahl der Worker bzw. Threads begrenzt (PAPERLESS_TASK_WORKERS, PAPERLESS_THREADS_PER_WORKER). Dann dauert der Import länger, aber die Oberfläche bleibt bedienbar.

Meist ist die Middleware nicht am Router. Prüfe, dass die Zeile traefik.http.routers.nc.middlewares beide Middlewares nennt (nc-dav,nc-secure) und dass die zwei nc-secure-Header-Labels im nc-app-Block stehen. Danach docker compose up -d nc-app. Traefik übernimmt geänderte Labels erst beim Neu-Erstellen des Containers.

Fast immer Port/Verschlüsselung oder Authentifizierung. Kombiniere SSL/TLS mit Port 465 oder STARTTLS mit Port 587 – nicht kreuzweise. Nutzt dein Anbieter 2FA, brauchst du ein App-Passwort (siehe Schritt 4). Details stehen im Nextcloud-Log: docker exec -u www-data nc-app php occ log:tail 20.

Du hattest noch keinen zweiten Faktor eingerichtet. Hebe die Pflicht per Kommandozeile auf, richte deinen Faktor in Ruhe ein und schalte sie danach wieder scharf: docker exec -u www-data nc-app php occ twofactorauth:enforce --off.

TRUSTED_PROXIES passt nicht zum tatsächlichen proxy-Subnetz. Ermittle es mit docker network inspect proxy -f '{{(index .IPAM.Config 0).Subnet}}' und trag den Wert in der nc-app-Umgebung ein (Teil 1, Schritt 2). Sonst sperrt der Brute-Force-Schutz im Ernstfall den Proxy und damit alle Nutzer.

Der App-Container ist vor Redis gestartet. Stelle sicher, dass nc-redis in depends_on steht (Teil 1) und mit restart: unless-stopped läuft – dann fängt Docker den Startreihenfolge-Fall selbst ab.

Deine Domain steht nicht in trusted_domains. Prüfe NEXTCLOUD_TRUSTED_DOMAINS in der Compose-Datei. Nachträglich setzen geht per occ: docker exec -u www-data nc-app php occ config:system:set trusted_domains 1 --value=cloud.DEINE_DOMAIN.

Der CalDAV/CardDAV-Redirect greift nicht. Kontrolliere die nc-dav-Middleware-Labels (Schritt 3) und dass der Router sie über ...routers.nc.middlewares=nc-dav einbindet. Das Regex muss die volle https://…-URL matchen – redirectregex prüft die komplette URL, nicht nur den Pfad.

Der HSTS-Header fehlt. Setz ihn als Traefik-Middleware und häng sie an den Router: traefik.http.middlewares.nc-secure.headers.stsSeconds=15552000. Häng sie zusätzlich zur nc-dav-Middleware an den Router (...routers.nc.middlewares=nc-dav,nc-secure). Der Header muss vom Proxy kommen, nicht von Nextcloud. In Teil 2 richten wir genau diese nc-secure-Middleware vollständig ein (inklusive includeSubdomains).

Das PHP-Limit ist zu klein. Erhöhe PHP_UPLOAD_LIMIT und PHP_MEMORY_LIMIT (Schritt 3) und starte den Container neu. In seltenen Fällen greifen diese Variablen nicht – dann ein eigenes php.ini-Snippet ins Image mounten.

Der App-Container war schneller als die Datenbank. Genau dagegen ist der healthcheck mit depends_on: condition: service_healthy da – prüfe, dass beide in deiner Compose-Datei vorhanden sind, und starte mit docker compose up -d neu.

Fast immer fehlt das Port-Label traefik.http.services.kuma.loadbalancer.server.port=3001 oder es steht ein falscher Port drin. Traefik erreicht den Container dann zwar, klopft aber am falschen Port an. Label prüfen und docker compose up -d erneut ausführen.

Wie bei jeder App hinter Traefik: traefik.enable=true gesetzt? Container im proxy-Netzwerk? Stimmt die Domain in der Host(...)-Regel und zeigt der DNS-Record status.DEINE_DOMAIN auf den Server? Das Traefik-Dashboard zeigt unter „HTTP Routers", ob kuma registriert ist.

Kuma nutzt WebSockets. Traefik leitet die standardmäßig korrekt weiter – tritt das Problem trotzdem auf, liegt es meist an einem davorgeschalteten CDN/Proxy (z. B. Cloudflare im „Proxy"-Modus), der WebSockets blockt. Für den Direktbetrieb hinter Traefik ist keine Zusatzkonfiguration nötig.

Das kuma-data-Volume wurde gelöscht (z. B. durch docker compose down -v). Alle Konfiguration und Historie liegt allein in diesem Volume – deshalb steht es im nächsten Abschnitt ganz oben.

Es fehlt das volumes:-Mapping. Vaultwarden bricht dann mit dem Kasten „It looks like you did not configure a persistent volume!" ab und beendet sich mit Exit-Code 1, damit deine Passwörter nicht in einem flüchtigen Container landen. Ergänze ./vw-data:/data wie in Schritt 2 und starte neu.

Vaultwarden nutzt die Web-Crypto-API des Browsers, die nur in einem sicheren Kontext (echtes HTTPS) verfügbar ist. Du hast die Seite über http:// oder mit ungültigem Zertifikat aufgerufen. Stell sicher, dass Traefik ein gültiges Let’s-Encrypt-Zertifikat geholt hat (Traefik-Log prüfen) und du die Seite über https:// erreichst. Die DOMAIN-Variable muss ebenfalls mit https:// beginnen.

Vermutlich sind die Dollarzeichen im ADMIN_TOKEN nicht verdoppelt. In der compose.yaml muss aus jedem $ ein $$ werden. Prüfe mit docker compose exec vaultwarden printenv ADMIN_TOKEN, wie der Token wirklich im Container ankommt – dort muss wieder ein einfaches $ stehen. (docker compose config hilft hier nicht: Es zeigt die Datei mit den doppelten $$.) Denk auch daran: Beim Login gibst du das Passwort ein, nicht den Hash.

Die Server-URL muss die vollständige https://-Adresse ohne abschließenden Pfad sein (https://vault.DEINE_DOMAIN). Prüfe außerdem, ob die Domain von außen per Browser erreichbar ist und das Zertifikat gültig ist – Apps sind bei Zertifikatsfehlern strenger als Browser.

Wahrscheinlich wurde die Einstellung im Admin-Panel gesetzt und überschreibt die Umgebungsvariable, oder der Container wurde nach der Änderung nicht neu gestartet. Kontrolliere den Wert unter Settings → General settings im Panel und starte mit docker compose up -d neu.

ignoreip fehlte oder enthielt die falsche IP. Verbinde dich über die Konsole im netcup SCP (unabhängig von SSH) und entsperre dich mit sudo fail2ban-client set sshd unbanip DEINE_EIGENE_IP. Trage deine IP anschließend in ignoreip ein und lade neu. Deshalb steht die Whitelist in Schritt 2 an erster Stelle.

Fast immer ein Tippfehler in jail.local. Prüfe die Syntax mit sudo fail2ban-client -t (Testmodus) – der Befehl nennt die fehlerhafte Zeile.

Es wird nur 10 Minuten gesperrt, oder die eigene IP fliegt trotz ignoreip raus. Fast immer fehlt der Reload – der Dienst lief schon, bevor du die erste eigene Zeile geschrieben hast, und start/enable --now tut bei einem laufenden Dienst nichts. Was wirklich gilt, zeigen sudo fail2ban-client get sshd bantime (600 = Debian-Standard, 3600 = deine Stunde) und sudo fail2ban-client get sshd ignoreip; übernommen wird es mit sudo systemctl reload fail2ban.

Prüfe mit sudo fail2ban-client status sshd, ob Total failed überhaupt steigt. Bleibt es bei 0, findet der Filter die Einträge nicht – meist, weil eine veraltete Anleitung einen logpath auf eine nicht existierende Datei gesetzt hat. Auf Debian 13 den logpath aus jail.local entfernen und das Journal nutzen (Schritt 2).

Auf Debian 13 sperrt Fail2ban per nftables (banaction = nftables aus defaults-debian.conf). Sichtbar wird das mit sudo nft list table inet f2b-table: Dort steht die Kette f2b-chain und darin ein Adress-Set addr-set-sshd mit den gesperrten IPs. sudo iptables -L -n | grep f2b liefert dagegen nichts – das ist kein Fehler, sondern die falsche Werkzeugebene, an der ältere Anleitungen hängen bleiben. Fehlt die Tabelle ganz, hakt das Zusammenspiel mit der Firewall – Dienst neu starten und /var/log/fail2ban.log ansehen.

Restic kann den SSH-Hostkey des Backup-Servers nicht bestätigen, weil er noch nicht bekannt ist. Verbinde dich einmal manuell (ssh BACKUP_BENUTZER@DEIN_BACKUP_HOST) und bestätige den Fingerprint – oder hinterlege ihn mit ssh-keyscan DEIN_BACKUP_HOST >> ~/.ssh/known_hosts. Danach läuft Restic durch.

RESTIC_REPOSITORY oder RESTIC_PASSWORD_FILE ist nicht gesetzt oder zeigt ins Leere – im systemd-Dienst also die EnvironmentFile prüfen. Ein per Hand gesetztes export gilt nur in der aktuellen Shell.

Ein abgebrochener Lauf hat eine Sperre hinterlassen. Prüfe, dass wirklich kein Backup mehr läuft, dann restic unlock. Niemals blind entsperren, während parallel ein Lauf aktiv ist.

Grenze mit --exclude/--exclude-file ein (Caches, Logs, temporäre Dateien) und nutze --one-file-system, damit Restic nicht in gemountete Fremd-Dateisysteme abtaucht.

Kein Grund zur Panik – prune ist wiederaufnehmbar und das Repository bleibt gültig. Starte es erneut und lass anschließend einmal restic check laufen. Trenne --prune bei großen Repos vom täglichen Backup (siehe Schritt 6).

Sieh dir den letzten Lauf mit journalctl -u restic-backup.service an. Meist bricht das Skript vor dem curl-Aufruf ab (z. B. der DB-Dump schlug fehl) – dank set -euo pipefail stoppt es dann sauber, statt ein kaputtes Backup als Erfolg zu melden. Der ausbleibende Push ist also kein Bug, sondern genau das Alarmsignal, das du haben willst.

Die drei üblichen Gründe: (1) Der DNS-Record zeigt noch nicht auf den Server – dig +short DEINE_DOMAIN prüfen. (2) Port 80 ist von außen nicht erreichbar (Firewall/netcup-Firewall) – die HTTP-Challenge braucht ihn. (3) Du hast das Rate-Limit der Produktiv-CA gerissen – auf den Staging-Server wechseln (Tipp in Schritt 3), testen, dann zurück.

Traefik kennt die Route nicht. Prüfe: Hat der Container traefik.enable=true? Hängt er im proxy-Netzwerk? Stimmt die Domain in der Host(...)-Regel exakt (inkl. Subdomain)? Das Dashboard (Schritt 7) zeigt unter „HTTP Routers", ob der Router registriert wurde.

Traefik läuft, hat aber den ACME-Resolver übersprungen – daher kein echtes Zertifikat. chmod 600 acme.json nachholen (Schritt 2) und Container neu starten.

Deine Traefik-Version ist zu alt für deine Docker-Engine – der Docker-Provider kann den Socket nicht mehr abfragen. Aktuelles Docker (Engine 29, API-Level ≥ 1.40) braucht Traefik ≥ v3.6; deshalb nutzt dieses Tutorial traefik:v3.7. Gegen Docker 29 nachgestellt: v3.5.6 läuft in genau diesen Fehler, v3.6.25 spricht wieder sauber mit dem Socket. Ältere Tags wie v3.3 oder v3.5 funktionieren mit neuem Docker also nicht mehr – Image-Tag hochziehen und docker compose up -d erneut ausführen.

In der compose.yaml müssen die $-Zeichen des Hashes verdoppelt sein ($$). Prüfe den Hash außerhalb noch einmal mit htpasswd -nbB.

Meist hängt die App im falschen Netzwerk oder Traefik weiß nicht, welches gemeint ist. providers.docker.network=proxy in Traefik und networks: [proxy] an der App müssen zusammenpassen.

Traefik erreicht den Container, trifft aber den falschen Port. Lauscht die App nicht auf 80, braucht sie das Label traefik.http.services.<name>.loadbalancer.server.port=<echter-port>. Genau dieser Fall begegnet dir bei der ersten App im nächsten Tutorial (Uptime Kuma auf 3001).

Meist völlig normal – aktuell steht kein Sicherheitsupdate an. Prüfe die Konfiguration trotzdem über die Allowed origins are:-Zeile im --debug-Lauf. Erscheinen dort keine Security-Origins, stimmt das Origins-Pattern aus Schritt 3 nicht.

Meist steht Automatic-Reboot auf "false" (Standard) – dann auf "true" setzen und eine Automatic-Reboot-Time vergeben (Schritt 3). Steht die Option richtig, prüfe die Markierungsdatei: Ohne /var/run/reboot-required löst der Neustart nie aus. Dafür zuständig ist der Kernel-Hook des Pakets – dpkg -S /etc/kernel/postinst.d/unattended-upgrades muss ihn melden (Schritt 3).

Alte Kernel häufen sich an. Remove-Unused-Kernel-Packages "true" setzen (Schritt 3); einmalig aufräumen mit sudo apt autoremove --purge.

unattended-upgrades installiert keine Updates, die andere Pakete entfernen würden. Solche Fälle löst du bewusst von Hand mit sudo apt upgrade und prüfst, was passiert.

YAML ist einrückungssensibel – ausschließlich Leerzeichen, niemals Tabs, und pro Ebene konsistent (üblich: 2 Leerzeichen). Prüfe die Datei ohne sie zu starten: docker compose config löst alles auf und meckert genau die falsche Zeile an.

Der Host-Port (links in 8080:80) ist schon belegt. Finde den Beleger mit sudo ss -tlnp | grep 8080 oder wähle einen anderen Host-Port. Zwei Container dürfen sich denselben Host-Port nicht teilen.

Als Hostname muss der Service-Name stehen (z. B. db), nicht localhost. Innerhalb eines Containers ist localhost der Container selbst, nicht der Nachbar-Service. Und: Beide Services müssen im selben Compose-Projekt (derselben Datei) liegen.

Entweder lag das Volume nicht als Named Volume unter volumes: vor (dann war es nur der vergängliche Container-Speicher), oder es wurde down -v verwendet. Persistente Dienste immer mit deklariertem Named Volume fahren.

Das ist das alte Compose v1 (mit Bindestrich). Aktuell ist docker compose (mit Leerzeichen, Plugin). Falls es fehlt: sudo apt install docker-compose-plugin (siehe Docker-Tutorial).

Meist noch Propagation. Frage gezielt einen öffentlichen Resolver, der deinen lokalen Cache umgeht: dig +short DEINE_DOMAIN @1.1.1.1. Zeigt der schon den richtigen Wert, ist nur dein lokaler/Provider-Cache noch nicht abgelaufen – abwarten.

Oft existiert noch ein alter A-Record oder eine Weiterleitung/Parking-Einstellung. Entferne widersprüchliche Einträge; pro Name und Typ sollte genau ein Wert stehen (bewusste Ausnahmen ausgenommen).

Du hast einen AAAA-Record eingetragen, obwohl der Server keine funktionierende IPv6-Adresse hat. Browser bevorzugen dann IPv6 und laufen in einen Timeout. AAAA-Record entfernen, bis der Server wirklich IPv6 kann.

Der abschließende Punkt (Root der DNS-Hierarchie) ist normal und korrekt – viele DNS-Verwaltungen ergänzen ihn automatisch. Kein Grund zur Sorge.

Der Reverse-DNS-Eintrag (PTR) fehlt oder passt nicht zum Absender-Hostnamen. Setze den PTR wie in Schritt 5 beschrieben beim VPS-Anbieter und achte darauf, dass er auf denselben Namen zeigt, der auch per A-/AAAA-Record auflöst.

Die SSH-Regel fehlte oder betraf den falschen Port. Verbinde dich über die Konsole im netcup SCP (VNC, unabhängig von SSH), erlaube dort deinen SSH-Port (sudo ufw allow …) und teste erneut. Genau davor warnt Schritt 3.

Das OpenSSH-Profil existiert nur, wenn openssh-server installiert ist. Nutze stattdessen die Portnummer: sudo ufw allow 22/tcp (bzw. deinen Port). sudo ufw app list zeigt die verfügbaren Profile.

Kein Fehler von dir – Docker umgeht UFW. Docker schreibt seine Regeln direkt in iptables und hängt sie vor die UFW-Ketten. Ein veröffentlichter Container-Port (ports: in der compose.yaml) ist damit offen, egal was UFW sagt. Die saubere Lösung ist eine zweite Firewall-Ebene vor dem Server – bei netcup die Firewall im SCP als vorgelagerter Perimeter. Auf dem Host hilft außerdem, Container-Ports nur an 127.0.0.1 zu binden statt an 0.0.0.0.

Hängt unter Medien → DVD-Laufwerk ein .iso-Image im virtuellen Laufwerk, verweigert das SCP neue Snapshots. Wirf das Image dort aus – in der Server-Übersicht muss die Zeile ISO wieder - zeigen – und starte den Snapshot erneut.

Ein Snapshot braucht Platz neben deinen Live-Daten. Räume auf dem Server auf, gib die freigewordenen Blöcke mit fstrim -av an den Host zurück, lösche nicht mehr benötigte Snapshots und stoße im SCP unter Medien → Festplatten die Speicheroptimierung an.

Ein Online-Snapshot fängt einen laufenden Schreibvorgang womöglich mittendrin ein. Für Server mit Datenbank nimm einen Offline-Snapshot oder erstelle vorher einen Datenbank-Dump.

Das SCP nutzt eigene Zugangsdaten (nicht SSH). Sie stehen in der Willkommensmail; ein vergessenes SCP-Passwort setzt du im netcup-Kundenkonto (CCP) zurück.

Die DNS-Antworten werden geblockt. Prüfe im Basis-Template die Regel EINGEHEND UDP ACCEPT, Src-Port 53. Wichtig: Quell-Port, nicht Ziel-Port.

Die NTP-Antworten fehlen. Ergänze EINGEHEND UDP ACCEPT, Src-Port 123.

Es fehlt die ICMPv6-Regel. Ohne Neighbor Discovery kann der Server über IPv6 nicht einmal seinen Nachbarn (Router) finden.

Die SSH-Regel fehlt oder nennt den falschen Port. Über die VNC-Konsole (SCP → Bildschirm) kommst du trotzdem auf den Server; korrigiere die Policy und speichere neu. Genau dagegen hilft die „zweite Sitzung offen lassen"-Regel oben.

Das ist kein Fehler deiner Policy, sondern netcups Default-Policy „netcup Mail block" – sie sperrt ausgehendes SMTP (Port 25/465/587) als Spam-Schutz. Für einen echten Mailversand musst du dieses netcup-Template am Server deaktivieren.

Nutzt der Server DHCP, wird die Lease-Erneuerung von der Whitelist geblockt – die DHCP-Antwort kommt von UDP-Quell-Port 67, den keine Regel erlaubt, und UDP ist zustandslos. Ergänze EINGEHEND · UDP · ACCEPT · Src 67 im Basis-Template. Statisch konfigurierte netcup-VPS (der Standard) sind davon nicht betroffen.

Die Paketquelle aus Schritt 2 fehlt oder ist fehlerhaft – apt kennt den Namen nur aus den Abhängigkeiten der Debian-Pakete, findet aber kein Paket dazu. Prüfe den Inhalt von /etc/apt/sources.list.d/docker.list – dort muss deine Debian-Version (z. B. trixie) stehen – und führe danach erneut sudo apt update aus.

Die docker-Gruppenmitgliedschaft greift noch nicht. SSH-Sitzung beenden und neu verbinden; groups muss danach docker enthalten. Falls nicht, Schritt 4 wiederholen.

Auf dem System ist schon eine andere Docker-Variante installiert (docker.io, podman-docker, …). Alte Pakete zuerst entfernen: sudo apt remove docker.io docker-doc docker-compose podman-docker containerd runc – bestehende Container/Images bleiben dabei erhalten.

Das Compose-Plugin fehlt – wahrscheinlich wurde Docker früher anders installiert. sudo apt install docker-compose-plugin nachholen. Achtung: Das alte docker-compose (mit Bindestrich) ist ein anderes, veraltetes Werkzeug.

Meist stimmen die Dateirechte auf dem Server nicht: SSH ignoriert authorized_keys, wenn Gruppe oder andere in ~/.ssh schreiben dürfen. Im Log auf dem Server (sudo journalctl -u ssh --since -5min) steht dann Authentication refused: bad ownership or modes for directory /home/koch/.ssh. Repariere mit chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys und prüfe außerdem, dass du dich mit dem richtigen Benutzer verbindest (koch@…, nicht root@…).

Passwort-Login wurde deaktiviert, bevor der Schlüssel funktionierte. Kein Drama: Öffne die VNC-Konsole im netcup SCP, melde dich dort lokal an, setze PasswordAuthentication yes, starte SSH neu und beginne wieder bei Schritt 2.

Syntaxfehler in der sshd_config – ein verschriebenes PasswordAuthentification genügt (deshalb immer sshd -t vor dem Neustart). Über die VNC-Konsole einloggen, dann nennt sudo sshd -t Datei, Zeile und Option: /etc/ssh/sshd_config: line 125: Bad configuration option: PasswordAuthentification gefolgt von /etc/ssh/sshd_config: terminating, 1 bad configuration options.

Eine Datei unter /etc/ssh/sshd_config.d/ (häufig 50-cloud-init.conf) überschreibt deine Werte. sudo sshd -T | grep -i passwordauthentication zeigt die tatsächlich wirksame Einstellung – Treffer in den Zusatzdateien anpassen und SSH neu starten.

Meist ist die IP falsch abgetippt oder der Server noch nicht fertig provisioniert. Prüfe die IP in deinem Kundenkonto und ob der Server dort als „online" angezeigt wird. Warte nach der Bestellung ein paar Minuten.

Falsches Passwort – oft ein Copy-Paste-Problem mit unsichtbaren Leerzeichen am Ende oder ein abweichendes Tastaturlayout. Kopiere das Passwort ohne umgebende Leerzeichen direkt aus den Zugangsdaten.

Der Server wurde neu installiert und hat einen neuen Host-Key – SSH schlägt zu Recht Alarm. Wenn du selbst neu installiert hast, entferne den alten Eintrag mit ssh-keygen -R DEINE_SERVER_IP und verbinde neu. Hast du nicht neu installiert, geh der Sache nach, bevor du dich verbindest.

Auf Minimal-Images fehlt das Paket manchmal. Als root nachinstallieren: apt install sudo. Danach prüfen, dass der Benutzer in der Gruppe ist: groups koch muss sudo enthalten – sonst Schritt 3 wiederholen und einmal ab- und wieder anmelden.