El usuario de origen tenía Syncthing funcionando para sincronizar las fotos del teléfono, pero los archivos terminaban en la unidad del sistema en lugar de en el disco de almacenamiento. Copiar una ruta desde la aplicación Archivos y pegarla directamente en Syncthing hizo que Syncthing recreara el mismo árbol de directorios dentro de su propio sistema de archivos del contenedor.
La solución final fue conceptual, no un comando mágico del sistema de archivos: Docker tiene una ruta del host y una ruta del contenedor. Syncthing debe usar la ruta visible dentro del contenedor, no la ruta sin modificar visible para CasaOS o ZimaOS.
Por qué la ruta externa se recreaba en el lugar equivocado
Si se indica a Syncthing que use una ruta que realmente no puede ver, puede crearla dentro de su propio sistema de archivos escribible o dentro de una ubicación de configuración asignada. El usuario de origen interpretó el nombre de la carpeta como una ruta del disco externo, mientras que el contenedor lo interpretó como una ruta relativa a su propio sistema de archivos.
Encontrar el punto de montaje real del host
La comunidad usó lsblk para identificar dónde había montado el sistema operativo la unidad externa. En el ejemplo del responsable, la unidad aparecía en una ruta similar a /media/devmon/...; posteriormente, las unidades del autor original aparecieron en /mnt/Storage1 y /mnt/Storage2.
Esas rutas de montaje históricas exactas son ejemplos de CasaOS/ZimaBlade y no deben tratarse como rutas universales actuales de ZimaOS.
Asignar la unidad del host a Syncthing
El responsable usó /DATA como ruta del lado de Syncthing. Una vez creada esa asignación, Syncthing debe hacer referencia a las carpetas dentro de /DATA en lugar de la ruta de montaje original del host.
El usuario introdujo inicialmente la ruta del host dentro de Syncthing
Syncthing devolvió entonces un error de permisos o de ruta porque esa ruta interna no correspondía al volumen asignado.
La ruta final que funcionaba era /DATA/Documents
El responsable explicó que, después de asignar la unidad del host a /DATA, Syncthing debería usar:
/DATA/Documentso el equivalente ~/Documents atajo cuando la carpeta de inicio de Syncthing apunta a esa ubicación de datos asignada.
El autor original volvió al día siguiente y confirmó que todo funcionaba.
El chown recursivo formaba parte del flujo de trabajo de la comunidad, no de la solución principal
El hilo también usó un chown en la unidad externa. Esto puede ser apropiado en un sistema de archivos administrado por Linux, pero cambia la propiedad en todo el destino y no era un requisito redactado por IceWhale.
No ejecutes un cambio recursivo de propiedad en un disco compartido existente hasta que sepas qué usuarios y aplicaciones dependen ya de sus permisos.
El ZimaOS actual facilita la asignación del almacenamiento de las aplicaciones
La documentación actual de ZimaOS muestra directamente las rutas del host y del contenedor en la configuración de la aplicación y recomienda establecer los datos de la aplicación en un almacenamiento administrado, en lugar de permitir que las aplicaciones llenen el disco del sistema.
Usa el modelo actual de rutas de aplicaciones de ZimaOS para volúmenes de Docker en lugar de depender de las antiguas ubicaciones de montaje de CasaOS.
El usuario de origen reinstaló Syncthing y reconstruyó la asignación
Después de que los primeros intentos siguieran siendo confusos, el autor original realizó una instalación nueva de Syncthing, volvió a añadir las unidades de almacenamiento y asignó /mnt/Storage1 en el host a /DATA dentro del contenedor. Esta nueva prueba limpia eliminó de la investigación la configuración antigua del contenedor.
Tener permisos en el host no bastó para que funcionara la ruta incorrecta del contenedor
El usuario podía conectarse por SSH a la unidad de almacenamiento y crear directorios, pero Syncthing seguía fallando cuando se le pedía usar /mnt/Storage1/Documents internamente. Ese resultado negativo es valioso: poder escribir como usuario del host no significa que el contenedor pueda ver el mismo espacio de nombres.
La visibilidad dentro del contenedor debe ser correcta antes de que ajustar los permisos pueda solucionar algo.
El ZimaOS actual debería priorizar las rutas de almacenamiento administradas
El hilo trata sobre un ZimaBlade que se envió con rutas de almacenamiento al estilo de CasaOS. El ZimaOS actual tiene un comportamiento de almacenamiento administrado diferente y una interfaz más clara para los volúmenes de las aplicaciones. En un servidor actual, usa la ruta de almacenamiento seleccionada a través de ZimaOS en lugar de asumir /mnt/Storage1 o /media/devmon existirá.
Cambia solo los permisos que la aplicación realmente necesita
Por lo general, Syncthing necesita acceso de lectura y escritura a su carpeta de sincronización. Si una carpeta asignada está visible pero no permite escribir, revisa la propiedad y los permisos de grupo de esa carpeta específica. Evita cambiar la propiedad de forma recursiva en toda una unidad de uso múltiple, a menos que hayas considerado todos los demás servicios que la utilizan.
Preguntas frecuentes sobre discos duros externos en Syncthing
¿Por qué Syncthing creó la ruta de la unidad externa dentro del disco del sistema?
La ruta del host no era la ruta que Syncthing podía ver dentro de su contenedor.
¿Qué ruta funcionó después de asignar la unidad a /DATA?
El usuario de origen lo confirmó /DATA/Documents funcionó.
¿El único arreglo fue ejecutar chown de forma recursiva?
No. Lo decisivo fue entender la diferencia entre la ruta del host y la ruta del contenedor.
