Fehlerbehebung
Schwarze oder leere Seite, installierte App bleibt schwarz, Lizenzserver nicht erreichbar, Lizenz auf anderer Installation aktiv, Endpoint-Limit, Setup-Token verloren, Backups mit „No such image“, gruppierte Listen mit nur Gruppenköpfen, Passwort eines Benutzers zurücksetzen.
Die häufigsten Probleme und ihre Lösung. Passt nichts davon, frag im Forum oder schreib an support@containly.ch.
Die Seite
Die Seite bleibt im Browser leer oder schwarz
Du öffnest Containly über reines HTTP, aber CONTAINLY_SECURE_COOKIES=true ist gesetzt. Der Browser holt dann alle Dateien über HTTPS, und das wird nicht ausgeliefert. Setz CONTAINLY_SECURE_COOKIES=false in der .env, starte mit docker compose up -d neu und lade die Seite mit Ctrl+Shift+R neu. true gehört nur hinter einen Reverse Proxy mit HTTPS.
Die installierte App (PWA) zeigt einen schwarzen Bildschirm
Die installierte App hat zwar ihre eigene Hülle, braucht für jede Seite aber deinen Containly-Server; API-Anfragen werden nie zwischengespeichert. Erreicht das Handy den Server nicht, kann die App schwarz bleiben: zum Beispiel ausserhalb deines Heimnetzes, mit ausgeschaltetem VPN oder wenn eine Firewall oder der Reverse Proxy die Adresse sperrt. Öffne dieselbe Adresse im Browser des Handys: Lädt auch sie nicht, zuerst die Verbindung lösen (VPN verbinden, Firewall und Proxy prüfen). Geht es im Browser, aber nicht in der App, schliess die App ganz und öffne sie wieder, oder entferne sie und installiere sie aus dem Browser neu.
Das Setup-Formular nimmt mein Token nicht an
Das Setup-Token steht einmal im Log (docker compose logs containly) und liegt ausserdem als /data/setup.token im Volume containly-data. Es gilt nur, solange es keinen Admin gibt; nach dem ersten Admin ist der Setup-Modus endgültig geschlossen.
Port 8420 ist schon belegt
Ändere PORT in der .env und die ports:-Zuordnung in der docker-compose.yml auf denselben freien Port und führe docker compose up -d aus.
Lizenz
„Lizenzserver nicht erreichbar“
Containly konnte die Lizenz nicht erneuern. Pro bleibt bis zum Datum auf der Karte aktiv und erneuert sich von selbst, sobald die Verbindung wieder steht. Prüf, ob der Containly-Server containly.ch über HTTPS erreicht (ausgehende Firewall, Proxy, DNS), und klick dann unter Einstellungen, Version und Lizenz auf „Jetzt prüfen“.
„Diese Lizenz ist bereits auf einer anderen Containly-Installation aktiv“
Eine Lizenz gilt für eine Containly-Installation. Deaktiviere sie auf der anderen Installation unter Einstellungen, Version und Lizenz, oder gib diese Installation in deinem Containly-Konto frei („Für Umzug freigeben“). Danach aktivierst du sie auf dieser Installation nochmals. Kein Zugriff mehr auf die andere Installation? Schreib an support@containly.ch.
„Das sieht nicht wie ein Lizenzschlüssel aus“ oder „Dieser Lizenzschlüssel ist ungültig“
Kopier den ganzen Schlüssel aus der Schlüssel-Mail; er beginnt mit CL1-. Schlüssel aus dem Shop brauchen Containly 2.1.0 oder neuer.
Hosts
„Endpoint-Limit erreicht“
Die Gratisversion erlaubt 2 Endpoints, den lokalen Host eingeschlossen. Eine Pro-Lizenz hebt das Limit auf.
Der Agent bleibt bei „Warte auf Verbindung des Agents“
Prüf die Logs des Agents auf dem Ziel-Host. Der Agent verbindet sich per WSS zu deiner Containly-Adresse, diese muss also vom entfernten Host aus erreichbar sein; das Einmal-Token gilt nur einmal.
Backups
Backups schlagen mit „No such image: alpine:latest“ fehl
Bis Containly 2.7.3 ist ein Backup mit (HTTP code 404) no such container - No such image: alpine:latest fehlgeschlagen, wenn das Hilfs-Image nach dem Start von Containly vom Docker-Host entfernt wurde, zum Beispiel durch docker image prune -a oder ein Aufräumskript. Containly 2.7.4 behebt das: Das Hilfs-Image ist auf eine feste Alpine-Version angeheftet und wird automatisch neu gezogen, wenn es fehlt. Aktualisiere also auf 2.7.4 oder neuer. Mit einer älteren Version führst du auf dem betroffenen Docker-Host docker pull alpine:latest aus; das nächste Backup läuft dann wieder, ohne Containly neu zu starten.
Der SMB-Verbindungstest meldet eine fehlende Sandbox oder einen fehlenden Systemaufruf
Ab Containly 2.5.0 startet das SMB-Ziel smbclient in einer Landlock-Sandbox. Das braucht auf dem Rechner, auf dem Containly läuft, Linux-Kernel 6.7 oder neuer und das Standard-Seccomp-Profil von Docker. Prüf mit uname -r und stell sicher, dass der Containly-Container kein eigenes Seccomp-Profil hat, das die landlock_*-Systemaufrufe blockiert. Ohne Sandbox bleibt SMB bewusst aus; es gibt keinen schwächeren Ersatzweg. Andere Backup-Ziele sind nicht betroffen. Die Backup-Anleitung nennt alle Voraussetzungen.
SMB lehnt die Verbindung ab
Containly akzeptiert nur SMB3 mit Verschlüsselung. Schalte auf dem Server die SMB-Verschlüsselung für die Freigabe ein (bei Samba smb encrypt = required, bei Windows Server die Verschlüsselung der Freigabe).
Wiederherstellen auf einem anderen Host wird abgelehnt
Das Wiederherstellen auf einem anderen Docker-Host braucht eine Pro-Lizenz. Ein Stack wird ausserdem abgelehnt, wenn seine Compose-Datei privilegiert ist, Host-Namespaces, externe Volumes oder Bind-Mounts ausserhalb des Stack-Ordners nutzt. Die Vorschau nennt den Grund; siehe die Backup-Anleitung.
Listen und Benutzer
Eine Liste zeigt nur Gruppenköpfe
Die Liste ist gruppiert (siehe Ansicht in der Werkzeugleiste). Seit Containly 2.6.1 startet jede Gruppe geschlossen; ein Klick auf den Kopf öffnet sie, oder du wählst unter Ansicht Liste für die einfache Liste. In einer gruppierten Liste zählt Pro Seite Gruppen. Die Anleitung zu den Ansichten erklärt alle Gruppierungen.
Wo ist „Passwort zurücksetzen“ für einen Benutzer?
Öffne Benutzer und das Drei-Punkte-Menü des Benutzers (in der Liste oder oben in den Benutzerdetails), dann Passwort zurücksetzen. Das gibt es nur für lokale Konten. Die Benutzerdetails zeigen unter dem Namen die Rolle und die Anmeldequelle (Lokal oder Entra) nebeneinander.