¿Cómo mantener conectado de manera confiable el recurso compartido de red para un usuario específico mediante el montaje automático?

Tengo un Synology NAS y un Mac mini con Plex y XBMC, que transmite contenido desde el NAS. El MM pierde con frecuencia la conexión con el NAS, por varios motivos (p. ej., después de actualizar/reiniciar el NAS, problemas de red, problemas de OS X).

Después de probar varias soluciones para este problema, finalmente encontré la herramienta de montaje automático incorporada, que se supone que vuelve a conectar las unidades de red cuando se pierde la conexión. Lo configuré, y parecía funcionar. Pero hay un problema molesto:

No estoy seguro de cómo expresar esto, pero los recursos compartidos montados automáticamente parecen entrar en algún tipo de estado no realmente conectado de vez en cuando. Cuando se atraviesa el recurso compartido, se conecta inmediatamente. Eso está bien, pero el recurso compartido se monta solo para el usuario que accedió a él .

Tengo dos cuentas de usuario: TV, que ejecuta Plex y XBMC y necesita acceder al recurso compartido, y Admin, que uso para tareas de administración. De vez en cuando, también uso la cuenta de administrador para conectarme al NAS, pero uso el Finder para eso. No hay necesidad de una conexión permanente.

Por alguna razón que no entiendo, a veces, el recurso compartido montado automáticamente se monta para la cuenta de administrador. Lo que significa que la cuenta de TV no puede acceder al recurso compartido (Permiso denegado). Puedo umountcompartir con Admin y lscon TV para montarlo para este último, pero después de un tiempo, Admin vuelve a tener los permisos.

¿Cómo puedo arreglar esto? ¿Cómo debo configurar los permisos para que TV sea la única cuenta que pueda acceder al recurso compartido montado automáticamente?

Así es como se ven mis archivos de montaje automático:


auto_maestro

Permisos:-rw-r--r-- 1 root wheel

+auto_master      # Use directory service
/net              -hosts     -nobrowse,hidefromfinder,nosuid
/home             auto_home  -nobrowse,hidefromfinder
/Network/Servers  -fstab
/-                -static
/-                auto_nas   -nosuid,noowners


auto_nas

Permisos:-rw------- 1 root staff

/NAS -fstype=smbfs,soft smb://TV:@192.168.1.56/Files


/NAS (el punto de montaje)

Permisos:drwx------@ 1 TV wheel


El MM ejecuta Yosemite (10.10.3).

Respuestas (1)

Suponiendo que NO desea habilitar la función de inicio de sesión de usuario "raíz" y aflojar los permisos de archivos y directorios lo suficiente como para abrir potencialmente su sistema a un vector de ataque de seguridad significativo (y asumo exactamente eso...), a partir de hoy , 7 de febrero de 2017, no hay forma de lograr lo que describe :(

Al menos no para los recursos compartidos AFP / SMB / CIFS (esos son los únicos tres que he probado, es posible que tenga suerte con los volúmenes NFS, pero no los ejecuto en mi red, así que no puedo confirmar).

Parece haber dos posibles causas fundamentales. Una es que en algún momento alrededor de Yosemite, hubo algunas modificaciones en la diferencia entre el uso de la funcionalidad de montaje automático directo e indirecto que causaba fallas intermitentes cuando más de un usuario accedía a un recurso compartido montado automáticamente.

A partir de Sierra, esta funcionalidad está completamente rota ya que el propietario del directorio especial /Volumes se convirtió en el usuario "raíz" y ese usuario asumirá la propiedad automáticamente si a otro usuario se le otorga la propiedad de cualquier carpeta o archivo en ese directorio en algún punto. Se han archivado errores , siéntase libre de comentar y compartir su indignación.

En la sección de comentarios de esta publicación de blog que analiza varios ejemplos del uso del montaje automático (y algunas de sus limitaciones), el usuario "Mark" proporciona un análisis completo de este problema con respecto a compartir carpetas montadas automáticamente entre varios usuarios.

TL; DR: se rompió en algún lugar alrededor de 10.10 y, a pesar de que se discutió en muchos foros, Apple aún no ha reconocido el error ni se ha comprometido a solucionarlo.

Creo que hay algo pasando con 10.11 que rompe el procedimiento > para montar recursos compartidos AFP en directorios de usuarios. Estoy tratando de montar afp://user:pass@myserver.local/Music to /Users/me/Test

auto_master tiene la línea: /- auto_afp -nosuid

auto_afp tiene la línea: /Users/me/Test -fstype=afp afp://serveuser:servepass@server.local/Music

El servidor se monta maravillosamente, pero al hacer clic en el icono del servidor en /Users/me da el error "La carpeta" Prueba "no se puede abrir porque no tiene permiso para ver su contenido".

Después de resolver el problema, veo que se trata de un problema de permisos. El punto de montaje tiene el propietario, el grupo y los permisos: drwx——@ 1 rueda raíz 364 31 de diciembre 10:01 Prueba (En realidad, es interesante: si vacío mi archivo auto_afp y reinicio, vuelve a un directorio normal con propietario/ grupo/permisos drwx——+ 18 me personal 612 31 dic 10:01 prueba)

Entonces, el problema aquí es que autofs está montando el recurso compartido con privilegios de root, y mi usuario no puede usar el recurso compartido. Según mi lectura en la web, este parece ser un problema relativamente nuevo, ¿quizás relacionado con El Capitán?

A modo de comparación, cuando hago lo siguiente (como usuario, no como usuario del sistema o usando 'sudo'): Cree una nueva carpeta desde el buscador en /Users/me llamada 'Test3' y luego desde la terminal ingrese: mount -o nosuid -t afp afp://serveuser:servepass@server.local/Music /Users/me/Test3

luego, el servidor se monta maravillosamente (aunque con el nombre del buscador "Música", que preferiría cambiar), y tiene los siguientes usuarios/grupos/permisos: drwx——@ 1 me staff 364 31 Dec 10:21 Test3 y estoy poder ver y manipular los contenidos.

Entonces, en resumen, el problema es: ¿Cómo puedo hacer que autofs monte un recurso compartido AFP de red y lo asigne a un directorio de usuario para que el usuario pueda acceder a él y manipular su contenido? Históricamente, creo que así es exactamente como se supone que funciona autofs, pero parece que la propiedad de la carpeta mapeada por 'root wheel' evita que ahora tenga un uso real.

Un asunto más, ya que estoy en eso: he vuelto al objetivo simple descrito anteriormente, pero mi objetivo a largo plazo es asignar una carpeta de música externa a CADA usuario. auto_afp debería verse así:

/Users/me/Test -fstype=afp afp://serveuser:servepass@server.local/Music /Users/her/Test -fstype=afp afp://serveuser:servepass@server.local/Music /Users/him /Test -fstype=afp afp://serveuser:servepass@server.local/Music

Sé que puedo hacer este montaje en los elementos de inicio de sesión de cada usuario, pero eso no es lo suficientemente bueno para satisfacer mis necesidades a largo plazo. A largo plazo, necesito esta carpeta montada en el arranque por autofs para que esté disponible para la copia de seguridad en la nube.

El usuario "Ben" comentó, confirmando este análisis y haciéndose eco de que al menos hasta el momento en que compartió su comentario, no había solución:

Usar un mapa indirecto tampoco ayuda. Esta funcionalidad parece estar fundamentalmente rota en OSX y se remonta al menos a Yosemite... He investigado 3 años de publicaciones de personas que tienen este mismo problema y, por lo que puedo decir, simplemente no hay forma de compartir un punto de montaje a través de usuarios... qué enorme, exasperante, increíble falla.

gracias manzana!

NOTA: No recomiendo esto para ninguna red, por lo que no proporcionaré instrucciones detalladas sobre cómo hacerlo aquí, pero otro usuario en ese mismo foro de comentarios indicó que habilitar el inicio de sesión del usuario raíz y usarlo para acceder a su sistema permitiría que esto trabajar como se esperaba:

Una opción es habilitar la raíz e iniciar sesión como raíz. Una vez que haces eso, todo comienza a funcionar. Opción de mierda, lo sé, pero mi caso de uso es un servidor de medios en una red aislada. Única opción hasta que pueda ver hasta que Apple se saque la cabeza del culo.

Todo el mundo, Apple, los expertos en seguridad, etc., lo desaconsejan encarecidamente, por lo que creo que es un camino viable para solucionar este problema. Tendremos que esperar hasta que Apple publique una solución.