Asignación de ID de usuario con NFS en Synology NAS

Tengo una caja NAS de Synology (que ejecuta DSM 5.1) y exporté un directorio a través de NFS. Estoy intentando montarlo en mi caja de Ubuntu.

En su mayoría funciona bien, pero tengo problemas con las asignaciones de usuarios y grupos. En el cuadro de Ubuntu, soy uid 1000 (roger), gid 1000 (roger). En Synology, tengo uid 1026 (roger), grupo 100 (usuarios).

Si uso NFSv3, usa valores numéricos uid / gid, lo que significa que la propiedad está en mal estado en Synology.

Si solo tuviera acceso al montaje NFS desde el mismo cuadro de Ubuntu, usando el mismo usuario, estaría bien, pero también accedo al directorio desde un cuadro de Windows, usando CIFS (SMB), lo que significa que los permisos son incorrecto.

Si utilizo NFSv4 ( mount -o nfsvers=4), con la configuración predeterminada en Synology, los archivos que pertenecen roger.usersa Synology aparecen roger.userscuando se ven desde el cuadro de Ubuntu. Esto es bueno.

Sin embargo, cuando tengo touchun archivo:

roger@ubuntu$ touch /mounts/diskstation/music/foo

Termina siendo propiedad de 1000.1000Synology, y se muestra como propiedad nobody.4294967294cuando se ve desde el cuadro de Ubuntu.

Todo lo que puedo encontrar sobre el tema en los foros de Synology data de 2011, cuando NFSv4 no era compatible, o consiste en personas que hacen la misma pregunta y luego se rinden.

Para completar, /etc/exportstiene:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

... y lo estoy montando en la caja de Ubuntu con:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

Encontré algunas pistas de que sec=syspodría ser un problema: por qué el mapeo uid / gid de NFSv4 no funciona con AUTH_UNIX (AUTH_SYS) , pero eso no tiene una solución.

¿Hay una manera simple de solucionar este problema? ¿Hay alguna forma más compleja ( tos de Kerberos de tos ) para resolver esto?

En serio, si Kerberos es la respuesta, tomaré ese golpe, pero me gustaría saber antes de perder un montón de tiempo.

Actualización : aunque la documentación de Synology habla sobre varias opciones de Kerberos, no puedo encontrarlas en la interfaz de usuario. Las notas de la versión indican "Si se implementa el sabor de seguridad Kerberos ...". Encontré (pero no puedo encontrar de nuevo) una página que implica que podría no estar en ciertos modelos. Tengo un DS211, de acuerdo con la página de información del sistema. Tal vez no tengo suerte?

Para que la asignación de ID NFSv4 funcione correctamente, tanto el cliente como el servidor deben ejecutar el idmapddaemon ID Mapper y tener el mismo Domainconfigurado /etc/idmapd.conf.

De esta forma, su cliente NFS envía sus credenciales de identificación como [email protected]en los comandos NFS en el cable, y su idmapper del servidor NFS asigna eso a un usuario llamado rogeren el servidor NFS. El UID y el GID no importan, el mapeador de mapas los asigna en cada sistema.

Sin embargo, no me molesto con eso en mi Synology. Mi carpeta compartida tiene los siguientes permisos:

• Permisos
  • Usuarios locales
    • Admin = leer / escribir
• Permisos NFS
  • Squash
    • Asigne todos los usuarios al administrador

Esto hace que anonuid=1024,anongid=100(el adminusuario y el usersgrupo) se agreguen a la exportación en /etc/exportsel NAS.

Mi cliente NFS (que no tiene el ID Mapper en ejecución) envía mis comandos NFS como mi usuario ( 1000:1000) y debido a que ese UID y GID no existen en el NAS, traduce mi UID y GID para 1024:100que me traten como el Usuario administrador que tiene permiso completo.

Este es un uso terriblemente poco profesional e inseguro de NFS para un entorno empresarial, pero solo para mí acceder a mis archivos en casa es un abuso del comportamiento de NFS que es aceptable para mí.

Otra opción es hacer que rogerel UID y el GID sean iguales en el Cliente NFS y NAS, luego puede usar NFSv4 sin asignación de ID, o puede usar NFSv3 que se basa solo en UID y GID.

Realmente he estado luchando con exactamente el mismo problema. Pasé por la gran molestia de configurar un servidor Kerberos con Docker en Synology, configuré el mapeo de ID, y todavía no me gustó el comportamiento. Kerberos está demasiado diseñado y es difícil seguir trabajando en reinicios y montajes automáticos. Además, la umask predeterminada de los archivos recién creados fue 0000, y cada nuevo archivo se creó en modo 777, sin importar cuál fuera mi umask local.

Mi solución fue similar a la de suprjami, pero la llevé un poco más allá:

• Cree un nuevo usuario con la interfaz de usuario web de Synology, asígnele un nombre roger.remote. Haga lo mismo para un grupo de usuarios y asígnele el mismo nombre que el nombre de usuario.
• En Synology como root, edite / etc / passwd y cambie roger.remoteel UID a 1000, y GID a 1000
• edite / etc / group y cambie el grupo roger.remotea 1000 también
• En la interfaz de usuario web de Synology, configure squash en "todos los usuarios para administrar" y guarde
• Como root nuevamente, edite / etc / exporta y cambie el UID / GID a anonuid=1000,anongid=1000
• Reinicie NFS con /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Esto también es un poco hacky, pero chmod 777 /volume1. Tuve muchos problemas extraños con mi directorio de inicio montado. KDE no se iniciará porque la access()función glibc devolverá el acceso denegado en el directorio NFS montado. (Pero cualquier subdirectorio funcionaría) Firefox también tuvo un problema similar, donde se negó a guardar archivos en el directorio montado debido a la verificación de acceso. Aunque los permisos eran correctos, podía tocar / crear / escribir archivos en el directorio montado. Cambiar el directorio padre / volumen1 a escritura mundial solucionó ese problema tonto y engañó a las aplicaciones cliente para que escribieran en él.
• Elimine todas las ACL del sistema de archivos del recurso compartido. A través de una gran cantidad de experimentos aleatorios, descubrí que estas ACL causan problemas con la máscara de modo de los archivos creados. No soy un maestro de ACL, así que quizás haya una solución más elegante. Como root en Synology, hazlo synoacltool -del /volume1/myshare. Debería ver el +símbolo eliminado de la salida ls -l.
• Cambie la propiedad del recurso compartido a su nuevo usuario: chown roger.remote:roger.remote /volume1/myshare
• Cambia el modo a 755: chmod 755 /volume1/myshare
• Monte el volumen en el cliente, pruebe los permisos, ¡debería funcionar! Asegúrese de tocar también un archivo y verifique que su bash umask se haya aplicado correctamente.

$ umask 
0002
$ cd / mnt / myshare
$ prueba táctil
$ ls -l prueba
-rw-rw-r-- 1 roger roger 0 21 de octubre 18:15 prueba

En Synology debería ver:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 21 de octubre 18:15 prueba

¡Disfrutar!