Die Quelle begann mit einer plausiblen Theorie zu veralteten AppData, aber der abschließende Beitrag macht diese Erklärung unzureichend. Apps, die zuvor entfernt worden waren, übersprangen das Einrichtungsformular und versuchten, nicht vorhandene Bind-Pfade wiederzuverwenden, wodurch Docker-Fehler wie bind source path does not exist entstanden. Eine Antwort aus der Community schlug vor, den alten AppData-Ordner zu entfernen oder umzubenennen, damit ZimaOS die App als neu behandelt.
Der ursprüngliche Verfasser berichtete anschließend, dass dies einmal funktioniert hatte, später jedoch nicht mehr half. Noch wichtiger: Auch neu installierte Apps übersprangen bei der ersten Installation das Einstellungsformular und blieben bei 100 % hängen, während die Installation von Apps über YAML weiterhin funktionierte. Dadurch richtet sich der stärkste Verdacht nicht mehr auf ein einzelnes fehlerhaftes App-Verzeichnis, sondern auf den historischen UI-/Konfigurationspfad des App Stores selbst.
Der Docker-Fehler war real, aber nachgelagert
Der sichtbare Fehler sah folgendermaßen aus:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]Docker lehnte korrekt einen Bind-Mount ab, dessen Quellverzeichnis auf dem Host nicht existierte. Die offene Frage war, warum der App Store diesen Pfad generierte oder wiederverwendete, ohne das Einstellungsformular anzuzeigen, über das der Benutzer ihn normalerweise auswählen oder erstellen kann.
Veraltete AppData waren eine Vermutung der Community
gelbuilding schlug vor, /DATA/AppData/<app-name> zu löschen oder umzubenennen, damit der Store die Installation als neu behandelt. Ein weiteres Community-Mitglied sagte, dass es dieselbe Methode verwendet habe.
Das war keine Diagnose von IceWhale-Mitarbeitern, und der spätere Test des ursprünglichen Verfassers zeigte, dass dies für das umfassendere Problem nicht ausreichte.
Dass auch Apps bei der Erstinstallation das Formular übersprangen, ändert die Diagnose
Sobald auch neue Apps ohne vorheriges lokales AppData die Konfiguration übersprangen, war das wiederholte Löschen alter Ordner der falsche Ansatz zur Fehlersuche. Der Benutzer erklärte ausdrücklich, dass Neustart + Ordnerlöschung + Neuinstallation zum gleichen Ergebnis führten.
Die funktionierende YAML-Installation war ein wichtiger Hinweis
Der Benutzer sagte, dass Apps weiterhin aus YAML installiert werden konnten. Das deutet darauf hin, dass Docker selbst nicht vollständig defekt war, und grenzt das historische Problem eher auf den Workflow zur App-Definition, Konfiguration oder Darstellung im Store ein.
ZimaOS 1.7 hat die Architektur des App Stores überarbeitet
ZimaOS 1.7.0 führte den App Store 2.0 mit einer überarbeiteten Oberfläche zur Suche und Verwaltung sowie nativer YAML-Bearbeitung und -Analyse ein. ZimaOS 1.7.1 ergänzte anschließend weitere Korrekturen für Docker, AppData, WebUI und YAML.
Siehe die aktuelle Grundlage des App Store 2.0.
Aktuelle Reihenfolge der Fehlersuche
- auf die aktuelle stabile ZimaOS-Version aktualisieren;
- eine einfache Erstanbieter-App testen, die noch nie installiert wurde;
- den genauen fehlenden Bind-Pfad auf dem Host erfassen;
- prüfen, ob der Ordner existiert und zu welchem Speicher er gehört;
- prüfen, ob die YAML-Installation mit demselben vorgesehenen Pfad erfolgreich ist;
- bei weiterhin fehlerhaftem Einstellungsformular die App-Store- und Container-Logs sammeln.
AppData bei zustandsbehafteten Apps nicht blind löschen
Ein AppData-Ordner kann Datenbanken, Konfigurationen, Schlüssel, Bibliotheken und den Benutzerstatus enthalten. Beim Testen ist das Umbenennen sicherer als das Löschen; wichtige Daten sollten zuvor gesichert werden.
FAQ zum fehlenden Einstellungsformular
Hat das Löschen alter AppData das ursprüngliche Problem dauerhaft behoben?
Nein. Der ursprüngliche Verfasser sagte, dass es einmal geholfen habe, später jedoch nicht mehr funktionierte.
Waren auch Apps bei der Erstinstallation betroffen?
Ja. Im abschließenden Beitrag der Quelle steht, dass auch neue Apps das Konfigurationsformular übersprangen und hängen blieben.
Funktionierte die YAML-Installation weiterhin?
Ja. Das war einer der stärksten Hinweise darauf, dass der historische Fehler mit dem App-Store-Pfad zusammenhing und nicht damit, dass Docker vollständig nicht verfügbar war.
