La modifica manuale di Compose ha bypassato le variabili gestite da ZimaOS
Un nuovo utente di ZimaOS ha modificato manualmente il file Compose di Jellyfin per cambiare i percorsi di archiviazione. Dopo il riavvio, Compose ha segnalato che PGID, PUID, TZ e AppID non erano impostate e diverse mappature dei dispositivi hardware non funzionavano come previsto.
La risposta della community ha spiegato che normalmente ZimaOS inserisce questi valori tramite il proprio livello di gestione delle app. Modificare il file YAML generato al di fuori di quel flusso può lasciare dei segnaposto senza l'ambiente che ZimaOS prevedeva di fornire.
Cambiare lo spazio di archiviazione tramite le impostazioni dell'app e i volumi
Il percorso consigliato consisteva nell'aprire le impostazioni dell'app Jellyfin e modificare lì le mappature dei volumi, invece di riscrivere il file Compose. In questo modo ZimaOS può mantenere i metadati dell'applicazione, le variabili d'ambiente e le voci dei dispositivi, applicando al contempo i percorsi di archiviazione host scelti.
L'autore ha in seguito confermato che questo metodo funzionava. Dopo aver selezionato i percorsi corretti dell'unità secondaria nelle impostazioni dell'app, Jellyfin funzionava correttamente senza il flusso di lavoro Compose manuale.
La reinstallazione ripristina la configurazione fornita dallo store
Se la configurazione generata è già stata modificata in modo esteso, la risposta proponeva di rimuovere Jellyfin dal dashboard e reinstallarlo dall'App Store per ripristinare le impostazioni predefinite originali. I dati esistenti dell'applicazione devono essere preservati tramite mappature corrette dei volumi host prima della rimozione; reinstallare un container non sostituisce il backup della relativa configurazione.
La riparazione manuale rimane possibile solo se ogni variabile mancante e ogni percorso dei dispositivi richiesto vengono definiti correttamente. La discussione favoriva l'interfaccia delle impostazioni di ZimaOS perché riduceva il rischio di perdere valori gestiti.
La mappatura del disco in Proxmox era una complicazione separata
L'autore eseguiva ZimaOS come macchina virtuale su Proxmox, con Debian 13. Un disco collegato tramite un comando qm set e un mount obsoleto in /etc/fstab hanno causato problemi con la modalità di manutenzione dopo il riavvio. Inoltre, ZimaOS assegnava al dispositivo un nome diverso da quello previsto dall'utente.
Questo problema di virtualizzazione era separato dalle variabili Compose mancanti. Per ottenere un risultato funzionante erano necessarie sia una mappatura stabile del disco della macchina virtuale sia percorsi corretti per i volumi di Jellyfin nell'interfaccia dell'app ZimaOS.
La successiva domanda sull'NTP non faceva parte della soluzione per Jellyfin
La discussione è passata alla sincronizzazione dell'ora dopo che Jellyfin aveva iniziato a funzionare. Il comportamento dell'NTP sull'host Proxmox e sul guest non ha causato gli avvisi di Compose, quindi deve essere analizzato separatamente.
Domande frequenti
Perché PUID, PGID, TZ e AppID erano vuote?
Gli avvisi sono comparsi dopo che le modifiche manuali hanno bypassato i valori normalmente gestiti dal livello applicativo di ZimaOS.
Dove devono essere modificati i percorsi di archiviazione di Jellyfin?
La soluzione confermata consisteva nell'utilizzare le impostazioni dell'app Jellyfin in ZimaOS e i relativi controlli dei volumi.
I dispositivi hardware mancanti richiedevano nuovi driver?
La discussione non ha stabilito che si trattasse di un problema di driver. Il ripristino della configurazione gestita dell'app e dei percorsi dei volumi ha risolto la configurazione di Jellyfin dell'autore.
