Lorsque Jellyfin, Emby ou Plex ne voient que ZimaOS-HD et pas le disque dur, le NVMe ou le RAID où se trouvent réellement vos fichiers multimédias, le problème ne vient généralement pas du fait que Docker « n’a pas l’autorisation d’accéder au NAS ». Un conteneur ne peut parcourir que les dossiers de l’hôte que ZimaOS lui mappe en tant que volumes.
C’était la correction essentielle dans le fil source de juin 2024. ETWang1991 a indiqué aux utilisateurs d’ouvrir les paramètres de l’application et d’ajouter le nouveau stockage en tant que volume. L’auteur du message a répondu que cela fonctionnait alors « à merveille », et un autre utilisateur de Jellyfin est ensuite arrivé à la même conclusion après avoir vu les captures d’écran.
Une application Docker ne voit pas l’intégralité du système de fichiers de l’hôte ZimaOS
L’isolation du conteneur est intentionnelle. Jellyfin peut voir /Media dans son conteneur uniquement si ce chemin a été mappé vers un véritable dossier de l’hôte contenant les fichiers multimédias.
L’apparition d’un disque dans Fichiers ZimaOS ne le rend pas automatiquement visible dans chaque conteneur de l’App Store.
Ouvrez les paramètres de l’application et modifiez les volumes
Choisissez le véritable dossier Media sur l’hôte
Sélectionnez le dossier de l’espace de stockage réel qui contient votre bibliothèque plutôt que de saisir un chemin racine supposé tel que /Main-Storage.
Les chemins sur l’hôte et dans le conteneur ont des rôles différents
Le chemin dans le conteneur doit être simple et stable, par exemple /media ou /Media. Dans Jellyfin, ajoutez les bibliothèques à l’aide de ce chemin dans le conteneur, et non du chemin brut sur l’hôte.
Plusieurs utilisateurs ont confirmé que le mappage des volumes était l’étape manquante
L’auteur du message a indiqué que la modification fonctionnait. Un autre utilisateur disposant d’un stockage principal RAID 5 ne voyait initialement que le disque du système d’exploitation, puis a répondu que les captures d’écran lui avaient donné l’idée : « J’ai dû ajouter les volumes à Jellyfin. »
Il s’agit d’une résolution confirmée par la source, et non d’une solution spéculative fondée sur les autorisations.
L’ajout individuel de disques était un problème d’interface en 2024
Certains participants ont eu du mal à sélectionner individuellement les disques activés ou le stockage RAID dans l’ancien sélecteur. Le personnel d’IceWhale a répondu que les disques individuels pouvaient être activés et utilisés, puis a indiqué que l’interface avait été améliorée.
Ces limitations de 2024 concernent les premières versions de ZimaOS. Les paramètres actuels de stockage et des applications de ZimaOS exposent beaucoup plus clairement le stockage géré.
ZimaOS documente désormais explicitement les chemins de stockage des applications
La documentation actuelle d’IceWhale explique désormais que les conteneurs de l’App Store conservent les données persistantes dans de vrais dossiers de l’hôte et que les mappages de volumes de chaque application peuvent être consultés et modifiés depuis ses paramètres.
Utilisez le modèle actuel des chemins d’application Docker de ZimaOS lors du mappage de Jellyfin, Emby, Plex ou d’une autre application.
L’emplacement d’AppData et celui des médias sont distincts
Les fichiers de configuration et de base de données de l’application peuvent se trouver dans l’emplacement App Data configuré, tandis que les fichiers multimédias volumineux résident sur un autre pool RAID ou HDD. Ne redirigez pas le volume de configuration de l’application vers le dossier des films et ne supposez pas que le déplacement d’AppData déplace toute la bibliothèque multimédia.
ZimaOS peut actuellement déplacer les données d’application gérées
La migration actuelle des données peut déplacer les images Docker et les données d’application Docker vers un autre espace de stockage. Cela résout un problème différent de l’ajout d’un volume multimédia : l’un détermine où l’application elle-même conserve son état persistant ; l’autre donne au conteneur accès aux médias de l’utilisateur.
Consultez le workflow actuel de migration des données d’application gérées.
Choisissez des montages de supports en lecture seule lorsque l’application n’a pas besoin de modifier les fichiers
Un serveur multimédia doit généralement lire les films et la musique, mais n’a pas nécessairement besoin de l’autorisation de supprimer ou de réorganiser la bibliothèque source. Lorsque le paquet de l’application actuel l’autorise, le mappage des médias en lecture seule réduit les dommages qu’un conteneur compromis ou mal configuré peut causer.
Les applications qui renomment, déplacent ou importent volontairement des fichiers, comme certaines solutions de téléchargement ou de gestion de photos, nécessitent un modèle différent d’autorisations en écriture.
Le mappage des volumes et les autorisations du système de fichiers sont deux vérifications distinctes
L’ajout du dossier hôte correct est la première condition requise. Le processus du conteneur doit également disposer d’autorisations suffisantes sur le système de fichiers pour lire ou écrire dans ce dossier. Si un répertoire mappé apparaît mais est vide à l’ouverture ou renvoie des erreurs d’autorisation, identifiez l’UID/GID du conteneur et le propriétaire côté hôte avant d’utiliser des autorisations trop larges. chmod 777 solutions de contournement.
Le problème de la source datant de 2024 concernait principalement l’absence de mappage de volume ; les problèmes d’autorisation ultérieurs ne doivent être diagnostiqués qu’une fois le chemin correct réellement monté.
Conservez le chemin côté conteneur entre les réinstallations
Si la bibliothèque Jellyfin a été créée à partir de /Media, en remplaçant le chemin côté conteneur par /mnt/media2 Lors d’une réinstallation, cela peut donner l’impression que la bibliothèque existante a disparu, même si les fichiers hôtes n’ont jamais été déplacés.
Conservez si possible le même chemin côté conteneur, ou mettez délibérément à jour la configuration de la bibliothèque de l’application après toute modification du mappage.
L’interface actuelle est meilleure que le sélecteur de 2024, mais la règle Docker n’a pas changé
IceWhale a reconnu dans la source que l’ancien sélecteur de stockage prêtait à confusion, puis a amélioré l’interface. La version actuelle de ZimaOS affiche désormais plus directement l’emplacement des données d’application, les chemins hôte/conteneur, la migration du stockage et l’utilisation du cache des applications.
La règle Docker sous-jacente reste la même : un conteneur ne voit que ce qui y est monté.
FAQ sur l’accès des applications au stockage
Pourquoi Files de ZimaOS peut-il voir un disque alors que Jellyfin ne le peut pas ?
Files s’exécute au niveau de l’hôte ; Jellyfin s’exécute dans un conteneur et ne voit que les volumes mappés.
L’ajout du volume a-t-il été confirmé comme fonctionnel dans le fil de discussion source ?
Oui. Plusieurs utilisateurs ont signalé que cela fonctionnait après l’ajout du volume de stockage et de médias.
Jellyfin doit-il parcourir le chemin hôte brut ?
Non. Jellyfin doit parcourir le chemin côté conteneur attribué au dossier hôte mappé.
