Źródło początkowo przedstawiało wiarygodną teorię dotyczącą nieaktualnych danych AppData, jednak końcowy wpis pokazuje, że to wyjaśnienie jest niewystarczające. Aplikacje, które wcześniej zostały usunięte, pomijały formularz konfiguracji i próbowały ponownie użyć nieistniejących ścieżek montowania, powodując błędy Dockera, takie jak bind source path does not exist. W odpowiedzi społeczności zasugerowano usunięcie lub zmianę nazwy starego folderu AppData, aby ZimaOS potraktował aplikację jako nową.
Autor oryginalnego wpisu poinformował następnie, że zadziałało to raz, ale później przestało pomagać. Co ważniejsze, nowe aplikacje instalowane po raz pierwszy również zaczęły pomijać formularz ustawień i zawieszać się na poziomie 100%, podczas gdy instalowanie aplikacji za pomocą YAML nadal działało. To przesuwa główne podejrzenia z jednego uszkodzonego katalogu aplikacji na historyczną ścieżkę interfejsu i konfiguracji App Store.
Błąd Dockera Był Prawdziwy, Ale Wtórny
Widoczna awaria wyglądała następująco:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]
Docker prawidłowo odrzucał montowanie typu bind, którego katalog źródłowy po stronie hosta nie istniał. Pozostawało pytanie, dlaczego App Store generował lub ponownie używał tej ścieżki bez wyświetlania formularza ustawień, który normalnie pozwala użytkownikowi wybrać lub utworzyć odpowiedni katalog.
Nieaktualne AppData Były Hipotezą Społeczności
gelbuilding zasugerował usunięcie lub zmianę nazwy /DATA/AppData/<app-name>, aby sklep potraktował instalację jako nową. Inny członek społeczności powiedział, że stosował tę samą metodę.
Nie była to diagnoza pracownika IceWhale, a późniejszy test autora wpisu wykazał, że nie rozwiązuje ona szerszego problemu.
Pomijanie Formularza Także Przez Aplikacje Instalowane Po Raz Pierwszy Zmienia Diagnozę
Gdy nowe aplikacje, które nie miały wcześniej lokalnych danych AppData, również zaczęły pomijać konfigurację, wielokrotne usuwanie starych folderów przestało być właściwą ścieżką rozwiązywania problemu. Użytkownik wyraźnie stwierdził, że ponowne uruchomienie, usunięcie folderu i ponowna instalacja prowadziły do tego samego rezultatu.
Działająca Instalacja Za Pomocą YAML Była Istotną Wskazówką
Użytkownik poinformował, że aplikacje nadal można instalować z użyciem YAML. Sugeruje to, że Docker nie był całkowicie uszkodzony, i zawęża źródło historycznego problemu do procesu definiowania aplikacji, konfiguracji lub renderowania w sklepie.
ZimaOS 1.7 Przebudował Architekturę App Store
ZimaOS 1.7.0 wprowadził App Store 2.0 z przeprojektowanym interfejsem wyszukiwania i zarządzania oraz natywną edycją i analizowaniem YAML. Następnie ZimaOS 1.7.1 dodał kolejne poprawki dotyczące Dockera, AppData, WebUI i YAML.
Zobacz aktualną wersję bazową App Store 2.0.
Obecna Kolejność Diagnostyki
- zaktualizuj system do najnowszej stabilnej wersji ZimaOS;
- przetestuj jedną prostą aplikację pierwszej firmy, która nigdy wcześniej nie była instalowana;
- zapisz dokładną brakującą ścieżkę montowania po stronie hosta;
- sprawdź, czy folder istnieje i do którego magazynu należy;
- sprawdź, czy instalacja YAML działa z użyciem tej samej zamierzonej ścieżki;
- jeśli formularz ustawień nadal nie działa, zbierz logi App Store i kontenera.
Nie Usuwaj Bezkrytycznie AppData w Aplikacjach Przechowujących Dane
Folder AppData może zawierać bazy danych, konfigurację, klucze, biblioteki i dane użytkownika. Podczas testów bezpieczniej jest zmienić jego nazwę niż go usuwać, a wcześniej należy wykonać kopię zapasową ważnych danych.
FAQ: Brak Formularza Ustawień
Czy usunięcie starego AppData trwale rozwiązało pierwotny problem?
Nie. Autor oryginalnego wpisu stwierdził, że początkowo pomogło, ale później przestało działać.
Czy problem dotknął także aplikacji instalowanych po raz pierwszy?
Tak. Końcowy wpis źródłowy mówi, że nowe aplikacje również pomijały formularz konfiguracji i zawieszały się.
Czy instalacja YAML nadal działała?
Tak. Była to jedna z najsilniejszych wskazówek, że historyczna awaria była związana ze ścieżką App Store, a nie z całkowitą niedostępnością Dockera.
