Solución de la comunidad

Los nuevos usuarios de ZimaOS reciben un error de «permiso denegado» en los archivos compartidos: qué comprobar

A March 2026 multi-user case where an administrator could access data but a newly created member received permission errors even after read/write access was assigned. The thread ended without a confirmed root cause.

Si se concede a un nuevo miembro de ZimaOS acceso de Lectura y escritura en la interfaz de uso compartido, pero sigue recibiendo «permiso denegado», no ejecutes inmediatamente comandos recursivos para cambiar la propiedad en todo el grupo de almacenamiento. El hilo original de marzo de 2026 probó varias teorías sobre la propiedad, realizó un restablecimiento completo y aun así no llegó a una causa raíz confirmada.

El método de resolución de problemas más fiable consiste en separar la capa de permisos de ZimaOS/Samba de la capa de propiedad subyacente de Linux. Reproduce primero el problema en una carpeta nueva pequeña, compara el acceso del administrador y del miembro, y solo después inspecciona la ruta exacta del host implicada.

El permiso del miembro parecía correcto en la interfaz

La cuenta del administrador podía acceder a los datos, mientras que una cuenta recién creada llamada Andres tenía asignado acceso de lectura y escritura, pero recibía un error de permiso al abrir archivos.

La cuenta de miembro de ZimaOS recibe un error de permiso denegado al acceder a archivos compartidos
El síntoma original era que se denegaba el acceso a una cuenta de miembro, aunque el administrador podía acceder al mismo almacenamiento.
Configuración de miembros de ZimaOS que muestra los permisos de acceso del usuario afectado
El usuario de origen ya había configurado el acceso de miembros en la interfaz de ZimaOS.

La versión actual de ZimaOS admite permisos de Samba por usuario

La documentación actual de ZimaOS distingue entre el acceso de miembros y el acceso de invitados, y permite que un administrador conceda permiso de Solo lectura o de Lectura y escritura a un recurso compartido de Samba. Un miembro con permiso de Lectura y escritura debería poder descargar, cargar, cambiar el nombre y eliminar archivos dentro del recurso compartido, siempre que el sistema de archivos subyacente sea accesible.

Configuración multiusuario actual de Samba en ZimaOS es la referencia adecuada antes de usar correcciones a nivel de shell copiadas de un hilo antiguo.

Reproduce el problema en una carpeta de prueba completamente nueva

Crea una carpeta de prueba pequeña mediante la interfaz actual de Archivos en el disco de datos previsto. Comparte solo esa carpeta con el nuevo miembro con permiso de Lectura y escritura; después, conéctate desde el cliente del miembro usando las credenciales de ese miembro.

Si la carpeta de prueba funciona, pero los directorios migrados o antiguos fallan, es probable que el problema esté relacionado con esas rutas o con su propiedad. Si la carpeta recién creada mediante la interfaz también falla, el problema es más amplio y debe tratarse como un posible problema de cuenta, Samba o permisos de ZimaOS, no como un problema de propiedad de archivos heredados.

Panel de ZimaOS para administrar Samba, utilizado para revisar el acceso a los recursos compartidos
Usa la capa de gestión de recursos compartidos para verificar qué miembro tiene acceso antes de cambiar la propiedad del sistema de archivos.

Usa la propiedad de Linux como señal de diagnóstico, no como solución a ciegas

El hilo inspeccionó los ID de usuario y la propiedad de los directorios, y encontró rutas dentro de /DATA/.media pertenecientes a distintos usuarios y grupos de Linux. Esto hizo plausible una discrepancia de propietarios en los datos migrados.

Salida del terminal que muestra la propiedad de los directorios de datos de ZimaOS durante la solución de problemas de permisos
La comunidad comparó la propiedad de los directorios después de que la configuración de permisos en la interfaz no explicara el fallo.

Un comando recursivo sugerido chown La operación produjo después muchos errores de «Operación no permitida» dentro de datos gestionados por aplicaciones. Esto advierte contra la aplicación de un único comando de cambio de propietario en árboles amplios del sistema o de AppData. Cambiar propietarios de forma recursiva puede romper contenedores o servicios que esperan UID y GID específicos.

Usa id, ls -ldy un archivo de prueba pequeño para comprender la ruta exacta que falla. No modifiques directorios de aplicaciones no relacionados.

El restablecimiento de fábrica no fue una solución confirmada

Menú de restablecimiento de ZimaOS utilizado durante la investigación de permisos
Finalmente, el usuario probó un restablecimiento en lugar de seguir modificando el árbol migrado.
Cuadro de diálogo de confirmación del restablecimiento de ZimaOS del hilo original
El restablecimiento fue un experimento del hilo, no una solución comprobada.

Después de reformatear y reinstalar, el autor siguió informando de errores de permisos del miembro. Ese resultado es importante: no recomiendes un restablecimiento destructivo como solución habitual para un problema de acceso de usuario.

La instalación nueva de ZimaOS sigue mostrando un error de permiso denegado para un miembro
La prueba con una instalación nueva no demostró que restablecer o reformatear resolviera el problema de acceso del miembro.
Configuración de acceso del miembro en la instalación nueva de ZimaOS utilizada después de la reinstalación
Los permisos del miembro se recrearon después de la reinstalación, pero el hilo aún no llegó a una causa confirmada.

Qué recopilar antes de informar del problema

Si una carpeta nueva creada mediante el ZimaOS actual sigue fallando para un miembro recién creado, registra la versión de ZimaOS, la ruta compartida, la configuración de permisos del miembro, el sistema operativo del cliente, el error exacto y si el acceso de administrador funciona. Registra también la salida de id para la cuenta correspondiente y ls -ld solo para la ruta afectada.

Esa evidencia es más útil que otro cambio general de propietario. El hilo original terminó con la comunidad considerando inesperada y digna de una investigación más profunda una reproducción mediante una instalación limpia, no con una solución de una sola línea verificada.