La fonte iniziava con una plausibile ipotesi relativa a dati AppData obsoleti, ma il post finale rende questa spiegazione insufficiente. Le app che erano state precedentemente rimosse saltavano il modulo di configurazione e tentavano di riutilizzare percorsi bind inesistenti, producendo errori Docker come bind source path does not exist. Una risposta della community suggeriva di rimuovere o rinominare la vecchia cartella AppData, così ZimaOS avrebbe trattato l’app come nuova.
L’autore del post originale ha poi riferito che questa soluzione aveva funzionato una volta, ma non era più d’aiuto. Ancora più importante, anche le nuove app installate per la prima volta hanno iniziato a saltare il modulo delle impostazioni e a bloccarsi al 100%, mentre l’installazione delle app tramite YAML continuava a funzionare. Ciò sposta il sospetto principale da una singola directory dell’app danneggiata al percorso storico dell’interfaccia e della configurazione dell’App Store.
L’errore Docker era reale, ma secondario
Il problema visibile era simile a questo:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]Docker rifiutava correttamente un bind mount il cui percorso sorgente sul sistema host non esisteva. La domanda rimasta senza risposta era perché l’App Store generasse o riutilizzasse quel percorso senza mostrare il modulo delle impostazioni, che normalmente consente all’utente di sceglierlo o crearlo.
AppData obsoleti erano un’ipotesi della community
gelbuilding ha suggerito di eliminare o rinominare /DATA/AppData/<app-name>, in modo che lo store considerasse l’installazione come una nuova installazione. Un altro membro della community ha affermato di aver utilizzato la stessa tecnica.
Non si trattava di una diagnosi dello staff di IceWhale e il test successivo dell’autore del post ha dimostrato che non era sufficiente a risolvere il problema più ampio.
Il fatto che anche le app installate per la prima volta saltassero il modulo cambia la diagnosi
Una volta constatato che anche le nuove app, prive di precedenti dati AppData locali, saltavano la configurazione, continuare a eliminare le vecchie cartelle diventava un ciclo di risoluzione errato. L’utente ha dichiarato esplicitamente che riavvio, eliminazione della cartella e reinstallazione producevano lo stesso risultato.
Il corretto funzionamento dell’installazione YAML era un indizio importante
L’utente ha detto che le app potevano ancora essere installate tramite YAML. Ciò suggerisce che Docker non fosse completamente guasto e restringe il problema storico al flusso di definizione, configurazione o rendering delle app nello store.
ZimaOS 1.7 ha ricostruito l’architettura dell’App Store
ZimaOS 1.7.0 ha introdotto App Store 2.0, con un’interfaccia riprogettata per la scoperta e la gestione delle app e il supporto nativo alla modifica e all’analisi dei file YAML. ZimaOS 1.7.1 ha poi aggiunto ulteriori correzioni per Docker, AppData, WebUI e YAML.
Consulta la baseline attuale di App Store 2.0.
Ordine attuale delle verifiche
- aggiorna alla versione stabile attuale di ZimaOS;
- prova un’app ufficiale e semplice che non sia mai stata installata;
- acquisisci il percorso bind mancante esatto sul sistema host;
- verifica se la cartella esiste e a quale unità di archiviazione appartiene;
- controlla se l’installazione YAML riesce utilizzando lo stesso percorso previsto;
- raccogli i log dell’App Store e dei container se il modulo delle impostazioni continua a non funzionare.
Non eliminare AppData alla cieca nelle app che conservano dati
Una cartella AppData può contenere database, configurazioni, chiavi, librerie e dati dell’utente. Durante i test è più sicuro rinominarla anziché eliminarla, e prima è consigliabile eseguire un backup dei dati importanti.
Domande frequenti sul modulo delle impostazioni mancante
L’eliminazione dei vecchi AppData ha risolto definitivamente il problema originale?
No. L’autore del post ha detto che aveva funzionato una volta, ma in seguito aveva smesso di funzionare.
Anche le app installate per la prima volta sono state interessate?
Sì. Il post finale della fonte afferma che anche le nuove app saltavano il modulo di configurazione e si bloccavano.
L’installazione YAML continuava a funzionare?
Sì. Questo era uno degli indizi più forti del fatto che il problema storico fosse legato al percorso dell’App Store, anziché a un’indisponibilità completa di Docker.
