El anfitrión
Tengo un host que ejecuta 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 /media/storagedrivecon otras máquinas en la red en el rango de IP 10.0.0.0 - 10.0.0.255.
Cliente que trabaja
Esto funciona correctamente con una máquina cliente en 10.0.0.40Ubuntu 13.10, conocida como MattDev. Esa máquina /etc/fstabse ve 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 idse ve 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 con Windows 7. La máquina host está en la red como 10.0.0.28. Vagrant administra la máquina invitada, utilizando VirtualBox 4.3.6 como proveedor. Llamaré al host de Windows 7 AlexDevHost y al invitado de Ubuntu AlexDevGuest.
Al ejecutar showmount -e 10.0.0.202AlexDevGuest se 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 son diferentes al usuario matt en MattDev. Así que hice malabarismos con el uid para vagrant, ya que leí que el acceso a 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
$
Aún no hay éxito. Así que ahora me estoy quedando sin ideas.
- ¿Qué estoy haciendo mal?
- Si la parte del uid es correcta, ¿hay alguna manera de verificar que la máquina del servidor NFS vea que mi intento de acceso proviene de
10.0.0.28y no de alguna otra IP que no esté en el rango permitido?
Respuesta1
Bien, 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, por lo 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 puertos de cliente superiores a IPPORT_RESERVED (1024).
El comando de montaje ahora funciona.
Mi suposición de 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 que si bien 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 embargo, establecer la insecurebandera significaba que estaba permitido.
Obviamente, este problema no afecta a la máquina no virtual MattDev.