Wenn Docker nach einer ZimaOS-Datenmigration den Start verweigert, kann die letzte Zeile im Protokoll irreführend sein. In diesem Ausgangsfall vom Februar 2026 meldete Docker schließlich, dass der Speichertreiber overlay2 nicht unterstützt werde. Einige Zeilen weiter oben zeigt sich jedoch der eigentliche Fehler: Docker konnte keine temporären Dateien erstellen oder den Overlay-Speicher testen, weil auf der Systemfestplatte kein Speicherplatz mehr auf dem Gerät vorhanden war.
Der Benutzer hatte eine 180-GB-ZimaOS-SSD und versehentlich eine wachsende Immich-Datenbank darauf belassen. Als er die Migration starten wollte, war nicht genügend freier Speicherplatz für eine saubere Verschiebung vorhanden. Nach mehreren Versuchen und dem manuellen Löschen von Protokollen schien AppData migriert worden zu sein, doch die Systemfestplatte war weiterhin zu 100 % ausgelastet, und Docker konnte sich nach dem Neustart nicht mehr initialisieren.
Immich füllte die kleine System-SSD vor der Migration
Der Benutzer installierte Immich, ohne dessen Datenbank von der Systemfestplatte zu verschieben. Als die Fotosammlung wuchs, füllte sich die Festplatte, und ZimaOS begann, Fehler zu melden.
Dies entspricht den aktuellen Empfehlungen von IceWhale: Anwendungsdaten sollten auf dem Hauptspeicher und nicht auf einer kleinen Systemfestplatte abgelegt werden, da Fotobibliotheken, Medienmetadaten, Dokumentindizes, Datenbanken und Caches schnell wachsen können.
Die Migration selbst benötigte Arbeitsbereich
Der Benutzer versuchte den ZimaOS-Migrationsworkflow erst, als die Systemfestplatte bereits kritisch voll war. Er gab an, dass die ersten Migrationsversuche wegen unzureichenden freien Speicherplatzes zum Zwischenspeichern des Vorgangs fehlschlugen.
Dies ist eine wichtige Lehre für den Betrieb: Verschieben Sie AppData, bevor auf der Systemfestplatte nur noch wenige Gigabyte frei sind – nicht erst, nachdem Docker und die Migrationsdienste bereits unter Platzmangel leiden.
Die Docker-Socket-Meldung war nur ein Symptom
Die Anwendungen meldeten:
Es kann keine Verbindung zum Docker-Daemon unter unix:///var/run/docker.sock hergestellt werden.
Läuft der Docker-Daemon?Diese Meldung bedeutet, dass der Docker-Daemon nicht verfügbar ist. Sie gibt nicht an, warum der Daemon ausgefallen ist.
Das Journal enthüllte die eigentliche Ursache
Die wichtigen Zeilen waren:
Kein Speicherplatz mehr auf dem Gerät
Das Standard-AppArmor-Profil konnte nicht geladen werden.
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
Der Daemon konnte nicht gestartet werden: Fehler beim Initialisieren des Graph-TreibersDocker schlug zunächst fehl, weil keine temporären Daten geschrieben werden konnten. Später erschien die Meldung Treiber nicht unterstützt Die Meldung war eine Folge der fehlgeschlagenen Initialisierung des Speichertreibers und kein Hinweis darauf, dass der laufende Kernel nach der Migration plötzlich die Unterstützung für overlay2 verloren hatte.
Warum der Neustart von Docker das Problem nicht löste
Der Benutzer versuchte, Docker neu zu starten docker.service und docker.socket manuell neu und erhielt „Zugriff verweigert“. Eine Antwort aus der Community brachte dies mit den dienstspezifischen Steuerungen von ZimaOS im Appliance-Stil in Verbindung.
Selbst wenn der Neustart des Dienstes möglich gewesen wäre, hätte er keinen freien Speicherplatz geschaffen. Der Daemon wäre einfach erneut auf denselben Schreibfehler gestoßen.
Das Löschen temporärer Docker-Dateien schaffte nicht genügend Speicherplatz
Die Community schlug vor, zunächst den Speicherplatz zu überprüfen und anschließend temporäre Docker-Dateien zu löschen. Der ursprüngliche Benutzer versuchte dies und antwortete, dass das Systemlaufwerk weiterhin zu 100 % voll sei und Docker immer noch nicht starten würde.
Dieses negative Ergebnis ist hilfreich: Eine kleine vorübergehende Bereinigung kann kein Speicherkonzept reparieren, bei dem die Systemfestplatte vollständig ausgelastet bleibt.
Der ursprüngliche Benutzer entschied sich für Backup und Wiederherstellung auf die Werkseinstellungen
Nach dem fehlgeschlagenen Bereinigungsversuch beschloss der Benutzer, ein Backup zu erstellen. /DATA/AppData und ZimaOS neu zu installieren/wiederherzustellen. Der Community-Responder empfahl, die installierten Apps zu notieren, die Systemwiederherstellung auf die Werkseinstellungen zu verwenden und anschließend den anwendungsbezogenen Speicher vor der Neuinstallation der Apps auf das große Laufwerk zu migrieren.
Der öffentliche Thread endet, nachdem der Benutzer mitgeteilt hatte, dass er dies tun würde. Er enthält keine Bestätigung nach der Wiederherstellung. Daher sollte die Seite die Neuinstallation nicht als verifizierte endgültige Lösung für diesen konkreten Benutzer darstellen.
Die Datenmigration des aktuellen ZimaOS macht expliziter, was verschoben werden kann
Das aktuelle ZimaOS bietet separate Migrationskategorien für:
- Docker-Images;
- Docker-Anwendungsdaten;
- Benutzerdatenbanken wie Galerie, Downloads, Dokumente, Medien und Backup.
Dies ist ein wichtiges Update zum älteren Thread, in dem die Diskussion „AppData-Migration“ teilweise so behandelte, als würde sie automatisch den gesamten Docker-Speicher abdecken.
Verwenden Sie die aktuellen Kategorien der ZimaOS-Datenmigration, bevor ein kleines Systemlaufwerk kritisch voll wird.
Das Problem verhindern, indem der Speicherort für App-Daten frühzeitig festgelegt wird
Das aktuelle ZimaOS bietet außerdem unter Einstellungen > Apps einen Speicherort für App-Daten. IceWhale empfiehlt, ihn von Anfang an auf das Speicher-Array zu verweisen, anstatt das gesamte Wachstum persistenter Apps auf dem Systemgerät zu belassen.
Die aktuelle Erklärung dazu, wo ZimaOS-Apps persistente Daten speichern, ist die beste vorbeugende Referenz.
Kapazität und Inodes prüfen
Ein Dateisystem kann neue Dateien ablehnen, weil keine freien Blöcke mehr vorhanden sind oder weil die Inodes aufgebraucht sind. Die Fehlerbehebung für das Quellsystem empfahl, beides zu prüfen. Das Protokoll in diesem Fall deutet stark auf eine normale Erschöpfung der Speicherkapazität hin, aber die Prüfung beider Werte ist weiterhin eine nützliche schreibgeschützte Diagnose.
Wann eine Neuinstallation sinnvoll wird
Wenn der Systemdatenträger zu 100 % voll war, Docker-Speichermetadaten beschädigt sind, der Daemon nicht starten kann und eine sichere Bereinigung nicht genügend Arbeitsbereich schaffen kann, ist eine kontrollierte Systemwiederherstellung möglicherweise schneller und sicherer als die manuelle Bearbeitung der Docker-Overlay-Metadaten.
Schützen Sie zuerst AppData und Benutzerdaten, prüfen Sie, auf welche Datenträger die Wiederherstellung zugreift, und vermeiden Sie es, die einzige Kopie von Anwendungsdatenbanken zu löschen.
FAQ zu Docker nach der Migration
War overlay2 auf der Quellhardware tatsächlich nicht unterstützt?
In den Protokollen wird zunächst angezeigt, dass Docker keine overlay2-Testdateien erstellen konnte, weil der Datenträger voll war. Die Treibernachricht folgte auf diesen Fehler.
Hat das Leeren des Docker-Tmp-Verzeichnisses das Quellsystem repariert?
Nein. Der ursprüngliche Verfasser sagte, dass das Betriebssystemlaufwerk weiterhin zu 100 % voll war.
Ermöglicht das aktuelle ZimaOS, Docker-Images getrennt von AppData zu verschieben?
Ja. In der aktuellen Datenmigration werden Docker-Images und Docker-Anwendungsdaten als separate verschiebbare Kategorien aufgeführt.
Wurde im Thread bestätigt, dass die werkseitige Wiederherstellung erfolgreich war?
Nein. Der Nutzer sagte, dass er damit fortfahren würde, aber der öffentliche Thread endet, bevor ein Ergebnis nach der Wiederherstellung vorliegt.
