Källan började med en plausibel teori om föråldrade AppData, men det slutliga inlägget gör den förklaringen otillräcklig. Appar som tidigare hade tagits bort hoppade över konfigurationsformuläret och försökte återanvända icke-existerande bind-sökvägar, vilket ledde till Docker-fel som bind source path does not exist. Ett svar från communityn föreslog att ta bort eller byta namn på den gamla AppData-mappen så att ZimaOS skulle behandla appen som ny.
Den ursprungliga skribenten rapporterade sedan att detta hade fungerat en gång men inte längre hjälpte. Ännu viktigare var att nya appar som installerades för första gången också började hoppa över inställningsformuläret och fastna på 100 %, medan installation av appar via YAML fortfarande fungerade. Det förskjuter den starkaste misstanken från en felaktig appkatalog till själva den historiska sökvägen för App Store-gränssnittet och konfigurationen.
Docker-felet var verkligt men ett följdfel
Det synliga felet såg ut så här:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]Docker avvisade korrekt en bind-montering vars källkatalog på värddatorn inte fanns. Den obesvarade frågan var varför App Store genererade eller återanvände den sökvägen utan att visa inställningsformuläret som normalt låter användaren välja eller skapa den.
Föråldrade AppData var en hypotes från communityn
gelbuilding föreslog att /DATA/AppData/<app-name> skulle tas bort eller döpas om så att butiken skulle behandla installationen som ny. En annan community-medlem sade att de hade använt samma metod.
Det var inte en diagnos från IceWhale-personal, och OP:s senare test visade att det inte räckte för det mer omfattande felet.
Att appar som installerades för första gången också hoppade över formuläret förändrar diagnosen
När nya appar utan tidigare lokal AppData också hoppade över konfigurationen blev det fel felsökningsmetod att fortsätta ta bort gamla mappar. Användaren sade uttryckligen att omstart + borttagning av mappen + ominstallation gav samma resultat.
Att YAML-installation fungerade var viktiga bevis
Användaren sade att appar fortfarande kunde installeras från YAML. Det tyder på att Docker inte var helt trasigt och begränsar den historiska problemkällan till butikens arbetsflöde för appdefinition, konfiguration och rendering.
ZimaOS 1.7 byggde om App Store-arkitekturen
ZimaOS 1.7.0 introducerade App Store 2.0 med ett omdesignat gränssnitt för upptäckt och hantering samt inbyggd redigering och parsning av YAML. ZimaOS 1.7.1 lade därefter till fler korrigeringar för Docker, AppData, WebUI och YAML.
Se den aktuella grunden för App Store 2.0.
Aktuell felsökningsordning
- uppdatera till den aktuella stabila versionen av ZimaOS;
- testa en enkel app från förstapartskällan som aldrig har installerats;
- notera den exakta saknade bind-sökvägen på värddatorn;
- bekräfta om mappen finns och vilken lagringsenhet den tillhör;
- kontrollera om YAML-installation lyckas med samma avsedda sökväg;
- samla in loggar från App Store och containern om inställningsformuläret fortfarande inte fungerar.
Ta inte bort AppData för tillståndsbevarande appar utan eftertanke
En AppData-mapp kan innehålla databaser, konfiguration, nycklar, bibliotek och användardata. Att byta namn på den är säkrare än att ta bort den under testning, och viktig data bör säkerhetskopieras först.
Vanliga frågor om saknade inställningsformulär
Löste borttagning av gammal AppData det ursprungliga problemet permanent?
Nej. OP sade att det hjälpte en gång men senare slutade fungera.
Påverkades appar som installerades för första gången också?
Ja. Det slutliga inlägget i källan säger att nya appar också hoppade över konfigurationsformuläret och fastnade.
Fungerade YAML-installation fortfarande?
Ja. Det var en av de starkaste ledtrådarna till att det historiska felet var kopplat till App Store-sökvägen, snarare än att Docker var helt otillgängligt.
