CasaOS Portainer lokale Umgebung: Wiederherstellungsleitfaden für Docker 29

Diese Quelle enthält mehrere Fehler, die kurz hintereinander auftraten. Daher sollte sie nicht als ein einfacher „Portainer-Fehler“ umgeschrieben werden. Auf dem Systemlaufwerk war fast kein freier Speicher mehr vorhanden, Docker und containerd wurden über Debian auf neue Hauptversionen aktualisiert, ein älterer Docker-CLI-Test wurde vom Docker-29-Daemon abgewiesen, Portainer verlor seine lokale Umgebung, CasaOS zeigte weiterhin „Apps werden geladen“ an, und ein späteres Boot-Problem ließ das Dashboard fast wie eine Neuinstallation aussehen.

Keine Antwort in der Quelle bestätigt eine einzige endgültige Ursache. Die sicherste Interpretation ist ein mehrschichtiges Wiederherstellungsproblem: Zuerst die vorhandenen Daten sichern, anschließend feststellen, welcher Bootvorgang bzw. welches Root-Dateisystem aktiv ist, ob das Docker-Datenverzeichnis noch vorhanden ist, ob der Daemon ordnungsgemäß läuft und ob Portainer/CasaOS mit der aktualisierten Docker-API kompatibel sind.

Die Systemfestplatte stand bereits unter erheblichem Speicherdruck

Der Benutzer hatte vor der Bereinigung auf einem 27-GB-Root-Dateisystem nur noch etwa 1 GB freien Speicher. Zu den größten Verbrauchern gehörten Docker-Overlay-Daten, Jellyfin-Metadaten, Systemprotokolle und Entwicklungspakete.

Wenig freier Speicher kann dazu führen, dass Docker-Image- und Container-Vorgänge, Datenbanken, Protokolle und CasaOS-Dienste unvorhersehbar reagieren. Speicher freizugeben war unabhängig vom späteren Docker-API-Problem notwendig.

Das Host-Upgrade änderte Docker von 28.x auf 29.0.0

Die Debian-Paketverläufe zeigten Aktualisierungen von:

docker-ce;
docker-ce-cli;
containerd.io;
Docker-Rootless-Erweiterungen.

Ein größeres Docker-Engine-Upgrade kann Kompatibilitätsprobleme in Verwaltungstools aufdecken, die ältere API-Clients integrieren oder aushandeln.

Die Quelle dokumentierte eine tatsächliche Abweichung bei der Docker-API-Version

Ein Docker-24.0.5-CLI-Container gab Folgendes zurück:

client version 1.43 is too old.
Minimum supported API version is 1.44

Diese Meldung ist ein direkter Beleg dafür, dass mindestens ein älterer Client nicht mehr mit dem aktualisierten Docker-Daemon kommunizieren konnte. Sie beweist nicht für sich genommen, dass Portainer genau diese Client-Version verwendet hat, macht die API-Kompatibilität jedoch zu einer vorrangigen Prüfung.

Dass Portainer „Local“ zunächst anzeigt und anschließend verliert, ist ein Symptom der Verwaltungsebene

Die Quelle versuchte, eine lokale Docker-Umgebung über /var/run/docker.sock neu zu erstellen, jedoch ohne Erfolg. Bevor der Portainer-Zustand gelöscht wird, sollte Folgendes überprüft werden:

docker info
docker ps
ls -l /var/run/docker.sock

Wenn die Docker-CLI selbst funktioniert, Portainer jedoch nicht, sollte der Fokus auf der Portainer-Version, der API-Kompatibilität und dem Socket-Zugriff liegen. Wenn Docker selbst fehlschlägt, muss zuerst der Daemon repariert werden.

CasaOS mit „Apps werden geladen“ deutet darauf hin, dass der Fehler umfassender als ein Portainer-Problem war

Auch CasaOS hatte Schwierigkeiten, Anwendungen aufzulisten. Das kann passieren, wenn Docker nicht verfügbar ist, sich die Docker-API inkompatibel geändert hat, das Datenverzeichnis des Daemons fehlt oder der gestartete Host nicht mehr dem erwarteten Systemzustand entspricht.

Das spätere Ereignis „Richtiges Boot-Gerät auswählen“ verändert die Priorität der Wiederherstellung

Nach einem Neustart startete der Rechner nicht mehr normal, bis der Benutzer die Boot-Auswahl änderte. Nach dem erfolgreichen Start zeigte CasaOS keine Apps an, obwohl die große HDD weiterhin eingebunden war.

Das lässt vermuten, dass möglicherweise ein anderes Startlaufwerk bzw. Root-Dateisystem ausgewählt wurde oder dass sich die Systempartition bzw. der Systemzustand geändert hat. Die Quelle belegt jedoch nicht, welche dieser Möglichkeiten zutrifft.

AppData vor einer Neuinstallation von CasaOS sichern

Für den Benutzer waren vor allem folgende Daten wichtig:

/home/casaos-Projektdateien;
Jellyfin-Metadaten unter AppData;
Mediendateien auf der HDD;
Docker-/CasaOS-Konfigurationen, soweit sie wiederherstellbar sind.

Diese beständigen Ordner sollten auf ein anderes Laufwerk oder System kopiert werden, bevor CasaOS neu installiert oder Docker zurückgesetzt wird. Container neu zu erstellen ist meist einfacher, als Anwendungsdatenbanken und Metadaten wiederherzustellen.

Docker nicht aggressiv bereinigen, bevor bekannt ist, was noch verwendet wird

Das Entfernen nicht verwendeter Images kann Speicher freigeben. Das Löschen von Volumes oder Verzeichnissen des Datenverzeichnisses kann jedoch den Anwendungszustand entfernen, den Sie eigentlich sichern möchten. Ermitteln Sie daher zuerst Container, Volumes, Bind-Mounts und AppData-Pfade.

Debian- und Docker-Updates als Teil der CasaOS-Plattform behandeln

CasaOS läuft auf dem zugrunde liegenden Linux-Host. Ein umfassendes apt upgrade kann Docker, Kernel, systemd, Netzwerk- und Speicherpakete aktualisieren, von denen CasaOS abhängt. Größere Host-Upgrades sollten gezielt getestet werden. Sichern Sie das System und die Anwendungen, bevor Sie solche Aktualisierungen auf einem funktionierenden NAS durchführen.

FAQ zur Wiederherstellung von Portainer/CasaOS

Hat die Quelle bewiesen, dass Docker 29 allein alle Fehler verursacht hat?

Nein. Das System war außerdem fast vollständig belegt, und später trat ein Problem mit dem Boot-Gerät bzw. Systemzustand auf.

Wurde eine Abweichung bei der Docker-API bestätigt?

Ja. Eine Docker-24-CLI mit API 1.43 wurde abgewiesen, weil der Docker-29-Daemon mindestens Version 1.44 verlangte.

Sollte der Benutzer CasaOS neu installieren, bevor er AppData kopiert?

Nein. Sichern Sie wichtige AppData, Dateien im Home-Verzeichnis und Mediendateien zuerst, sofern die Laufwerke weiterhin zugänglich sind.