Conclusión clave: probablemente este no sea un problema de «seguir cambiando chmod hasta que Syncthing funcione». La señal más clara es que la carpeta funciona cuando está en una ruta que Syncthing puede ver directamente, pero falla cuando un enlace simbólico cruza hacia otra unidad física. En CasaOS, eso apunta primero a las rutas montadas en el contenedor y después a los permisos de UID/GID.
«Ya configuré los permisos hasta el final… funciona cuando apunto a /DATA/AppData/, pero no cuando el enlace apunta a una unidad física diferente». Ese resultado es más útil que el error de permisos original porque aísla el fallo en la ruta de almacenamiento.
Por qué el enlace simbólico es lo primero que hay que cuestionar
Syncthing no trata un enlace simbólico como «ve al destino y sincroniza todo lo que haya allí». El comportamiento documentado de Syncthing con los enlaces simbólicos es que los enlaces simbólicos pueden sincronizarse, pero nunca se siguen. La configuración de sus carpetas también espera una ruta real y local al dispositivo: la ruta de carpeta de Syncthing es la ruta física a la carpeta del disco duro.
Eso hace sospechosa una ruta como esta:
/DATA/Documents/Syncthing/SyncFiles → enlace simbólico → /some/other/physical/driveSi Syncthing se ejecuta en Docker, el host puede resolver ese enlace, mientras que el contenedor quizá no pueda ver el destino en absoluto.
La aplicación Syncthing de CasaOS explica por qué puede desaparecer una segunda unidad
La definición oficial de Syncthing en la tienda de aplicaciones de CasaOS resulta especialmente útil en este caso. Su archivo de composición monta mediante bind dos rutas del host en el contenedor:
/DATA/AppData/$AppID/config → /config
/DATA → /DATAPuedes verificar la asignación real de volúmenes en la composición de Syncthing de CasaOS.
Eso significa que un destino disponible físicamente dentro del árbol /DATA del host también debería estar visible bajo /DATA dentro del contenedor de Syncthing. Pero si el enlace simbólico finalmente apunta a un montaje del host fuera de ese árbol, el contenedor necesita un montaje bind independiente para el destino real. Con los montajes bind de Docker, los directorios del host deben montarse explícitamente en el contenedor.
Usa esta prueba para distinguir un problema de ruta de un problema de permisos
Ejecuta las comprobaciones en este orden. No empieces con otro chmod recursivo.
1. Resuelve la ruta real en el host de CasaOS
readlink -f "/DATA/Documents/Syncthing/SyncFiles"Si el comando devuelve una ruta fuera de /DATA, has encontrado una pista importante.
2. Pregunta al contenedor de Syncthing si puede ver el mismo destino
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Después prueba el destino resuelto si se supone que debe existir dentro del contenedor. Si el host puede mostrar su contenido, pero el contenedor no, los permisos todavía no son el problema principal; falta la ruta en el espacio de nombres del contenedor.
3. Inspecciona los montajes reales del contenedor
docker inspect syncthingConsulta la Montajes sección. Deberías poder identificar el origen en el host y el destino en el contenedor de la unidad que quieres sincronizar.
La solución más limpia: monta la unidad real mediante un bind y utiliza después esa ruta del contenedor
Si la unidad externa está fuera de /DATA, expónela directamente a Syncthing en lugar de ocultarla detrás de un enlace simbólico. Conceptualmente, la entrada de Compose tiene este aspecto:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveLuego configura la ruta de la carpeta de Syncthing de forma explícita, por ejemplo:
/sync-drive/Dev FilesEsta no es una ruta mágica; elige un destino que coincida con tu configuración de Compose. Lo importante es que el contenedor reciba el directorio real del host como un volumen montado.
La imagen de Syncthing de LinuxServer utiliza el mismo modelo y documenta asignaciones independientes de datos del host al contenedor, como /path/to/data1:/data1 y /path/to/data2:/data2. Su asignación de PUID/PGID de Syncthing también explica cómo la identidad del contenedor debe coincidir con la propiedad del volumen del host.
Solo después de que el montaje sea correcto debes corregir la propiedad y los permisos
La solución de problemas original incluía una sugerencia como:
sudo chmod -R 770 /path/to/folder770 pueden ser apropiados en algunas configuraciones, pero solo ayudan si Syncthing se está ejecutando realmente como un usuario o grupo que es propietario de ese directorio o pertenece al grupo propietario. La aplicación de CasaOS pasa PUID y PGID en la imagen de LinuxServer. La propia documentación de LinuxServer indica que la propiedad de los volúmenes del host debe coincidir con el PUID/PGID configurado.
Comprueba los ID en lugar de dar por supuesto el nombre de usuario casaos es suficiente:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveSi el UID/GID numérico no coincide, cambia la propiedad o la pertenencia al grupo de forma intencionada. Evita chmod -R 777; oculta el problema real y debilita el control de acceso.
Lo que realmente indica el error “file exists”
El mensaje:
mkdir /DATA/Documents/Syncthing/SyncFiles: file existsno demuestra que el directorio final Archivos de desarrollo el directorio es el problema. Syncthing falla mientras prepara la raíz de la carpeta. Cuando una ruta principal es un enlace simbólico o se resuelve de forma diferente dentro del contenedor, la aplicación puede encontrar un objeto del sistema de archivos donde esperaba una ruta de directorio normal.
Por lo tanto, el diagnóstico más rápido no consiste en eliminar y volver a crear el mismo directorio. Consiste en comparar:
- la ruta resuelta del host;
- la ruta visible dentro del contenedor;
- los montajes bind del contenedor;
- el PUID/PGID numérico con la propiedad del destino.
Como referencia básica limpia, la configuración de Syncthing en CasaOS muestra un flujo normal de sincronización con la misma ruta antes de personalizarlo para varias unidades. La plataforma de aplicaciones de ZimaOS resulta útil al comparar herramientas alternativas de copia de seguridad o sincronización de archivos. Si el objetivo final es consolidar varias unidades físicas en lugar de conectarlas mediante enlaces simbólicos, ZimaCube 2 es la opción de hardware centrada en el almacenamiento.
Preguntas frecuentes
¿Debería resolver esto cambiando el propietario de root a casaos?
No por sí solo. La propiedad solo importa después de que el contenedor pueda ver la ruta de destino real. Verifica primero el montaje bind y los valores numéricos de PUID/PGID.
¿Por qué funciona una ruta directa mientras que falla el enlace simbólico a otra unidad?
Una ruta directa bajo un directorio montado en el contenedor existe en ambos sistemas de archivos. Un enlace simbólico puede resolverse a una ubicación del host que nunca se montó en el contenedor, por lo que Syncthing queda con una ruta que no puede recorrer.
¿Syncthing sigue los enlaces simbólicos para sincronizar el directorio de destino?
No. La documentación de Syncthing indica que los enlaces simbólicos nunca se siguen. Usa una ruta de carpeta real visible para el proceso de Syncthing.
¿Qué debería cambiar primero?
Resuelve el enlace simbólico, inspecciona los montajes del contenedor de Syncthing y monta mediante bind el directorio real de la unidad externa. Después, verifica PUID/PGID y los permisos.
