La configuration source utilisait ZimaOS comme serveur d’applications, tout en conservant l’ensemble des médias sur un NAS Unraid existant. Plex, Emby et OpenWebUI s’exécutaient sur ZimaOS et accédaient initialement correctement aux données distantes. Après environ une semaine — puis de nouveau après un redémarrage — le partage réseau a disparu de l’environnement des applications. La reconnexion dans Fichiers et le redémarrage des applications ont rétabli l’accès.
Cela met en évidence une limite d’architecture importante pour les déploiements « nœud de calcul + NAS séparé » : un emplacement réseau visible dans l’application Fichiers n’est pas automatiquement équivalent à un montage hôte durable dont tous les conteneurs Docker peuvent dépendre après un redémarrage ou un événement de reconnexion.
Les applications ont perdu leurs médias parce que le partage distant a disparu
Il n’a pas été signalé que Plex et Emby avaient subi des défaillances de base de données. Ils ont simplement perdu les chemins pointant vers les données stockées sur Unraid. Lorsque l’utilisateur a ajouté de nouveau le partage, les applications ont commencé à reconstruire leurs bibliothèques ou à les analyser de nouveau.
Cela indique un problème d’accessibilité du stockage, et non une installation Plex ou Emby corrompue.
L’accès via Fichiers et l’accès aux volumes Docker sont deux couches différentes
Fichiers dans ZimaOS peut se connecter à un stockage sur le réseau local via SMB. Cette connexion permet de parcourir et de déplacer des fichiers depuis l’interface web.
Une application Docker a besoin d’un chemin hôte qui reste disponible au démarrage du conteneur. Si le montage réseau sous-jacent disparaît ou est recréé selon un cycle de vie différent, l’application peut voir un chemin vide ou inexistant, même si Fichiers peut ensuite se reconnecter.
Les conseils concernant les UUID ne s’appliquent pas à un partage SMB classique
Une réponse suggérait d’effectuer le montage « à l’aide d’un UUID ». Un autre participant a fait remarquer à juste titre que le partage Unraid distant était connecté par IP/SMB plutôt que comme un périphérique de stockage local.
Les UUID sont utiles pour identifier les systèmes de fichiers locaux et les périphériques de stockage. Un partage SMB est identifié par le chemin du serveur et du partage réseau, les identifiants et la configuration du montage.
Une réponse de la communauté a suggéré /etc/fstab
Un autre participant a indiqué qu’un montage SMB persistant dans /etc/fstab était stable dans son cas. Il s’agit d’une administration Linux classique qui peut fonctionner, mais ce conseil provenait de la communauté et l’auteur de la publication originale n’a pas confirmé de configuration finale fonctionnelle.
Sur un système d’exploitation de type appliance, la configuration manuelle d’un montage hôte signifie également que vous êtes responsable de l’ordre de démarrage, des identifiants, du comportement lors des reconnexions et de la compatibilité avec les mises à jour.
La version actuelle de ZimaOS prend toujours en charge le stockage réseau dans Fichiers
La documentation actuelle d’IceWhale indique qu’il est possible d’ajouter un stockage réseau depuis la barre latérale de Fichiers en saisissant l’adresse IP du NAS distant et les identifiants correspondants. C’est la méthode prise en charge pour parcourir ou migrer des données depuis un autre NAS.
Utilisez le processus actuel de connexion au stockage réseau lorsque l’objectif est d’accéder aux fichiers ou de les migrer.
La discussion n’a pas établi de méthode prise en charge pour un montage persistant destiné aux applications
Aucun développeur d’IceWhale n’a fourni de procédure documentée permettant de « monter définitivement ce partage SMB pour les applications Docker », et l’auteur de la publication originale restait sceptique quant à la capacité de la connexion dans Fichiers à survivre au cycle de vie observé.
Un article fiable doit conserver ce statut non résolu plutôt que de présenter la suggestion concernant fstab de la communauté comme la solution officielle.
Pour un serveur multimédia, déterminez où se situe la limite de montage stable
Si Plex et Emby doivent récupérer automatiquement après une coupure de courant, le chemin des médias distants doit être monté avant le démarrage des conteneurs et rester stable pendant les reconnexions. Plusieurs architectures Linux permettent d’y parvenir, mais le choix exact doit être testé avec la version actuelle de ZimaOS.
Pour les installations permanentes critiques, vérifiez un redémarrage à froid, un redémarrage du NAS distant, un redémarrage du commutateur réseau et une perte temporaire du réseau avant de considérer le chemin de stockage comme prêt pour la production.
Évitez les analyses inutiles de la bibliothèque multimédia
Lorsqu’un partage multimédia disparaît temporairement, Plex ou Emby peut interpréter cette situation comme une suppression de contenu, selon les paramètres de la bibliothèque. Évitez le nettoyage automatique et destructif de la bibliothèque tant que la stabilité du montage distant n’a pas été démontrée.
FAQ sur le montage d’un NAS distant pour les applications
La reconnexion du partage dans Fichiers a-t-elle rétabli l’accès des applications ?
Les utilisateurs ont indiqué que la reconnexion du partage et le redémarrage des applications avaient rétabli l’accès.
Un partage SMB peut-il être monté à l’aide de l’UUID du système de fichiers ?
Pas au même sens qu’un disque local. SMB utilise le chemin d’un partage réseau et des identifiants.
IceWhale a-t-il publié dans cette discussion un correctif confirmé pour un montage persistant destiné aux applications Docker ?
Non. La discussion publique s’est terminée sans qu’un tel correctif soit fourni.
