¿Por qué se rompen los permisos de archivo después de mover archivos a un NAS?

Los archivos pueden funcionar normalmente en una computadora, unidad externa o carpeta de descargas y luego volverse de solo lectura, invisibles para una aplicación o inaccesibles después de ser movidos a un NAS. Eso usualmente no significa que los datos del archivo estén dañados. Significa que los archivos entraron a un nuevo sistema de archivos con un modelo diferente de propiedad y permisos.

Un movimiento entre dispositivos comúnmente se realiza como una copia seguida de la eliminación del origen. El NAS crea archivos nuevos usando la identidad SMB o NFS conectada, las ACL de la carpeta destino, valores UID y GID, umask, usuario del contenedor y reglas de creación del servidor. La forma más rápida de solucionar el problema es identificar quién creó los archivos, quién los posee ahora y qué usuario o proceso está siendo denegado.

Mover archivos a un NAS usualmente crea archivos nuevos

Arrastrar una carpeta a un NAS puede parecer un movimiento ordinario en el Explorador de Windows o Finder. Sin embargo, debajo, el disco fuente y el NAS son sistemas de archivos separados. El cliente lee los datos originales, crea nuevos objetos en el destino y elimina los originales después de que la transferencia tiene éxito.

Esto difiere de mover un archivo entre dos carpetas en el mismo sistema de archivos, donde el sistema puede solo actualizar la ubicación del archivo en el directorio. La descripción de Microsoft sobre el comportamiento de copiar y mover explica que los objetos copiados a otro volumen heredan los permisos de la nueva carpeta, mientras que un movimiento dentro del mismo volumen normalmente conserva los permisos existentes.

Esa distinción explica por qué “Cortar y Pegar” no garantiza que la propiedad, las entradas ACL o los atributos extendidos permanezcan idénticos después de una transferencia a un NAS. El sistema de destino no está simplemente reubicando el objeto original del sistema de archivos.

Las ACL de destino deciden qué heredan los archivos nuevos

Si cada archivo recién copiado recibe los mismos permisos inesperados, el directorio padre suele ser más importante que el archivo fuente. El destino puede haber heredado entradas ACL, ACL POSIX predeterminadas, banderas ACL NFSv4 o configuraciones de permisos específicas de NAS.

Por ejemplo, una carpeta compartida puede configurarse para que los archivos nuevos hereden el acceso para un grupo familiar, un grupo de medios o una cuenta SMB en particular. La ausencia de una bandera de herencia puede crear el resultado opuesto: los usuarios pueden acceder a la raíz del conjunto de datos pero no a los archivos nuevos dentro de él.

Los sistemas de permisos estilo TrueNAS distinguen entre modelos POSIX y ACLs NFSv4/SMB. El comportamiento importante es que la herencia de ACL NFSv4 y SMB puede controlar archivos y carpetas nuevos, mientras que los valores predeterminados POSIX y los límites de conjuntos de datos se comportan de forma diferente. Antes de cambiar archivos individuales, inspeccione la ACL y las banderas de herencia en la carpeta de destino.

El NAS usa la cuenta SMB conectada

Cuando una computadora Windows o macOS copia un archivo a través de SMB, el NAS normalmente no conserva la identidad local del usuario del cliente. Crea el archivo de destino como la cuenta autenticada en el recurso compartido SMB, o como una cuenta a la que se asigna esa sesión.

Por eso un archivo propiedad de un usuario de Windows en el PC de origen puede ser propiedad de kenneth , nasuser , guest , u otra identidad del lado NAS después de la transferencia. Una credencial SMB guardada también puede hacer que una computadora cree archivos bajo un propietario diferente que otra computadora.

Verifique el nombre de usuario SMB activo en lugar de asumir que se está usando el inicio de sesión del escritorio. Desconecte el recurso compartido, borre credenciales obsoletas si es necesario y vuelva a conectarse con la cuenta NAS que debería poseer o gestionar los archivos.

El acceso al recurso compartido y el acceso a archivos son capas de permisos separadas

Un usuario puede abrir el recurso compartido SMB y navegar por las carpetas, pero aún así no poder editar, renombrar o eliminar un archivo. Esto significa que el recurso compartido en red es accesible; no prueba que el sistema de archivos haya concedido la operación solicitada.

Las reglas a nivel de recurso compartido determinan si un cliente SMB o NFS puede acceder al recurso y si la conexión se presenta como solo lectura o lectura/escritura. El sistema de archivos subyacente evalúa entonces el propietario, grupo, bits de modo, entradas ACL y reglas de herencia para cada archivo y directorio.

Solucione problemas en ambas capas. Un recurso compartido marcado como lectura/escritura no puede anular una ACL del sistema de archivos que niega la escritura, y los modos permisivos del sistema de archivos no ayudan cuando la cuenta SMB está restringida por la configuración del recurso compartido.

Las ACL al estilo Windows y los modos POSIX no se corresponden perfectamente

los permisos de Windows pueden contener múltiples usuarios y grupos, entradas explícitas de permitir y denegar, banderas de herencia y derechos separados para leer, escribir, eliminar y modificar. Los bits de modo POSIX tradicionales reducen el acceso a propietario, grupo y otros.

Samba y los sistemas operativos NAS deben traducir entre esos modelos. Un panel de seguridad de Windows puede mostrar una ACL detallada aunque ls -l muestra solo una representación simplificada. Por el contrario, ejecutar chmod puede alterar los bits de modo sin reconstruir correctamente la ACL al estilo Windows que esperan los clientes SMB.

Si el conjunto de datos NAS utiliza ACLs NFSv4 o SMB, inspeccione la ACL completa a través de la interfaz NAS o un comando compatible con ACL. No asuma que un archivo que muestra rwxrwx--- cuenta toda la historia de permisos.

Las discrepancias entre UID y GID afectan a Linux, NFS y aplicaciones

Los sistemas Linux generalmente determinan la propiedad mediante IDs numéricos de usuario y grupo. El nombre de usuario es solo una etiqueta asociada a esos números.

Dos sistemas pueden mostrar un usuario llamado media mientras uno usa UID 1000 y el otro usa UID 1001. Para Linux y NFS, esas son identidades diferentes. Un archivo propiedad de UID 1000 puede ser inaccesible para una aplicación que se ejecuta como UID 1001 incluso cuando sus nombres de usuario visibles parecen idénticos.

Verifique los valores numéricos en el NAS, host, cliente y aplicación:

id media
ls -ln /ruta/a/archivos
stat /ruta/a/archivos/ejemplo.mkv

Compare los números en lugar de solo los nombres mostrados. Si varios sistemas necesitan escribir en el mismo almacenamiento, alinee los valores UID/GID requeridos o cree un grupo compartido con los permisos correctos.

SMB y NFS pueden escribir el mismo conjunto de datos como usuarios diferentes

Los problemas de permisos suelen aparecer gradualmente cuando los clientes SMB y NFS tienen acceso de escritura al mismo directorio. Los archivos subidos a través de SMB pueden pertenecer a un usuario NAS, mientras que los archivos creados a través de NFS pueden llevar un UID numérico de otro sistema.

Los dos protocolos también pueden aplicar diferentes reglas de ACL y mapeo de identidad. Como resultado, una carpeta puede contener archivos que parecen idénticos para un usuario pero tienen diferentes propietarios, grupos, máscaras o entradas heredadas.

Elija un protocolo de escritura principal cuando sea posible. Cuando SMB y NFS deben compartir un conjunto de datos, alinee los IDs numéricos, grupos compartidos, ACL predeterminadas, valores umask y comportamiento de creación antes de colocar datos de producción en él.

Los contenedores Docker añaden otra identidad de usuario

Un archivo puede ser legible a través de SMB pero no estar disponible para Plex, Jellyfin, Nextcloud, un descargador o un contenedor de respaldo. Docker puede montar la ruta correcta mientras que el proceso dentro del contenedor aún carece de permiso para leer o escribir en ella.

Un proceso de contenedor se ejecuta bajo un UID y GID propios. Si esa identidad no coincide con el propietario o un grupo permitido en la ruta NAS montada, la aplicación recibe Permiso denegado. Un montaje de volumen hace que el directorio sea visible; no omite la autorización del sistema de archivos.

Una solución común es hacer coincidir el UID y GID del contenedor con la identidad permitida para usar el volumen montado. Verifique la identidad real del proceso en lugar de confiar solo en un campo PUID o PGID mostrado en un archivo Compose:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Escribible"

Un contenedor puede crear archivos que otro no puede leer

Esto ocurre frecuentemente en pilas de automatización de medios. Un contenedor de descarga escribe correctamente un archivo completado, pero el servidor de medios no puede escanearlo, o un organizador no puede renombrarlo.

Las aplicaciones pueden usar diferentes valores UID/GID o diferentes umasks. Si el descargador crea archivos como 600, solo su propietario puede leer y escribir en ellos. Un modo como 640 permite lectura al grupo, pero solo cuando ambas aplicaciones comparten el grupo correcto.

Para directorios de aplicaciones compartidas, use un grupo propietario planificado, agregue las identidades necesarias de la aplicación a ese grupo y seleccione un umask que otorgue al grupo el acceso requerido. Arreglar solo archivos antiguos no ayudará si el descargador sigue creando archivos nuevos con modos restrictivos.

Umask y reglas de creación del servidor controlan nuevos permisos

Si los archivos antiguos funcionan pero cada archivo nuevo es inaccesible, el proceso de creación es la causa probable. Cada programa comienza con un modo de archivo solicitado, y su umask elimina permisos seleccionados antes de crear el archivo.

Samba también puede usar configuraciones como máscara de creación, máscara de directorio, forzar usuario, o forzar grupo. Las interfaces NAS pueden ocultar estos detrás de plantillas de permisos, preajustes de carpetas compartidas u opciones de herencia.

Cree un archivo de prueba a través de cada ruta: Windows SMB, macOS SMB, administrador de archivos NAS, NFS y cada contenedor relevante. Compare el propietario, grupo, modo y ACL resultantes. Esto revela rápidamente qué ruta de creación produce permisos rotos.

Diferentes herramientas de transferencia preservan diferentes metadatos

Finder, Windows Explorer, una interfaz web de NAS, cp, y rsync no garantizan resultados idénticos. Algunos preservan marcas de tiempo, otros pueden retener modos POSIX, y otros simplemente crean archivos nuevos bajo las reglas del destino.

Antes de elegir un método de migración, decida qué propiedades deben conservarse:

• Contenido de archivos y estructura de directorios
• Tiempos de modificación
• Permisos POSIX
• Propietario y grupo
• Entradas ACL
• Atributos extendidos
• Enlaces simbólicos

Para documentos familiares ordinarios o archivos multimedia, la herencia en el destino puede ser preferible a preservar cuentas de computadora de origen que no existen en el NAS. Para datos de aplicaciones, directorios home de Linux o migraciones de servidores, puede ser esencial preservar la propiedad y los metadatos ACL.

Rsync no preserva todos los atributos con un solo comando básico

Rsync es útil para migraciones controladas de NAS, pero el resultado depende de sus opciones, los privilegios del usuario que lo ejecuta y las capacidades de los sistemas de archivos de origen y destino.

El modo de archivo conserva metadatos comunes, incluidos modos, marcas de tiempo, grupos y propiedad cuando está permitido. Se requieren opciones adicionales cuando la migración debe preservar permisos, ACL y atributos extendidos con rsync. Una prueba típica de Linux a Linux puede usar:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

El -A la opción preserva ACL y -X preserva atributos extendidos cuando ambos lados los soportan. --numeric-ids debe usarse deliberadamente porque preservar un propietario numérico que no tiene una cuenta válida en el NAS puede reproducir la misma incompatibilidad que se intenta evitar.

Un destino rsync montado por SMB puede no comportarse como el sistema de archivos NAS

Ejecutar rsync desde una computadora hacia un recurso SMB montado localmente no siempre equivale a ejecutar rsync por SSH directamente contra el sistema de archivos NAS. La capa SMB puede mapear propietarios, transformar ACL o rechazar intentos de establecer atributos.

El usuario que realiza la copia SMB puede no tener permiso para asignar propiedad arbitraria, incluso cuando rsync lo solicita. El sistema de archivos de destino también puede soportar un modelo de ACL diferente al de origen.

Pruebe primero con un directorio representativo pequeño. Examine los archivos directamente en el NAS después de la transferencia, no solo a través del recurso compartido montado del cliente. Confirme la propiedad, modos, ACL, atributos extendidos y acceso de aplicaciones antes de migrar el conjunto de datos completo.

Los ajustes preestablecidos de permisos NAS pueden anular los bits de modo simples

Algunos sistemas NAS gestionan el acceso mediante plantillas de ACL del conjunto de datos y metadatos extendidos en lugar de solo los modos tradicionales de propietario/grupo/otros. Esto puede hacer que una gestión manual chmod pueden parecer exitosos mientras SMB o una aplicación continúan denegando el acceso.

Un conjunto de datos también puede estar configurado para reaplicar reglas heredadas cuando se crean nuevos archivos o cuando se editan permisos a través de la interfaz de gestión. Mezclar ACL gestionadas por GUI con cambios repetidos desde la línea de comandos puede producir un estado inconsistente.

Elija un modelo de permisos y adminístrelo de manera consistente. Si el conjunto de datos está configurado para una ACL SMB/NFSv4, use el editor de ACL del NAS o herramientas compatibles con ACL en lugar de reemplazar repetidamente la estructura con comandos de modo POSIX.

Reinstalar el NAS no necesariamente restablece los permisos de datos

Los permisos generalmente pertenecen a los archivos y al conjunto de datos del sistema de archivos, no solo a la configuración del sistema operativo NAS. Por lo tanto, reinstalar el sistema de arranque puede dejar las mismas entradas de propiedad y ACL inaccesibles en un grupo de almacenamiento importado.

Un caso de la comunidad TrueNAS ilustra cómo los permisos del sistema de archivos permanecen vinculados al grupo de almacenamiento y deben coincidir con los usuarios correctos y la configuración de acceso adecuada. También muestra el riesgo de hacer cambios recursivos grandes sin entender primero el modelo de identidad previsto.

Antes de reinstalar o reconstruir servicios, inspeccione el propietario del conjunto de datos, grupo, ACL y usuarios de la aplicación. Los datos pueden estar intactos y solo requerir que sus reglas de acceso se restauren correctamente.

Por qué chmod 777 recursivo no es una solución real

Cuando miles de archivos se vuelven inaccesibles, chmod -R 777 parece una forma rápida de restaurar el acceso. Otorga permiso de lectura, escritura y ejecución al propietario, grupo y a todas las demás identidades locales.

Eso puede exponer datos privados, permitir que servicios no relacionados modifiquen archivos, establecer permiso de ejecución en documentos ordinarios y dañar una estructura de ACL cuidadosamente heredada. Tampoco corrige el propietario incorrecto, UID de contenedor desajustado, falta de membresía en grupo o mapeo de identidad SMB roto.

Use el modelo de acceso previsto: establezca el propietario correcto y el grupo compartido, reconstruya la ACL apropiada, configure modos de directorio y archivo por separado y corrija la herencia futura y la configuración de umask. Pruebe en una carpeta pequeña antes de aplicar cambios recursivos.

Reparar permisos desde la identidad hacia afuera

Comience con el usuario o proceso denegado en lugar del comando que espera que lo solucione. Un usuario SMB humano, un servidor multimedia y un contenedor de respaldo pueden requerir diferentes niveles de acceso.

Para cada flujo de trabajo afectado, registre:

• El usuario o proceso que intenta acceder
• Su UID y GID numéricos cuando corresponda
• El protocolo o montaje utilizado
• El propietario y grupo actuales del archivo
• La ACL completa y las entradas heredadas
• El acceso realmente requerido: leer, crear, modificar o eliminar

Luego modifique solo la capa que está mal. Agregue al usuario a un grupo permitido, corrija la propiedad, repare la ACL, alinee un UID de contenedor o actualice la regla de creación. Evite otorgar acceso más amplio del que el flujo de trabajo necesita.

Siga un orden de solución de problemas en capas

Cambiar la ACL del recurso compartido, la identidad del contenedor, la exportación NFS y los modos de archivo al mismo tiempo destruye evidencia útil. Pruebe una capa de permisos a la vez.

Comience con un archivo afectado y un usuario o aplicación afectados. Una vez que ese caso pequeño funcione, cree un archivo nuevo mediante el flujo de trabajo normal y confirme que la corrección también previene que el problema regrese.

Prevenga problemas de permisos antes de una gran migración NAS

Reparar permisos en cientos de miles de archivos es mucho más difícil que probar el modelo de acceso antes de la migración. Construya una pequeña carpeta de destino con la misma ACL y configuración de aplicación planeada para el conjunto final de datos.

Copie varios tipos de archivos, directorios anidados, archivos de solo lectura, scripts ejecutables y archivos con atributos extendidos. Pruébelos desde cada ruta requerida: SMB, NFS, la interfaz NAS, software de respaldo y contenedores relevantes.

Solo comience la migración completa después de que los archivos nuevos reciban consistentemente el propietario, grupo, ACL y acceso de aplicación correctos. Mantenga una instantánea o copia de seguridad antes de aplicar cualquier cambio recursivo de propiedad o permisos a los datos existentes.

Conclusión final

Los permisos de archivo se rompen después de mover datos a un NAS porque la transferencia generalmente crea nuevos objetos en el sistema de archivos. Esos objetos están gobernados por la cuenta NAS usada para la transferencia, la ACL de destino, los valores UID/GID, la umask, el mapeo del protocolo y la identidad de la aplicación o contenedor.

No comience con chmod 777Primero responda tres preguntas: quién creó el archivo, quién lo posee ahora y a qué identidad se le niega el acceso. Luego inspeccione el acceso al recurso compartido, las ACL del sistema de archivos, la herencia, los IDs del contenedor y las reglas de creación futuras.

Una reparación exitosa debe hacer dos cosas: restaurar el acceso apropiado a los archivos existentes y asegurar que el próximo archivo copiado, descargado o creado en el NAS reciba automáticamente los permisos correctos.

Preguntas frecuentes

¿Por qué los archivos copiados heredan los permisos de la carpeta NAS?

Una transferencia a un NAS generalmente crea archivos nuevos en otro sistema de archivos. Los nuevos objetos comúnmente reciben permisos de la ACL de la carpeta de destino, las banderas de herencia y las reglas de creación del servidor.

¿Por qué puedo abrir archivos NAS por SMB pero mi contenedor Docker no puede?

La sesión SMB y el contenedor usan identidades diferentes. Verifique el UID y GID reales del contenedor, la propiedad numérica de la ruta montada, la membresía del grupo y si el montaje es de solo lectura.

¿Debo usar chmod 777 para reparar un recurso compartido NAS?

No. Otorga a cada identidad local un acceso amplio, puede dañar la herencia de ACL y no soluciona la propiedad incorrecta ni el mapeo de UID/GID. Defina los usuarios y grupos previstos, luego repare la propiedad y las ACL en consecuencia.

¿Puede rsync preservar los permisos de archivos NAS?

Puede preservar los permisos POSIX y otros metadatos cuando las opciones seleccionadas, los privilegios de ejecución y ambos sistemas de archivos los soportan. Las ACL y los atributos extendidos requieren opciones adicionales como -A y -X.

¿Por qué los archivos nuevos siguen fallando después de reparar los archivos antiguos?

La ruta de creación sigue siendo incorrecta. Verifique la ACL heredada de la carpeta de destino, la identidad SMB o NFS, la umask de la aplicación, las reglas de creación de Samba y el UID/GID del contenedor.