Solution communautaire

Les applications Docker de ZimaOS perdent un NAS SMB après un redémarrage : comment résoudre le problème

Plex and Radarr lost access to a Synology SMB share after each reboot until the same ZimaOS folder mapping was manually reselected.

Si Plex, Radarr, Sonarr ou une autre application Docker perd l’accès à un NAS SMB distant après chaque redémarrage de ZimaOS, vérifiez le montage de l’hôte avant de modifier l’application. Le conteneur ne peut voir un partage réseau que si ZimaOS l’a monté correctement et que le chemin de liaison Docker pointe toujours vers cet emplacement monté.

Un cas rapporté par la communauté concernant un partage Synology a été résolu chaque fois que l’utilisateur sélectionnait à nouveau le même dossier dans le sélecteur de chemins de Docker Compose. Cela suggère fortement un problème de persistance du montage ou du chemin, mais l’explication du forum selon laquelle ZimaOS générait toujours un nouvel identifiant de montage interne relevait du raisonnement de la communauté et ne constituait pas une cause racine confirmée par IceWhale. Un bon guide doit donc dépanner séparément le montage, le chemin et l’ordre de démarrage.

Commencez par vérifier si le partage SMB est monté après un redémarrage

Avant d’ouvrir Plex ou Radarr, ouvrez Fichiers dans ZimaOS et parcourez le partage du NAS distant. Si le partage lui-même est indisponible, l’application Docker n’est pas le premier problème à résoudre.

Si le partage est absent

Vérifiez que le NAS distant est en ligne, que son adresse IP ou son nom d’hôte est toujours résolu, que SMB est activé et que les identifiants enregistrés restent valides. Reconnectez le partage via le processus de stockage réseau de ZimaOS si nécessaire.

Si le partage est visible dans Fichiers

Passez ensuite au mappage Docker. Le montage de l’hôte existe, mais l’application peut toujours faire référence à un chemin obsolète ou indisponible.

Utilisez le stockage réseau de ZimaOS plutôt qu’une entrée fstab écrite manuellement

L’utilisateur envisageait de modifier /etc/fstab. Ce n’est pas la meilleure première solution sur un système d’exploitation de type appliance qui gère déjà le stockage réseau dans son interface.

La documentation actuelle de ZimaOS présente l’accès SMB à un autre NAS dans le cadre de ses processus de migration et de stockage réseau. Utilisez d’abord cette méthode gérée afin que ZimaOS puisse gérer les identifiants et l’état du montage de manière cohérente.

Le guide de migration des NAS avec ZimaOS fournit la référence actuelle.

Vérifiez le chemin hôte Docker, pas uniquement le chemin du conteneur

Les mappages de volumes Docker comportent deux côtés :

  • chemin hôte : emplacement où ZimaOS voit le dossier Synology monté ;
  • chemin du conteneur : chemin stable que Plex, Radarr ou Sonarr voit à l’intérieur du conteneur.

Si le côté hôte n’est plus valide après le redémarrage, le chemin du conteneur peut tout de même sembler correct dans l’interface de l’application, tout en pointant vers un emplacement inutilisable.

Le guide des chemins Docker de ZimaOS actuel explique cette distinction.

Sélectionnez à nouveau le dossier une fois comme test de diagnostic

Si le partage distant est visible dans Fichiers, mais que l’application ne peut pas y accéder, ouvrez la configuration de l’application ou de Compose et sélectionnez à nouveau le dossier hôte à l’aide du sélecteur de chemin de ZimaOS.

Si l’accès revient immédiatement sans modifier les identifiants ni les chemins des conteneurs, cela indique fortement que le problème se situe entre le montage géré et la liaison de montage Docker.

Vérifiez l’ordre de démarrage après chaque redémarrage

Le stockage SMB distant dépend du réseau, du DNS ou de l’accessibilité de l’adresse IP, de l’authentification et de la disponibilité du NAS. Les conteneurs Docker peuvent démarrer plus vite que le montage distant ne devient disponible.

Test simple

  1. redémarrez ZimaOS ;
  2. attendez que le partage distant soit accessible dans Fichiers ;
  3. redémarrez uniquement l’application Docker concernée ;
  4. vérifiez si les fichiers multimédias ou les téléchargements réapparaissent.

Si cela fonctionne de manière fiable, le chemin est peut-être stable et le véritable problème vient peut-être du moment du démarrage plutôt que d’identifiants de montage qui changent.

Vérifiez les autorisations sur les deux systèmes

Le compte Synology utilisé pour le montage SMB doit avoir accès aux dossiers multimédias. Ensuite, le montage ZimaOS doit être accessible au processus Docker. Enfin, l’application doit utiliser le chemin correct dans le conteneur.

Les problèmes d’autorisation peuvent ressembler à un montage manquant. Vérifiez donc séparément « autorisation refusée » et « chemin introuvable » ou « aucun fichier de ce type ».

Pourquoi les modifications manuelles de fstab peuvent compliquer la récupération

Un montage personnalisé peut introduire des fichiers d’identifiants, des dépendances au démarrage, des options de temporisation et des comportements en cas d’échec que ZimaOS ne gère pas dans son interface. Si ce montage personnalisé échoue au démarrage, les applications peuvent tout de même démarrer sur un répertoire vide.

Utiliser fstab uniquement lorsque le flux de travail du stockage réseau géré ne peut pas répondre à une exigence et que vous êtes prêt à maintenir le montage entre les mises à jour.

Comment rendre les applications multimédias plus résilientes

  • Utilisez une adresse IP stable du NAS ou un nom DNS local fiable.
  • Conservez le partage distant configuré via le stockage réseau.
  • Mappez un dossier stable de l’hôte dans le conteneur.
  • Utilisez systématiquement le même chemin dans le conteneur pour Radarr, Sonarr, les clients de téléchargement et les serveurs multimédias.
  • Après les mises à jour ou les changements de stockage, vérifiez le montage avant de modifier les bibliothèques des applications.

Le guide de dépannage du réseau local aide à déterminer si la panne commence au niveau du réseau, tandis que les bases des chemins Docker fournissent le contexte Docker.

FAQ

Pourquoi mes applications Docker perdent-elles un partage Synology après le redémarrage de ZimaOS ?

Les causes les plus probables sont l’absence de remontage du partage SMB, l’utilisation par l’application d’un ancien chemin sur l’hôte ou le démarrage du conteneur avant que le partage distant soit prêt. Testez ces causes séparément.

Dois-je modifier /etc/fstab ?

Pas comme première solution. Privilégiez le stockage réseau de ZimaOS afin que le système gère le partage. Les montages manuels ajoutent de la maintenance et complexifient l’ordre de démarrage.

Pourquoi le fait de sélectionner à nouveau le même dossier corrige-t-il le problème de l’application ?

Cela actualise la liaison de montage côté hôte. C’est un signe de problème de montage ou de chemin, même lorsque le nom du dossier visible n’a pas changé.

Puis-je utiliser un partage SMB distant pour Plex et les applications Arr ?

Oui, à condition que ZimaOS le monte de manière fiable, que les autorisations soient correctes et que tous les conteneurs utilisent des chemins cohérents sur l’hôte et dans le conteneur.