La modification manuelle de Compose a contourné les variables gérées par ZimaOS
Un nouvel utilisateur de ZimaOS a modifié manuellement le fichier Compose de Jellyfin afin de changer les chemins de stockage. Après le redémarrage, Compose a signalé que PGID, PUID, TZ et AppID n’étaient pas définis, et plusieurs mappages de périphériques matériels ne fonctionnaient pas comme prévu.
La réponse de la communauté a expliqué que ZimaOS injecte normalement ces valeurs via sa couche de gestion des applications. Modifier le fichier YAML généré en dehors de ce processus peut laisser des espaces réservés sans l’environnement que ZimaOS devait fournir.
Modifier le stockage via les paramètres et les volumes de l’application
La méthode recommandée consistait à ouvrir les paramètres de l’application Jellyfin et à y modifier les mappages de volumes, plutôt que de réécrire le fichier Compose. ZimaOS peut ainsi conserver les métadonnées de l’application, les variables d’environnement et les entrées des périphériques tout en appliquant les chemins de stockage choisis sur l’hôte.
L’auteur a ensuite confirmé que cette méthode fonctionnait. Une fois les bons chemins du disque secondaire sélectionnés dans les paramètres de l’application, Jellyfin a fonctionné correctement sans passer par la procédure Compose manuelle.
La réinstallation restaure la configuration fournie par la boutique
Si la configuration générée a déjà été largement modifiée, la réponse proposait de supprimer Jellyfin du tableau de bord, puis de le réinstaller depuis l’App Store afin de restaurer les paramètres par défaut d’origine. Les données existantes de l’application doivent être préservées à l’aide de mappages corrects des volumes hôtes avant la suppression : réinstaller un conteneur ne remplace pas la sauvegarde de sa configuration.
Une réparation manuelle reste possible uniquement si chaque variable manquante et chaque chemin de périphérique requis sont correctement définis. La discussion privilégiait l’interface des paramètres de ZimaOS, car elle réduisait le risque de perdre des valeurs gérées.
Le mappage du disque dans Proxmox constituait une complication distincte
L’auteur exécutait ZimaOS dans une machine virtuelle sous Proxmox sur Debian 13. Un disque transmis avec une commande qm set et un point de montage obsolète dans /etc/fstab ont provoqué des problèmes de mode maintenance après le redémarrage. ZimaOS nommait également le périphérique différemment de ce que l’utilisateur attendait.
Ce problème de virtualisation était distinct des variables Compose manquantes. Pour obtenir un résultat fonctionnel, il fallait à la fois un mappage stable du disque de la machine virtuelle et des chemins de volumes Jellyfin corrects dans l’interface de l’application ZimaOS.
La question ultérieure sur NTP ne faisait pas partie de la résolution du problème Jellyfin
La discussion s’est ensuite orientée vers la synchronisation de l’heure, une fois Jellyfin fonctionnel. Le comportement de NTP sur l’hôte et l’invité Proxmox n’était pas à l’origine des avertissements de Compose et devait donc être diagnostiqué séparément.
FAQ
Pourquoi PUID, PGID, TZ et AppID sont-ils devenus vides ?
Les avertissements sont apparus après que des modifications manuelles ont contourné les valeurs normalement gérées par la couche d’application de ZimaOS.
Où faut-il modifier les chemins de stockage de Jellyfin ?
La solution confirmée consistait à utiliser les paramètres de l’application Jellyfin dans ZimaOS ainsi que les contrôles des volumes.
Les périphériques matériels manquants nécessitaient-ils de nouveaux pilotes ?
La discussion n’a pas établi l’existence d’un problème de pilote. La restauration de la configuration gérée de l’application et des chemins de volumes a résolu l’installation Jellyfin de l’auteur.
