Le problème initial était plus dangereux qu’un chemin qui disparaît. Après un redémarrage, SABnzbd pouvait démarrer avant que le partage SMB Synology ne soit effectivement monté. Le conteneur voyait toujours un répertoire au chemin hôte attendu : un téléchargement pouvait donc se terminer et sembler avoir été déplacé correctement, alors qu’il était en réalité enregistré sur le stockage local de ZimaOS au lieu du NAS distant.
La communauté a finalement mis au point une solution manuelle fonctionnelle avec CIFS/fstab, et l’auteur du message original a confirmé que le montage persistait après un redémarrage. Mais elle a également démontré le risque : une entrée fstab invalide pouvait empêcher un démarrage normal, et un point de montage contenant un espace non échappé pouvait interrompre la configuration. Considérez ces commandes comme une procédure d’administration communautaire confirmée par la source, et non comme la procédure officielle actuelle de ZimaOS pour le stockage réseau.
Le problème central venait du moment du montage
Le chemin source ressemblait à ceci :
/media/192.168.2.125/MoviesAprès le redémarrage, le montage SMB n’était pas prêt lorsque SABnzbd a démarré. Le fait d’ajouter à nouveau le même volume une fois le système stabilisé permettait de résoudre le problème, ce qui indique fortement un problème de synchronisation ou d’ordre de démarrage, plutôt qu’un changement d’identifiant de montage.
Un montage distant absent peut devenir un piège sous forme de répertoire local
Si Docker reçoit le chemin d’un répertoire hôte qui existe localement alors que le système de fichiers distant est absent, l’application peut écrire dans ce répertoire local. Le journal peut tout de même indiquer que le fichier a été déplacé vers /movies, alors qu’aucun fichier n’apparaît sur le Synology.
Avant de lancer des téléchargements volumineux, vérifiez que le système de fichiers distant attendu est réellement monté, et pas seulement que le répertoire du point de montage existe.
La communauté a déplacé le montage vers un chemin /DATA stable
La conception proposée consistait à monter le partage SMB dans un chemin local stable, par exemple :
/DATA/Media/Moviespuis à mapper ce chemin hôte stable dans SABnzbd. Le chemin du conteneur reste ainsi prévisible, tandis que le système de fichiers distant est géré au niveau de l’hôte.
L’utilisateur source a confirmé que /etc/fstab persistait après un redémarrage
L’exemple de la communauté utilisait des options CIFS comprenant _netdev, une version spécifique du protocole SMB ainsi que des valeurs UID/GID/mode. L’utilisateur a indiqué que l’entrée fstab persistait et fonctionnait après un redémarrage.
Ne copiez pas directement les identifiants dans un fichier de configuration lisible par tous sans envisager l’utilisation d’un fichier d’identifiants protégé.
nofail est devenu essentiel après qu’une entrée incorrecte a bloqué le démarrage
L’utilisateur source a découvert qu’un montage invalide ou indisponible pouvait perturber le démarrage. La réponse recommandait nofail afin que ZimaOS puisse continuer à démarrer si le NAS distant était indisponible.
_netdev indique également au système de montage qu’il s’agit d’une ressource dépendante du réseau.
Les espaces dans les points de montage doivent être gérés correctement
Une deuxième entrée fstab a échoué parce que le point de montage contenait TV Shows. Dans fstab, les espaces séparent les champs : un espace doit donc être échappé correctement ou évité en utilisant un répertoire plus simple, tel que TV_Shows.
L’auteur du message original a ensuite utilisé avec succès un dossier distinct sans espace.
Testez toujours avec mount -a avant de redémarrer
L’étape la plus sûre indiquée dans la source était la suivante :
sudo mount -aSi la commande renvoie une erreur, corrigez la syntaxe ou le chemin dans fstab avant de redémarrer. Vérifiez également que le système de fichiers monté contient bien les fichiers distants attendus.
Privilégiez le stockage réseau actuel de ZimaOS lorsqu’il répond à votre besoin
La version actuelle de ZimaOS peut se connecter à un stockage SMB/LAN via les workflows Fichiers/Stockage réseau. Utilisez d’abord l’interface gérée lorsqu’elle fournit le comportement de persistance et d’ordre de démarrage requis par votre application.
Consultez le workflow actuel de connexion SMB Synology.
Un conteneur réellement robuste ne doit pas écrire avant d’avoir vérifié le montage distant
Même avec fstab, un NAS réseau peut être hors ligne ultérieurement. Pour les pipelines importants de téléchargement ou d’importation, ajoutez une vérification de santé ou de démarrage, ou adoptez une procédure opérationnelle confirmant que la cible distante est montée avant que SABnzbd ne traite les tâches.
FAQ sur le montage SMB de SABnzbd
L’origine a-t-elle prouvé que l’identifiant du montage SMB changeait après un redémarrage ?
Non. Les éléments disponibles confirmaient plutôt un problème de synchronisation du montage.
Le fichier fstab persistait-il pour l’utilisateur source ?
Oui, mais des entrées mal formées ou indisponibles ont également provoqué des problèmes de démarrage jusqu’à leur correction.
Pourquoi un téléchargement peut-il sembler réussi alors qu’aucun fichier n’apparaît sur le Synology ?
L’application peut écrire dans le répertoire local du point de montage lorsque le système de fichiers SMB distant n’est pas réellement monté.
