L’utilisateur source avait configuré Syncthing pour synchroniser les photos de son téléphone, mais les fichiers atterrissaient toujours sur le disque système au lieu du disque de stockage. Copier un chemin depuis l’application Fichiers et le coller directement dans Syncthing a conduit Syncthing à recréer la même arborescence de répertoires dans son propre système de fichiers de conteneur.
La solution finale était conceptuelle plutôt qu’une commande magique du système de fichiers : Docker possède un chemin côté hôte et un chemin côté conteneur. Syncthing doit utiliser le chemin visible à l’intérieur du conteneur, et non le chemin brut visible par CasaOS ou ZimaOS.
Pourquoi le chemin externe était recréé au mauvais endroit
Si Syncthing est configuré pour utiliser un chemin auquel il ne peut pas réellement accéder, il peut créer ce chemin dans son propre système de fichiers accessible en écriture ou dans un emplacement de configuration mappé. L’utilisateur source a interprété le nom du dossier comme un chemin vers un disque externe, tandis que le conteneur l’a interprété comme un chemin relatif à son propre système de fichiers.
Trouver le véritable point de montage côté hôte
La communauté a utilisé lsblk pour déterminer où le système d’exploitation avait monté le disque externe. Dans l’exemple de l’intervenant, le disque apparaissait sous un chemin similaire à /media/devmon/...; les disques de l’auteur initial sont ensuite apparus sous /mnt/Storage1 et /mnt/Storage2.
Ces chemins de montage historiques précis sont des exemples de CasaOS/ZimaBlade et ne doivent pas être considérés comme des chemins universels actuels de ZimaOS.
Mapper le disque hôte dans Syncthing
L’intervenant a utilisé /DATA comme chemin côté Syncthing. Une fois ce mappage en place, Syncthing doit faire référence aux dossiers situés sous /DATA au lieu du chemin de montage hôte d’origine.
L’utilisateur a d’abord saisi le chemin côté hôte dans Syncthing
Syncthing a alors renvoyé une erreur de chemin ou d’autorisation, car ce chemin interne ne correspondait pas au volume mappé.
Le chemin final fonctionnel était /DATA/Documents
L’intervenant a expliqué qu’après avoir mappé le disque hôte vers /DATA, Syncthing doit utiliser :
/DATA/Documentsou l’équivalent ~/Documents raccourci lorsque le dossier personnel de Syncthing pointe vers cet emplacement de données mappé.
L’auteur initial est revenu le lendemain et a confirmé que le problème était résolu.
Le chown récursif faisait partie de la procédure de la communauté, pas de la correction fondamentale
La discussion utilisait également un chown sur le disque externe. Cela peut être approprié sur un système de fichiers géré par Linux, mais cela modifie la propriété de l’ensemble de la cible et ne constituait pas une exigence formulée par IceWhale.
N’effectuez pas de changement récursif de propriété sur un disque partagé existant avant de savoir quels utilisateurs et quelles applications dépendent déjà de ses autorisations.
Avec le ZimaOS actuel, le mappage du stockage des applications est plus simple
La documentation actuelle de ZimaOS indique directement les chemins de l’hôte et du conteneur dans les paramètres de l’application et recommande de définir les données de l’application dans un stockage géré plutôt que de laisser les applications remplir le disque système.
Utilisez le modèle actuel de chemins d’application de ZimaOS pour les volumes Docker au lieu de vous fier aux anciens points de montage de CasaOS.
L’utilisateur source a réinstallé Syncthing et recréé le mappage
Après les premières tentatives qui restaient confuses, l’auteur original a effectué une nouvelle installation de Syncthing, ajouté de nouveau les disques de stockage et mappé /mnt/Storage1 sur l’hôte vers /DATA dans le conteneur. Ce nouveau test propre a retiré les anciens paramètres du conteneur du diagnostic.
Les autorisations de l’hôte seules ne suffisaient pas à faire fonctionner le mauvais chemin du conteneur
L’utilisateur pouvait se connecter en SSH au disque de stockage et créer des répertoires, mais Syncthing échouait toujours lorsqu’on lui demandait d’utiliser /mnt/Storage1/Documents en interne. Ce résultat négatif est instructif : le fait de pouvoir écrire en tant qu’utilisateur de l’hôte ne signifie pas que le conteneur peut voir le même espace de noms.
La visibilité dans le conteneur doit être correcte avant que l’ajustement des autorisations puisse résoudre quoi que ce soit.
Avec le ZimaOS actuel, privilégiez les chemins de stockage gérés
La discussion concerne un ZimaBlade livré avec des chemins de stockage de type CasaOS. Le comportement du stockage géré de ZimaOS actuel est différent, et son interface de volumes d’application est plus claire. Sur un serveur actuel, utilisez le chemin de stockage sélectionné via ZimaOS au lieu de supposer /mnt/Storage1 ou /media/devmon existera.
Ne modifier que les autorisations réellement nécessaires à l’application
Syncthing a généralement besoin d’un accès en lecture et en écriture à son dossier de synchronisation. Si un dossier monté est visible mais non inscriptible, vérifiez la propriété et les autorisations de groupe sur ce dossier précis. Évitez de modifier récursivement la propriété de l’ensemble d’un disque polyvalent, sauf après avoir pris en compte tous les autres services qui l’utilisent.
FAQ sur les disques durs externes avec Syncthing
Pourquoi Syncthing a-t-il créé le chemin du disque externe sur le disque système ?
Le chemin de l’hôte n’était pas celui que Syncthing pouvait voir à l’intérieur de son conteneur.
Quel chemin a fonctionné après le montage du disque sur /DATA ?
L’utilisateur source l’a confirmé /DATA/Documents a fonctionné.
Le chown récursif était-il la seule solution ?
Non. La compréhension décisive concernait la différence entre le chemin de l’hôte et celui du conteneur.
