Los archivos montados sobre NFSv4 son propiedad de 4294967294, UID y GID coinciden

23

Tengo dos máquinas Linux idénticas (imágenes idénticas lanzadas en Amazon EC2) y estoy tratando de montar un directorio exportado a través de NFSv4. Así es como se ve el directorio montado en la máquina cliente:

root@server:~# ls -l /websites/
drwxr-xr-x  6 4294967294 4294967294   92 2010-01-01 20:21 logs
drwxr-xr-x  2 4294967294 4294967294   20 2009-12-23 01:14 monit.d
...

Verifiqué dos veces para asegurarme de que los UID coincidían

Aquí está el comando de montaje que ejecuto desde el cliente

/sbin/mount.nfs4 $MASTER_DN:/ /websites -o rw,_netdev,async

Y aquí está la /etc/exportsentrada en la máquina del servidor:

/websites 10.0.0.0/8(fsid=0,no_subtree_check,rw,no_root_squash)
jberryman
fuente
¿se está ejecutando el servicio rpcidmapd? iniciarlos usando comandos. /etc/init.d/rpcidmapd restart chkconfig rpcidmapd on

Respuestas:

8

Como se explica en UID / GID con NFS y ZFS , NFSv4 no usa UID. Estaba teniendo un problema similar y pude solucionarlo usando NFSv3. Esto solo implica agregar -o vers=3al mountcomando. Por supuesto, si necesita usar NFSv4, esta respuesta no le será de mucha utilidad.

intuido
fuente
7

lea aquí http://blather.michaelwlucas.com/archives/796

Si los nombres de dominio del servidor y el cliente NFSv4 no coinciden, todos los nombres de usuario aparecerán como "nadie".

  1. edite /etc/idmapd.conf y configure el dominio en el servidor y el cliente en el "dominio local"

    [General]

    Dominio = dominio local

    [Traducción]

    Método = nsswitch

  2. cambie el archivo / etc / default / nfs-common (tanto en su servidor como en su cliente): establezca NEED_IDMAPD = yes

  3. iniciar el servicio idmapd

vadim
fuente
Para mí, esta respuesta resolvió el problema que tenía (después de que "idmapd" se bloqueó por alguna razón).
Henk
7

Este es un problema de mapeo de id de usuario. Por alguna razón, el sistema está utilizando la cuenta "nadie" en lugar de los identificadores de cuenta verdaderos. Verifique sus opciones de aplastamiento y su archivo idmapd.conf.

Aquí hay un hilo que encontré que analiza el problema, este enlace a la publicación de interés, http://www.mail-archive.com/[email protected]/msg03303.html .

Para su información, 4294967294 es -2, si se trata como un entero con signo de 32 bits. -1 o -2 se usan en varias distribuciones de Linux para el UID de nadie y el GID de nogrupo (en el archivo passwd se usa generalmente el número sin signo más alto de 16 bits, 65535).

David
fuente
Gracias por la respuesta, David. Según mi publicación, lo he no_root_squashhabilitado. ¿Tienes más información sobre el archivo idmapd.conf?
jberryman
3

Debe cambiar el archivo / etc / default / nfs-common ( tanto en su servidor como en su cliente): establezca NEED_IDMAPDen yes.

Al menos esto me ayudó.

Veger
fuente
2

Estamos utilizando las opciones de NFS anonuidy anongidpara establecer las ID de usuario / grupo que el servidor usará para los archivos creados por anónimo. Si no se configuran, se usarán "nobody" y "nogroup", que pueden variar según la versión y distribución del sistema operativo. Entonces un

/websites 10.0.0.0/8 
    (fsid=0,no_subtree_check,rw,no_root_squash,anonuid=1001,anongid=1001)
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^

mayo para el truco (con 1001 siendo un UID / GID válido y utilizable en su servidor).

Axel Knauf
fuente