De bron begon met een plausibele theorie over verouderde AppData, maar de uiteindelijke post maakt die verklaring ontoereikend. Apps die eerder waren verwijderd, sloegen het configuratieformulier over en probeerden niet-bestaande bindpaden opnieuw te gebruiken, wat Docker-fouten opleverde zoals bind source path does not exist. Een reactie uit de community stelde voor de oude AppData-map te verwijderen of een andere naam te geven, zodat ZimaOS de app als nieuw zou behandelen.
De oorspronkelijke poster meldde vervolgens dat dit één keer had gewerkt, maar later niet meer hielp. Belangrijker nog: ook nieuwe apps die voor het eerst werden geïnstalleerd, begonnen het instellingenformulier over te slaan en bleven steken op 100%, terwijl het installeren van apps via YAML nog steeds werkte. Daardoor verschuift de sterkste verdenking van één defecte appmap naar de historische UI-/configuratieprocedure van de App Store zelf.
De Docker-fout was echt, maar een gevolg
De zichtbare fout zag er als volgt uit:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]Docker wees terecht een bind-mount af waarvan de bronmap op de host niet bestond. De onbeantwoorde vraag was waarom de App Store dat pad genereerde of opnieuw gebruikte zonder het instellingenformulier te tonen, waarmee de gebruiker het normaal kan kiezen of aanmaken.
Verouderde AppData was een hypothese uit de community
gelbuilding stelde voor /DATA/AppData/<app-name> te verwijderen of een andere naam te geven, zodat de store de installatie als nieuw zou behandelen. Een ander communitylid zei dezelfde techniek te hebben gebruikt.
Dit was geen diagnose van IceWhale-medewerkers, en de latere test van de oorspronkelijke poster liet zien dat dit niet voldoende was voor het bredere probleem.
Dat ook apps bij de eerste installatie het formulier overslaan, verandert de diagnose
Toen ook nieuwe apps zonder eerdere lokale AppData de configuratie oversloegen, werd het herhaaldelijk verwijderen van oude mappen de verkeerde probleemoplossingslus. De gebruiker zei expliciet dat opnieuw opstarten, de map verwijderen en opnieuw installeren tot hetzelfde scenario leidde.
Dat de installatie via YAML werkte, was belangrijk bewijs
De gebruiker zei dat apps nog steeds vanuit YAML konden worden geïnstalleerd. Dat wijst erop dat Docker zelf niet volledig defect was en verlegt de historische oorzaak naar de workflow voor appdefinities, configuratie of weergave van de store.
ZimaOS 1.7 heeft de architectuur van de App Store vernieuwd
ZimaOS 1.7.0 introduceerde App Store 2.0 met een vernieuwde interface voor ontdekken en beheren, evenals native bewerking en parsing van YAML. ZimaOS 1.7.1 voegde vervolgens meer oplossingen toe voor Docker, AppData, WebUI en YAML.
Zie de huidige basis van App Store 2.0.
Huidige volgorde voor probleemoplossing
- werk ZimaOS bij naar de huidige stabiele release;
- test één eenvoudige app van de eerste partij die nog nooit is geïnstalleerd;
- leg het exacte ontbrekende bindpad op de host vast;
- controleer of de map bestaat en bij welke opslag deze hoort;
- controleer of de installatie via YAML met hetzelfde beoogde pad slaagt;
- verzamel de logs van de App Store en containers als het instellingenformulier nog steeds niet werkt.
Verwijder AppData van apps met persistente gegevens niet zomaar
Een AppData-map kan databases, configuratie, sleutels, bibliotheken en gebruikersgegevens bevatten. Tijdens het testen is het veiliger de map een andere naam te geven dan deze te verwijderen; maak eerst een back-up van belangrijke gegevens.
Veelgestelde vragen over een ontbrekend instellingenformulier
Heeft het verwijderen van oude AppData het oorspronkelijke probleem permanent opgelost?
Nee. De oorspronkelijke poster zei dat het één keer hielp, maar later niet meer werkte.
Werden ook apps bij de eerste installatie getroffen?
Ja. De laatste bronpost zegt dat nieuwe apps het configuratieformulier eveneens oversloegen en vastliepen.
Werkte de installatie via YAML nog steeds?
Ja. Dat was een van de sterkste aanwijzingen dat de historische fout verband hield met de App Store-procedure en niet met het volledig onbeschikbaar zijn van Docker.
