Se PeaNUT continua a rilevare il tuo UPS dopo un riavvio di ZimaOS, ma le impostazioni salvate scompaiono, il problema riguarda solitamente la persistenza e non la connettività dell'UPS. La directory di configurazione deve essere mappata su uno spazio di archiviazione persistente di ZimaOS e il container deve poter scrivere in tale directory.
La discussione del forum di marzo 2026 ha confermato una soluzione per la build di PeaNUT installata all'epoca: mappare una cartella host persistente su /app/config. Da allora, la documentazione upstream attuale di PeaNUT ha standardizzato la configurazione persistente in /config; per le nuove installazioni è quindi consigliabile seguire il percorso attuale invece di copiare alla cieca il vecchio percorso del container.
Cosa ha effettivamente dimostrato la soluzione del forum
L'autore originale del post ha riferito che tutte le impostazioni di PeaNUT scomparivano dopo ogni riavvio di ZimaOS, anche se Home Assistant continuava a ricevere i dati dell'UPS. Un membro della community ha esaminato il pacchetto e ha suggerito di modificare il mapping del volume, in modo che una cartella host all'interno dei dati delle app di ZimaOS fosse montata su /app/config. L'autore originale ha risposto che la soluzione “ha funzionato”, rendendola una soluzione verificata per quella specifica versione del pacchetto.
Questo risultato non significa che /app/config sia oggi il percorso corretto per ogni immagine di PeaNUT. I percorsi dei container fanno parte del contratto dell'immagine e possono cambiare tra una build e l'altra.
Per le build attuali di PeaNUT, rendi persistente /config
La documentazione Docker attuale di PeaNUT usa /config per le impostazioni persistenti. L'immagine attuale prevede inoltre che questa directory sia scrivibile dall'utente del servizio, normalmente con UID/GID 1000:1000.
In ZimaOS, mappa una directory host persistente, ad esempio una cartella dei dati delle app, su /config, quindi riavvia il container e apporta una modifica innocua alle impostazioni. Riavvia nuovamente il sistema e verifica che la modifica sia rimasta. Lo stesso principio di persistenza è illustrato nella guida alla migrazione dei dati delle app di ZimaOS.
Controlla i permessi di scrittura prima di modificare nuovamente i percorsi
Se il mapping è corretto ma le impostazioni continuano a essere ripristinate, controlla nei log di PeaNUT la presenza di errori di autorizzazione. Il codice upstream attuale segnala esplicitamente quando /config non è scrivibile. Non dare per scontato che l'aggiunta di variabili d'ambiente PUID o PGID non supportate risolva il problema dell'immagine; le indicazioni upstream attuali si concentrano invece sul rendere la directory host scrivibile dall'utente effettivo del servizio del container.
Il forum di discussione upstream di PeaNUT è utile quando un'immagine attuale genera errori specifici relativi ai permessi.
Perché docker exec potrebbe non funzionare
La discussione originale mostrava inoltre che docker exec -it PeaNUT sh non funzionava perché quell'immagine di PeaNUT non conteneva una shell. Questo non dimostra che il container sia danneggiato. Le immagini minimali possono omettere intenzionalmente sh o bash.
Inizia dai log del container e dal mapping dei volumi configurato. Per una panoramica più ampia sui fondamenti della persistenza dei container, la guida introduttiva alle app Docker di ZimaOS spiega perché i dati montati dall'host sopravvivono alla ricreazione e ai riavvii del container.
In sintesi
La vecchia soluzione della community era valida per il pacchetto PeaNUT utilizzato a marzo 2026, ma le build attuali di PeaNUT indicano /config come directory persistente. Usa il percorso del container documentato dall'immagine installata, assicurati che la cartella host sia scrivibile e verifica la persistenza con un riavvio prima di modificare qualsiasi altra cosa.
