¿Cuánto tiempo hace que no te tropiezas con un servidor con NFS? Si se tratase de un animal seguro que casi podríamos decir que está en peligro de extinción. El caso es que, en ambientes mixtos Windows/*nix con un Directorio Activo (que es el entorno más habitual al que nos enfrentamos) es mucho más práctico y menos problemático montar un servidor con Samba. Pero si en nuestro entorno no existen máquinas con windows o estas son minoritarias, aún podemos montar nuestros servidores de archivos con NFS y usar Windows Services for Unix para dar soporte a este protocolo desde las máquinas con windows (aquí tenéis un tutorial de instalación en castellano).
Para preparar la máquina que ofrecerá los servicios de NFS (y partiendo, como siempre, de una Debian o derivada), sólo tenemos que instalar el paquete nfs-kernel-server (sudo apt-get install nfs-kernel-server) y sus dependencias. Una vez hecho esto podemos ver en el archivo /proc/filesystems que nuestro sistema ya debería de soportar nfs.
Los directorios que queremos compartir se configuran de forma sencilla en el fichero /etc/exports. Allí, y en función de nuestras necesidades, podríamos tener algo como esto:
/mnt/Sistemas 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Desarrollo 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Gestión 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Público (rw,sync,subtree_check)
La sintaxis es bien sencilla. En cada línea pondremos en primer lugar el recurso compartido, en segundo la dirección o direcciones de las máquinas que tendrán acceso a él y, por último y entre paréntesis y sin ningún espacio de separación, los atributos que aplicaremos al recurso compartido.
La forma de expresar las máquinas que tienen acceso al recurso es bien versatil. Podemos poner una única dirección IP (192.168.1.5), una subred completa (192.168.1.0/25 ó 192.168.1.0/255.255.255.128), un nombre de máquina (estacion1.midominio.net), o usar comodines * y ? (estacion*). Si no ponemos nada quiere decir que no habrá restricciones en cuanto al origen de la conexión (como en el caso del recurso /mnt/Público del ejemplo anterior). Si quisiéramos aplicar opciones diferentes según el origen de la conexión lo hacemos de forma consecutiva en la misma línea del fichero exports. De esta forma:
/mnt/Gestión 192.168.1.10(rw) 192.168.1.11(rw) 192.168.1.0/25(ro)
Las diferentes opciones de montaje pueden consultarse con man exports. Algunas de las más comunes son ro (sólo lectura), rw (lectura y escritura), async o sync (según si queremos que replique las modificaciones antes de hacer un commit de estas o no), etc. Despues de cada cambio en el fichero de unidades compartidas debemos de ejecutar la orden exportfs -a para que estos tengan efecto. Ah, y no olvidemos que los permisos aplicados sobre ficheros y directorios de las unidades compartidas ha de ser coherente con los que apliquemos al publicar las mismas.
Y ahora nos vamos con los clientes. En ellos lo único que tenemos que instalar es el paquete nfs-common y sus dependencias. Y listo. Ahora podemos montar las unidades de nuestro servidor remoto de forma manual o, si queremos hacerlo de forma permanente, añadiendo una línea en nuestro fichero fstab. La forma manual sería algo así:
mount -t nfs servidornfs:/mnt/datos /home/josemaria/datos
Si queremos hacerlo desde el fichero fstab, la línea a añadir para el mismo ejemplo anterior sería esta:
servidordns:/mnt/datos /home/josemaria/datos nfs auto,user,noexec,rw
Un par de notas finales. NFS siempre ha recibido muchas críticas por su seguridad hasta la versión 3. La versión 4, que es la que implementan ya los kernels modernos de Debian y sus derivados (Ubuntu, etc.), puede usar Kerberos para proporcionar seguridad en los accesos si así lo requerimos. Por último, aquí tenéis una buena comparativa que señala las debilidades y fortalezas de los sistemas de compartición de archivos más comunes (CIFS es la versión de SMB implementada por los sistemas de Microsoft).
