Solución de la comunidad

La aplicación ZimaOS no puede escribir en el almacenamiento principal: separa la propiedad de las carpetas de los permisos específicos de la aplicación

A January 2026 thread where a first community reply blamed general ZimaOS storage ownership and suggested recreating folders in Files. The original poster disproved that as a universal fix with SFTPGo and Navidrome, leading the responder to revise the diagnosis to application-specific permission and feature behavior.

El hilo original demuestra por qué «la aplicación no puede escribir en RAID» no debe considerarse de inmediato un problema de permisos de ZimaOS. La primera respuesta de la comunidad afirmaba que los contenedores de la tienda de aplicaciones normalmente tenían acceso de solo lectura fuera de su propio AppData, a menos que se creara o «tocara» una carpeta mediante Files. El autor de la publicación original hizo exactamente eso y aun así no pudo crear carpetas de SFTPGo ni eliminar música de Navidrome.

Después de esos contraejemplos, quien respondió revisó la explicación: la propiedad del sistema de archivos es solo una capa. Cada aplicación también tiene su propio usuario de contenedor, rutas internas esperadas y límites funcionales. Esa corrección posterior es la lección más fiable.

Hay tres capas de permisos diferentes

  • Almacenamiento del host de ZimaOS: la carpeta real del RAID o disco, junto con su propietario y permisos.
  • Asignación de volúmenes de Docker: si la carpeta del host está montada en el contenedor y si el montaje es de solo lectura.
  • Comportamiento de la aplicación: qué usuario utiliza la aplicación y si el software admite crear, eliminar o cambiar el nombre de archivos.

Un fallo en cualquiera de estas capas puede parecer un «permiso denegado».

Crear la carpeta en Files no fue una solución universal

La sugerencia inicial era crear o mover la carpeta de destino mediante ZimaOS Files para que se aplicara correctamente su propiedad. El autor de la publicación original creó srv/data en el RAID, indicó a SFTPGo que la utilizara y aun así recibió errores de permiso denegado.

Por lo tanto, el método de Files no puede presentarse como una solución garantizada para todas las aplicaciones.

SFTPGo necesita una ruta con permisos de escritura que coincida con su usuario de ejecución y su configuración

SFTPGo se ejecuta con sus propios permisos y reglas de carpetas virtuales/directorios principales. Una carpeta del host puede existir y ser visible, pero seguir sin permitir la escritura al proceso de SFTPGo.

En una implementación actual, comprueba conjuntamente la carpeta del host, el modo de montaje de Docker, el UID/GID del contenedor y el directorio principal o la carpeta virtual configurados para el usuario de SFTPGo.

La persona que respondió originalmente indicó que Navidrome debía tratarse como de solo lectura para la gestión de la biblioteca y que, en su contexto, no se admitía eliminar pistas desde Navidrome. Por tanto, la imposibilidad del usuario de borrar una canción no era una prueba sólida de que los permisos del RAID estuvieran dañados en general.

Gestiona los archivos de música de origen con Files u otra herramienta de administración de archivos, a menos que la versión actual específica de Navidrome documente una función compatible para modificar archivos.

Comprueba si el volumen de Docker está montado como de solo lectura

Una asignación de volumen puede utilizar explícitamente el modo de solo lectura. Si la aplicación debe modificar archivos, la carpeta del host tiene que estar asignada con permisos de lectura y escritura, y la identidad del proceso debe tener permiso de escritura en el sistema de archivos del host.

El ZimaOS actual permite inspeccionar y editar las asignaciones de volúmenes de las aplicaciones desde la configuración de la aplicación.

El ZimaOS actual hace más visibles las rutas del host y del contenedor

IceWhale documenta ahora la relación entre rutas del lado de la aplicación, como /config o /media, y las carpetas de almacenamiento reales que las respaldan.

Consulta el modelo actual de rutas de aplicaciones de ZimaOS antes de utilizar chmod/chown recursivos como primera medida.

No uses chmod 777 como atajo de diagnóstico

Los permisos de escritura excesivamente amplios pueden ocultar el problema real y exponer los datos compartidos a procesos no relacionados. Tampoco solucionan una aplicación que abre deliberadamente un volumen como de solo lectura o rechaza una ruta debido a su propia configuración.

Cambia únicamente la propiedad o los permisos de grupo mínimos que la aplicación necesite.

Una mejor secuencia de diagnóstico

  1. Confirma la carpeta exacta del host en ZimaOS.
  2. Confirma que el volumen de la aplicación asigna esa carpeta a la ruta de contenedor esperada.
  3. Comprueba si la asignación es de solo lectura.
  4. Identifica el UID/GID o el usuario con el que se ejecuta el contenedor.
  5. Verifica que esa identidad pueda escribir en la carpeta del host.
  6. Confirma que la propia aplicación admite la operación intentada.

Preguntas frecuentes sobre los permisos de almacenamiento de las aplicaciones

¿Recrear la carpeta en ZimaOS Files resolvió el caso original de SFTPGo?

No. El autor de la publicación original lo intentó y siguió recibiendo un error de permiso denegado.

¿Una carpeta del RAID con permisos de lectura se vuelve automáticamente escribible dentro de todas las aplicaciones?

No. El modo de montaje de Docker, el UID/GID del contenedor y el comportamiento de la aplicación siguen siendo importantes.

¿Debe utilizarse Navidrome como administrador de archivos de propósito general?

No. Trata la fuente de música como gestionada fuera de Navidrome, a menos que la aplicación actual admita explícitamente la modificación de archivos.