Montaje de NFS: los propietarios no son nadie:nogroup

Question

Monté un sistema de archivos NFS desde el shell usando el código:

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

Muestro los archivos como nadie:nogroup:

¿Alguna idea para solucionar este problema y mostrar a los propietarios adecuados?

Yo uso Ubuntu 12.04.

Editar:

Del lado del cliente (no tengo acceso al servidor NFS):

rpcidmapdEsta corriendo:

rpcinfo -p:

/etc/idmapd.conf:

Answer 1

Solicitar soporte o documentación local parece una muy buena idea :).

En forma de lista de verificación, creo que necesitas

1) los usuarios requeridos creados en el sistema cliente. Esto se puede hacer manualmente, pero debe esperar que haya un "servicio de directorio" automático que puede configurar. Podría ser LDAP.

2) mapeo de usuarios entre cliente y servidor. En NFS4(implícito en la opción tcp)esto lo maneja idmapd, como lo menciona gareth. Sólo debería necesitar configurar el dominio para que coincida con lo que piensa el servidor. El dominio cruzado no funciona, creo que es una limitación de Linux.

3) kerberos para autenticarse en el servidor (disponible en NFS4). Si desea acceder a algún archivo como alguien que no sea "nadie", esto definitivamente es necesario. Sugiero configurar y probar Kerberos primero que nada. Configurarlo incluirá la configuración de un dominio; configurará el mismo dominio en idmapd.conf.

o con autenticación estilo NFS3, 3) se omite y en lugar de 2) simplemente se asegura de que el UID numérico del usuario coincida con el del servidor. Esto sólo se utiliza cuando el servidor confía en el cliente :).

Answer 2

Seguí un problema similar. Configurar /etc/idmapd.conf Verbosity=3 ayudó a ver algunos de los problemas en Ubuntu, pero no todos. Aquí hay un resumen de mis hallazgos:

Todavía existe la posibilidad de que sus archivos /etc/passwd y de grupo no compartan los mismos usuarios/grupos que la máquina que ofrece el recurso compartido. Aquí hay una sugerencia: su máquina local debe tener una asignación de nombre de usuario/grupo similar. /etc/nsswitch.conf o la operación de mapeo de idmapd fallarán. Tenga en cuenta que si ejecuta Verbosity=3 verá una entrada en /var/log/syslog, como:

idmapd[25193]: Cliente 64: (grupo) nombre "TheGroupNameYouExpected" -> id "65534

Si modifica /etc/nsswitch.conf para asignarlo a algo que no sean archivos (como ldap o nis), entonces también debe asegurarse de que ldap o nis tenga una entrada real de algún tipo para el nombre de usuario o el nombre del grupo que desea traducir. para. Si una entrada no existe, idmapd no podrá asignar correctamente usuarios/grupos.

En problemas relacionados que encontré para RHEL v7, ya no es necesario habilitar el servicio idmapd.conf para clientes NFS:

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

Sin embargo, hay un problema en curso en el hilo anterior que, de forma predeterminada, los servicios que realizan la asignación automática de ID-nombre de usuario tienen una cantidad muy baja de ID que permanecen asignadas en la memoria. En lugar de registrar un error, idmapd simplemente se niega a traducir a más de 200 usuarios. Puede verificar esto desde la configuración actual de su kernel:

cat /proc/sys/kernel/keys/root_maxkeys    

Lo más probable es que 200 sea la configuración predeterminada. Para permitir que los puntos de montaje NFS asigne correctamente a todos los usuarios disponibles, debe cambiar este archivo:

/etc/sysctl.conf

y agregue o modifique estas líneas de la siguiente manera:

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

Es posible que su sistema no requiera tantas asignaciones de claves de usuario/id, así que ajuste según sea necesario. Esto permitirá que todas las claves de nombre de identificación permanezcan asignadas mientras se usa el montaje NFS. Aquí hay otra publicación relacionada que muestra la configuración actual del kernel:

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

para estos valores:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

Lo más probable es que maxbytes y root_maxbytes deban ser lo suficientemente grandes como para almacenar todas las claves:

https://www.kernel.org/doc/Documentation/security/keys.txt

Answer 3

Otra lista de verificación más, suponiendo que esté utilizando NFSv4 con Kerberos:

• kinit, luego mira klist. Deberías ver un ticket; De lo contrario, busque primero respuestas sobre cómo solucionar la autenticación de Kerberos.
• ¿Esta rpc.gssdcorriendo? Es posible que desee iniciar el servicio; Además, en algunas distribuciones, no se inicia automáticamente a menos que menciones montajes NFS con krb5* en sus opciones en tu archivo /etc/fstab.
• ¿Esta rpc.idmapdcorriendo? (Nuevamente, esto normalmente debería iniciarse mediante un servicio nfs del lado del cliente; ls /etc/init.d/es un buen punto de partida.
• mira a /etc/idmapd.conf. ¿La parte "Dominio" coincide con el dominio real de su servidor NFS? (... al menos, podría intentar usar el ámbito Kerberos). He visto distribuciones donde esto no era necesario y algunas donde sí lo era; tal vez en algunos, tenga valores predeterminados más razonables para un FQDN.
• también agregar GSS_principal_attr = GSSAuthNameal archivo. Solo el dominio podría solucionar algunos problemas de propiedad, pero parece que esto también es necesario, por ejemplo, para directorios.
• reinicie al menos rpc.idmapduna vez ajustando la configuración. No debería ser necesario volver a montarlo después de ajustar la configuración, pero no hace daño.
• ¡también! nfsidmap -c. Aparentemente, hay un caché que no se borra ni siquiera con un reinicio; esto lo aclarará. (De lo contrario, podría seguir pensando que la solución no funciona incluso si lo hiciera).