En résumé : le fait que ZimaOS Files voie un partage NAS ne signifie pas que toutes les applications Docker puissent y accéder
L’hôte et le conteneur ont des vues différentes du système de fichiers. ZimaOS Files peut parcourir un NAS monté sous /media/Plank-home-storage/Media/Books, tandis que Readarr, Audiobookshelf ou un autre conteneur ne voit que les chemins explicitement mappés dans ce conteneur. Liez le véritable chemin de l’hôte ZimaOS au conteneur, puis utilisez le chemin côté conteneur dans l’application.
Lisez chaque ligne de volume comme Chemin de l’hôte → Chemin du conteneur
Par exemple :
/media/Plank-home-storage/Media/Books -> /books
/DATA/Downloads -> /downloadsLe côté gauche existe sur ZimaOS. Le côté droit existe dans Readarr. Dans l’application, choisissez /books, et non le chemin de l’hôte. Les chemins des applications ZimaOS actuels expliquent cette séparation. Docker appelle ce même mécanisme montages par liaison Docker.
Vérifiez d’abord que le NAS est monté sur l’hôte
findmnt | grep -i cifs
mount | grep -i cifs
ls -la /mediaSi le partage NAS est absent ici, Docker ne peut pas non plus l’utiliser. Corrigez d’abord le montage SMB/NFS. Si Files peut le parcourir, passez au mappage du conteneur plutôt que de modifier le NAS distant.
Vérifiez ensuite que l’application peut voir le chemin du conteneur
docker exec -it READARR_CONTAINER sh
ls -la /booksSi /books est absent, vérifiez les paramètres de Volume. S’il existe mais est vide, confirmez que le chemin de l’hôte pointe vers le bon dossier monté. Si les fichiers sont visibles mais que les importations échouent, le problème concerne désormais les permissions, les noms ou les règles de bibliothèque propres à l’application.
Ne montez pas le même NAS indépendamment dans chaque application
Monter une seule fois le stockage distant au niveau de l’hôte ZimaOS, puis le monter par liaison dans les applications, fournit un emplacement unique pour gérer les identifiants et la reconnexion. Le compromis est la dépendance au montage de l’hôte. L’absence du montage distant peut devenir dangereuse si une application écrit dans un répertoire local vide portant le même chemin.
Le partage de fichiers NAS permet de séparer le stockage distant de l’accès aux applications.
Les autorisations restent importantes même lorsque le chemin est correct
touch /books/.write-test
rm /books/.write-testSi le test échoue, n’utilisez pas chmod 777 de façon permanente. Vérifiez les identifiants SMB, l’UID/GID du conteneur et le mode de lecture/écriture du volume.
Utilisez une stratégie de chemins partagés unique pour toute la pile *arr
Readarr, Sonarr, Radarr et les clients de téléchargement sont plus faciles à gérer lorsqu’ils utilisent des chemins d’hôte cohérents. Des mappages incohérents expliquent souvent pourquoi une application importe un fichier tandis qu’une autre indique que le chemin n’existe pas.
Les exigences des applications ZimaOS présentent le modèle général de stockage des applications.
Séparez les données des applications et les données multimédias
La configuration doit se trouver dans AppData. Les livres et les fichiers multimédias doivent se trouver sur le NAS ou le pool de stockage. Les téléchargements peuvent se trouver dans un troisième chemin. La migration des données de ZimaOS est utile lorsque la disposition du stockage a changé après l’installation.
N’oubliez pas que le montage NAS de l’hôte possède son propre cycle de vie SMB
Un montage bind Docker ne rend pas la connexion SMB distante plus fiable ; il expose uniquement le répertoire de l’hôte déjà monté. Les montages CIFS sous Linux expliquent la couche hôte sous-jacente au mappage du conteneur. Si le NAS distant se déconnecte, le chemin du conteneur peut rester présent alors que les fichiers attendus disparaissent ; surveillez donc le montage lui-même plutôt que l’application uniquement.
Pour les piles *arr fortement automatisées, le comportement au redémarrage est important. Vérifiez que le partage distant est monté avant de démarrer les applications qui déplacent ou renomment des fichiers ; sinon, une application peut créer des répertoires dans le système de fichiers local là où le partage réseau était censé se trouver.
FAQ
Pourquoi ZimaOS Files peut-il voir mon NAS, mais pas Readarr ?
ZimaOS Files s’exécute au niveau de l’hôte. Readarr ne voit que les répertoires explicitement montés dans son conteneur.
Dois-je saisir /DATA dans Readarr ?
Uniquement si /DATA ou un sous-dossier est réellement mappé dans le conteneur. Utilisez généralement le chemin côté conteneur, comme /books.
Que faire si l’application voit le dossier, mais ne peut pas y écrire ?
Vérifiez le mode de liaison, les identifiants SMB et l’UID/GID du conteneur.
Toutes les applications *arr peuvent-elles partager le même point de montage multimédia ?
Oui. Des mappages cohérents facilitent généralement la compréhension des importations et des liens physiques.
La configuration de l’application doit-elle se trouver sur le partage NAS ?
Conservez la configuration des conteneurs dans un dossier AppData local stable, sauf si l’application prend explicitement en charge les systèmes de fichiers réseau pour sa base de données.
