The source began with a plausible stale-AppData theory, but the final post makes that explanation insufficient. Apps that had previously been removed skipped the setup form and attempted to reuse non-existent bind paths, producing Docker errors such as bind source path does not exist. A community reply suggested removing or renaming the old AppData folder so ZimaOS would treat the app as new.
The original poster then reported that this had worked once but no longer helped. More importantly, new apps being installed for the first time also started skipping the settings form and getting stuck at 100%, while installing apps through YAML still worked. That shifts the strongest suspicion from one bad app directory toward the historical App Store UI/configuration path itself.
The Docker Error Was Real but Downstream
The visible failure looked like:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]Docker was correctly rejecting a bind mount whose host-side source directory did not exist. The unanswered question was why the App Store generated/reused that path without showing the settings form that normally lets the user choose/create it.
Stale AppData Was a Community Hypothesis
gelbuilding suggested deleting or renaming /DATA/AppData/<app-name> so the store would treat the install as fresh. Another community member said they had used the same technique.
That was not an IceWhale staff diagnosis, and the OP's later test showed it was not sufficient for the broader failure.
First-Time Apps Also Skipping the Form Changes the Diagnosis
Once new apps with no prior local AppData also skipped configuration, repeatedly deleting old folders became the wrong troubleshooting loop. The user explicitly said restart + folder deletion + reinstall produced the same scenario.
YAML Installation Working Was Important Evidence
The user said apps could still be installed from YAML. That suggests Docker itself was not completely broken and narrows the historical problem toward the store's app-definition/configuration/rendering workflow.
ZimaOS 1.7 Rebuilt the App Store Architecture
ZimaOS 1.7.0 introduced App Store 2.0 with a redesigned discovery/management UI and native YAML editing/parsing. ZimaOS 1.7.1 then added more Docker/AppData/WebUI/YAML fixes.
See the current App Store 2.0 baseline.
Current Triage Order
- update to the current stable ZimaOS release;
- test one first-party/simple app that has never been installed;
- capture the exact missing host bind path;
- confirm whether the folder exists and which storage it belongs to;
- check whether YAML installation succeeds with the same intended path;
- collect App Store/container logs if the settings form still fails.
Do Not Delete AppData Blindly on Stateful Apps
An AppData folder can contain databases, configuration, keys, libraries, and user state. Renaming it is safer than deletion while testing, and important state should be backed up first.
Missing Settings Form FAQ
Did deleting old AppData permanently fix the source problem?
No. The OP said it helped once but later stopped working.
Did first-time apps also become affected?
Yes. The final source post says new apps also skipped the configuration form and got stuck.
Did YAML installation still work?
Yes. That was one of the strongest clues that the historical failure was tied to the App Store path rather than Docker being completely unavailable.
