Tengo MCEBuddy configurado para convertir grabaciones de TV de Emby en un almacenamiento de red usando rutas UNC. Las conversiones funcionan bien. Sin embargo, al finalizar, la configuración de acceso del grupo está incompleta. El archivo entrante tiene permisos de acceso completo para el usuario llamado “admin” y los grupos “wheel” y “admin” (sí, “admin” es tanto un usuario como un grupo). El archivo convertido tiene permisos de acceso completo para el usuario “admin” y el grupo “wheel”. Los permisos de acceso para el grupo “admin” faltan. ¿Cómo puedo agregarlos automáticamente después del procesamiento, por favor?
MCEBuddy le indica a Windows que herede los permisos del archivo de destino desde el archivo de origen. Si la carpeta de destino no tiene los mismos permisos de herencia que el origen, es posible que Windows no los transfiera.
En mi caso, la carpeta de destino es la misma que la carpeta de origen, y la carpeta tiene los mismos permisos que el archivo, es decir, incluye tanto el grupo “wheel” como el grupo “admin” con permisos de acceso completos. Sin embargo, el archivo convertido carece de los permisos del grupo “admin”. Parece que esto se desvía de cómo se supone que debería funcionar, pero quizá me esté perdiendo algo.
Necesitas el directorio contenedor para aplicar los permisos de grupo heredados, no solo los permisos del propietario.
En un sistema operativo Unix/Linux (esto suena a BSD, con un grupo “wheel”), necesitarías que el directorio contenedor tenga el bit de permisos setgid establecido, no solo el bit setuid. Revisa la ayuda del comando chmod y el permiso setgid.
El recurso compartido está configurado en un servidor FreeNAS mediante el servicio samba. Establecí permisos ACL para el dataset dentro de FreeNAS para el grupo “admin” con “Control total” y banderas de “heredar”. Tengo entendido que una vez que se establecen los permisos ACL, no debería estar manipulando chmod.
EDIT: ¿No indica el hecho de que el archivo grabado .ts tenga todos los permisos que la herencia de grupo funciona correctamente en el lado de Windows? Solo después de que MCEBuddy procesa el archivo y lo copia de regreso al directorio de origen es que los permisos son incorrectos. No estoy diciendo que no esté haciendo algo mal, pero ciertamente no lo estoy entendiendo. También estoy reacio a ser demasiado generoso con la línea de comandos porque me preocupa estropear el servidor.
Ah. Podría ser que MCEBuddy realice una operación de “mover” o “renombrar” desde el directorio temporal de procesamiento, y por lo tanto el archivo tendría los valores predeterminados de ese directorio cuando ocurre el “movimiento”.
Eso sería diferente a si MCEBuddy está realizando una “copia”, y por tanto requiere el doble de espacio para lo que pueden ser archivos muy grandes.
Tal vez verifica los permisos de tus carpetas temporales donde MCEBuddy está procesando los archivos temporales.
Lo que propones tiene sentido. Sin embargo, no consigo añadir permisos a la carpeta temporal de procesamiento para el grupo “admin” en el servidor FreeNAS porque el servidor no es reconocido como una máquina de red Windows válida. En otras palabras, no aparece como un equipo en “red” en el Explorador de Windows. Y cuando intento añadir permisos de seguridad para el grupo, no puedo seleccionar el servidor en “Ubicaciones” del panel de propiedades del archivo → seguridad → añadir.
Así que después de abandonar Windows Server por FreeNAS, ya no uso Active Directory y parece que esta es la razón por la que ya no puedo agregar permisos para usuarios de red. Para los grupos de trabajo, el enfoque parece ser recrear los grupos y usuarios en la máquina local. Aquí fallé porque Windows no me permite crear un grupo “admin” con el mismo nombre que el usuario “admin”. Tal vez esto es lo que está causando el problema. Si este es el caso, me topé con una limitación del sistema operativo Windows y puede que tenga que vivir con los permisos incorrectos.
¿Lograste que tu FreeNAS se viera como un servidor en tu red después de eliminar AD?
Puede que haya todo tipo de políticas de grupo de AD en tus clientes Windows a las que ya no puedes acceder (porque AD desapareció y no hay PDC), aunque hayan retrocedido a SMBv2.
Además, yo tengo una red similar con Samba/NAS sin AD y clientes Windows Home usando mi router ASUS, y este no soporta SMBv2. Así que tengo que activar SMBv1 en cada cliente para que “vea” el router. ¿Podría ser algo parecido?
Tu NAS ahora también tiene que ejecutar un PDC si vas a intentar usarlo como un reemplazo directo de AD, pero no creo que puedan reemplazar completamente AD, ya que AD también gestiona mucho más en los clientes que solo los permisos de uso compartido de archivos.
Podrías tomar las herramientas GPedit y ACL de tu Windows Server (solo los ejecutables) y ver si pueden ayudarte a ver cuántas cosas de AD quedaron atrás, y posiblemente estén interfiriendo. Sé que tuve problemas cuando eliminaron HomeGroups (una especie de AD-lite para Windows Home) y volvieron al modelo básico de Workgroup, porque todo tipo de permisos y características desaparecieron, pero sus ACLs y entradas de registro no lo hicieron.
Porque en el mundo de Microsoft, no hay nada que migre a una alternativa o reemplazo de AD, ya que eso no existe. Por lo tanto, no hay necesidad de escribir código para realizar una migración o transición suave a algún otro producto que no sea de Microsoft. Ni de escribir nada que limpie después de eliminar un Servidor Microsoft de tu red, ya que ese no es un caso de uso válido para ellos (en el mundo de Microsoft).
El servidor FreeNAS nunca estuvo conectado a AD. Reemplacé un Windows Server 2012 Essentials quitando los clientes del dominio y añadiendo el servidor FreeNAS a la red. Así que ya no uso dominios ni AD. En su lugar, simplemente uso los mismos nombres de usuario y contraseñas en diferentes máquinas, incluido el servidor FreeNAS, y no tengo problemas para conectarme al servidor. Todo esto parece funcionar bien con SMB v2.
El problema parece ser que, aunque los nombres de usuario/contraseñas coinciden, son definiciones locales y no puedo añadir permisos para usuarios remotos en una máquina local. Parece que esta sería la ventaja de un dominio, así que quizá esta es una limitación con la que tengo que vivir.
No he tenido problemas con mi configuración aparte de la limitación reportada aquí. Pensé que podría haber una solución alternativa, pero quizá no la hay.
Ah, creo que entiendo. ¿Has probado anteponer el nombre de la máquina remota a los permisos (como un dominio)? Por ejemplo, para añadir User1 en Host1 a Host2, otorgarías permisos de compartición a «Host1\User1». Quizá tengas que escapar los caracteres en el NAS, ya que la barra invertida probablemente sea un carácter especial, como «Host1\\\User1».