¿Cómo solucionar la falla de diseño NTFS Move / Copy?

Como cualquiera que se ha ocupado de permisos de servidor de archivos es consciente, NTFS tiene una característica de diseño interesante / defecto conocido como el problema Mover / Copiar.

Como se explica en este artículo de KB de MS , los permisos de una carpeta o archivo no heredan automáticamente del padre si la carpeta se mueve y la fuente y el destino están en el mismo volumen NTFS. Los permisos se heredan si la carpeta se copia o si el origen y el destino están en volúmenes diferentes.

Aquí está un ejemplo rápido:

Tiene dos carpetas compartidas en el mismo volumen NTFS denominado "Técnicos" y "Administradores". El grupo Técnicos tiene acceso RW a la carpeta Técnicos y el grupo Administradores tiene acceso RW a la carpeta "Administradores". Si alguien tiene acceso a ambos y mueven una subcarpeta de la carpeta "Administradores" a la carpeta "Técnicos", la carpeta que se mueve es sólo accesible para los usuarios en el grupo "Administradores". El grupo "Técnicos" no puede acceder a la subcarpeta aunque esté bajo la carpeta "Técnicos" y debe heredar permisos desde la parte superior.

Como se puede imaginar, esto provoca llamadas de soporte, tickets y ciclos perdidos en la resolución de estos problemas de usuario final, sin mencionar el nido de ratas de permisos con los que puede terminar si los usuarios suelen mover carpetas entre diferentes carpetas seguras / área en el Mismo volumen.

Las preguntas son:

¿Cuál es la mejor manera de solucionar este fallo de diseño NTFS y cómo lo está manejando en su entorno?

Sé que el artículo de la KB enlazado habla de algunas claves del registro para cambiar el comportamiento predeterminado del Explorador de Windows, pero son del lado del cliente y requiere que los usuarios tengan la capacidad de cambiar los permisos que yo creo que en la mayoría de los entornos es un no iniciador si usted Desea mantener el control sobre sus permisos de servidor de archivos (y su cordura como administrador de sistemas).

Mi enfoque es no usar permisos de archivos de nivel de archivo / directorio; Utilizar permisos de nivel compartido de archivos y establecer toda la unidad de datos del sistema de archivos del servidor en Everyone Full Control (que se vuelve discutible).

Sobre los años (10+), he encontrado que los permisos de NTFS son más complejos y conduce a más errores. Si los permisos se establecen mal, o la herencia se rompe, se exponen los datos y es difícil de encontrar y verlo. Además, estás expuesto al problema de mover / copiar como dices.

Lugares en los que tiene que utilizar ACL de directorio / archivo; No conozco ninguna otra solución que la salud de comprobar la cosa sobre una base regular.

Bueno, no es realmente un defecto. Esta regla para manejar permisos al mover archivos ha estado en el lugar desde al menos beta 2 de NT3.1 (aunque obviamente no herencia ya que sólo se agregó con Windows 2000). Es tan conocido como cualquier característica de Windows puede ser. Tengo mucha simpatía por su opinión, ya que puede haber pocos de nosotros que no han sido quemados por esto en una etapa. Pero es algo que el administrador de sistemas aprende rápidamente.

JR

Hemos estado usando NTFS desde NT 3.51 y aunque hemos visto este "problema" (como casi todos) no nos ha causado mucho problema:

  • Siempre le decimos a la gente que copie archivos si necesitan moverlos de un directorio compartido a otro. "Mantenga presionada la tecla CTRL al arrastrar y asegúrese de que el pequeño + está mostrando", es una frase común.
  • Nuestras carpetas compartidas tienen una estructura bastante simple, y las carpetas compartidas que creamos no se cruzan entre grupos demasiado a menudo, por lo que es más probable que las personas deseen copiar archivos en primer lugar.
  • Vemos el problema principalmente en nuestro espacio "común" – carpetas donde todo el mundo puede leer / escribir, pero esos directorios son en su mayoría de corta duración por lo que el problema desaparece cuando son purgados.

Soluciones que puedo pensar en:

  • Encontrar alguna manera de hacer que las carpetas con diferentes permisos se encuentren en diferentes volúmenes NTFS
  • Haga una tarea programada (una vez por hora o una vez al día dependiendo de la frecuencia de las solicitudes de soporte) que se ejecuta a través de las carpetas y restablece todos los permisos para que sean iguales a los del nivel superior. Esto es menos que ideal, más aún si las carpetas tienen muchos archivos en ellos, pero es algo que mantendría el problema fijo si no hay una buena solución, como un servidor de registro del lado del registro. El comando que querrá ver es llamado "cacls", que luego podría agregar a un archivo por lotes.

Descargo de responsabilidad – Vengo de un fondo unix (y han implementado el último para arreglar los diferentes defectos de permisos – se siente icky, pero hace el trabajo), por lo que puede haber una solución mucho mejor.

Al moverme como administrador, utilizo xcopy / s / e / c / h / r / k / y – todo aparte de la propiedad de archivo y ACL, lo que significa que la herencia de ACL se activa automáticamente. Nunca tuve que lidiar con una situación en la que un usuario Cosas movidas aunque.

Uso políticas de grupo / políticas de seguridad / sistema de archivos para realizar un seguimiento de los permisos complicados. (NUNCA use los permisos "replace" en la política).

Programe un CACLS para restablecer todo el permiso durante la noche seguido de un gpupdate / force para volver a aplicar el permiso de la política. Funciona de maravilla.

Desde Windows 7 (o quizás Windows Vista), los permisos para una carpeta o archivo heredan del padre si la carpeta se mueve y la fuente y el destino están en el mismo volumen NTFS – si se está copiando un archivo o carpeta a través de Explorer. En un sistema operativo anterior, puede utilizar el Administrador de Far – permite habilitar la herencia de permisos desde el destino (junto con toneladas de otras características). Aunque lejano puede parecer no amistoso para un usuario general.

Una solución muy sencilla es simplemente comprimir los archivos y descomprimirlo en el directorio de destino.