¿Por qué NFS no me permite montar un recurso compartido?

El anfitrión

Tengo un host, ejecutando Ubuntu 12.04, en 10.0.0.202. Proporciona un recurso compartido NFS para otras máquinas en la red. Aquí está el contenido de /etc/exports:

/media/storagedrive 10.0.0.0/24(rw,sync,no_subtree_check)

La intención aquí es compartir el contenido de /media/storagedriveotras máquinas en la red en el rango de IP 10.0.0.0 - 10.0.0.255.

Cliente de trabajo

Esto funciona correctamente con una máquina cliente en 10.0.0.40Ubuntu 13.10, conocida como MattDev. Esa máquina se /etc/fstabve así:

UUID=8f8c838e-3ea2-457a-87f0-57b12dfab06c /               ext4    errors=remount-ro 0       1
UUID=427089d4-46a2-432d-9df4-7016bdfc7df2 none            swap    sw              0       0
10.0.0.202:/media/storagedrive /mnt/NetworkStorageDrive nfs rsize=8192,wsize=8192,timeo=14,intr

Y ls -al /mnt/en esa máquina se ve así:

total 12K
drwxr-xr-x  3 root root    4.0K Feb  4 17:48 .
drwxr-xr-x 23 root root    4.0K Feb  5 08:44 ..
drwxrwxr-x  7 root plugdev 4.0K Feb  5 11:43 NetworkStorageDrive

La salida de se idve así:

uid=1000(matt) gid=1000(matt) groups=1000(matt),4(adm),24(cdrom),27(sudo),30(dip),33(www-data),46(plugdev),112(lpadmin),124(sambashare)

Cliente virtual que no funciona

Tengo una segunda máquina cliente, que ejecuta Ubuntu 12.10, como sistema operativo invitado en una máquina host de Windows 7. La máquina host está en la red como 10.0.0.28. La máquina invitada está siendo administrada por Vagrant, usando VirtualBox 4.3.6 como proveedor. Llamaré al host de Windows 7 AlexDevHost y al invitado de Ubuntu AlexDevGuest.

Ejecutar showmount -e 10.0.0.202en AlexDevGuest produce:

Export list for 10.0.0.202:
/media/storagedrive 10.0.0.0/24

Sin embargo, cuando intento montar el recurso compartido, falla:

$ sudo mount 10.0.0.202:/media/storagedrive /mnt/NetworkStorageDrive
mount.nfs: access denied by server while mounting 10.0.0.202:/media/storagedrive

Entonces comencé a buscar problemas:

$ ls -alh /mnt/
total 12K
drwxr-xr-x  3 root root 4.0K Feb  5 12:23 .
drwxr-xr-x 26 root root 4.0K Feb  5 12:23 ..
drwxr-xr-x  2 root root 4.0K Feb  5 12:23 NetworkStorageDrive
$ id
uid=1001(vagrant) gid=1001(vagrant) groups=1001(vagrant)
$

Ese uid y gid es diferente al usuario matt en MattDev. Así que hice malabarismos con el uid para vagabundo, ya que he leído que el acceso NFS se controla haciendo coincidir la dirección IP y los uids. Y ahora:

$ id
uid=1000(vagrant) gid=1001(vagrant) groups=1001(vagrant)
$ sudo mount 10.0.0.202:/media/storagedrive /mnt/NetworkStorageDrive
mount.nfs: access denied by server while mounting 10.0.0.202:/media/storagedrive
$

Todavía no hay éxito. Así que ahora me estoy quedando sin ideas.

1. ¿Qué estoy haciendo mal?
2. Si la parte uid es correcta, ¿hay alguna forma de verificar que la máquina del servidor NFS vea que mi intento de acceso proviene 10.0.0.28, y no alguna otra IP que no esté en el rango permitido?

De acuerdo, lo resolví (o al menos, lo hice funcionar y creo que sé qué lo estaba causando).

Agregué la insecurebandera a la /etc/exportslínea en el servidor NFS, así que ahora se ve así:

/media/storagedrive 10.0.0.0/24(rw,sync,no_subtree_check,insecure)

Este indicador permite que las conexiones se originen desde los puertos del cliente por encima de IPPORT_RESERVED (1024).

El comando de montaje ahora funciona.

Supongo por qué la falta de la insecurebandera fue el problema es que VirtualBox estaba usando NAT para pasar la solicitud a la red física, por lo tanto, mientras que el puerto en el invitado de Ubuntu (AlexDevGuest) puede haber estado por debajo de 1024, el puerto traducido en el host de Windows 7 (AlexDevHost) probablemente estaba por encima de 1024 y, por lo tanto, estaba bloqueado. Sin insecureembargo, establecer la bandera significaba que estaba permitido.

Este problema obviamente no afecta a la máquina no virtual DevMatt.