El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más clientes. Los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor. Para que el sistema funcione correctamente se deben configurar y ejecutar unos cuantos procesos.

El servidor de NFS debe ejecutar los siguientes dæmones:

El cliente también puede ejecutar un dæmon conocido , como nfsiod. El dæmon nfsiod atiende las peticiones provinientes del servidor NFS. Este dæmon es opcional y sirve para mejorar el rendimiento pero no es necesario para el funcionamiento correcto del sistema. Se recomienda consultar nfsiod(8) para obtener más información.

La configuración de NFS es un proceso relativamente sencillo. Para que los procesos anteriormente descritos se ejecuten en tiempo de arranque del sistema, basta con realizar paqueñas modificaciones en /etc/rc.conf.

En /etc/rc.conf del servidor de NFS se deben configurar las siguientes opciones:

portmap_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"

mountd se ejecuta automáticamente cuando se activa el servidor NFS.

En el cliente debemos asegurarnos de que se encuentra activada la activada la siguiente opción dentro de /etc/rc.conf:

nfs_client_enable="YES"

El archivo /etc/exports especifica los directorios o sistemas de ficheros que NFS exporta al exterior. Cada línea dentro de /etc/exports/ especifia un sistema de ficheros y qué máquinas tienen derechos de acceso sobre dicho sistema. Además de los derechos de acceso se pueden definir otras opciones de acceso, tales como solo lectura o lectura y escritura. Existen multitud de opciones que pueden definirse sobre un directorio exportable pero en este manual sólo se van a comentar unas pocas. Consulte exports(5) para obtener una descripción más detallada.

Aquí se muestran algunos ejemplos de entradas para /etc/exports:

El siguiente ejemplo proporciona una idea de cómo exportar sistemas de ficheros, aunque los parámetros pueden diferir dependiendo de su entorno y su configuración de red. En dicho ejemplo, se exporta el directorio /cdromm a tres máquinas que se encuentran en el mismo dominio que el servidor (de ahí que no se especifique ningún nombre de dominio para cada máquina) o que pueden estar dadas de alta en /etc/hosts. En cualquier caso la opción -ro configura el sistema de ficheros de red como “sólo lectura” (“read-only”). Con esta opción los sistemas remotos no serán capaces de realizar cambios sobre el sistema de ficheros exportados.

/cdrom -ro host1 host2 host3

La siguiente línea exporta el directorio /home a tres máquinas utilizando direcciones IP. Esto resulta útil cuando disponemos de una red privada pero no disponemos de ningún servidor de DNS configurado. También se podría configurar /etc/hosts para que resolviera nombres de máquinas internos; consulte hosts(5) para obtener más información al respecto. La opción -alldirs permite que los subdirectorios del directorio /home tambíen se puedan utilizar como puntos de montaje. En otras palabras, esto permite que los clientes puedan trabajar sobre los subdirectorios en los que estén realmente interesados.

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

La siguiente línea exporta el directorio /a de tal forma que puedan acceder a dicho directorio dos máquinas situadas en distintos dominios. La opción -maproot=root permite que el usuario root de la máquina cliente modifique los datos del sistema de ficheros en red como si fuera el usuario root del servidor. Si no se especifica la opción -maproot=root el usuario root del cliente puede no poseer los permisos necesarios para realizar modificaciones en el sistema de ficheros.

/a  -maproot=root  host.example.com box.example.org

Para que un cliente pueda acceder al sistema de ficheros exportado debe poseer permisos para ello. Debemos asegurarnos de que el cliente se encuentra listado en /etc/exports.

Dentro de /etc/exports cada línea representa información de exportación de un sistema de ficheros para un determinado conjunto de máquinas. Una máquina sólo puede aparecer una vez dentro de un sistema de ficheros exportable y el archivo sólo puede tener una única entrada por defecto. Por ejemplo, si suponemos que /usr es un único sistema de ficheros la siguiente configuración de /etc/exports sería incorrecta:

/usr/src   client
/usr/ports client

Existe un sistema de ficheros, concretamente /usr, que posee dos líneas con reglas de exportación para la misma máquina, client. El formato correcto para esta situación sería el siguiente:

/usr/src /usr/ports  client

Las propiedades de un sistemas de ficheros que se exporta al exterior deben aparecer agrupadas bajo la misma línea. Líneas que no poseen ningún cliente se tratan como si tuvieran una única máquina. Esto limita la forma en que pueden configurarse la exportaciones de sistemas de ficheros pero para la mayoría de la gente no suele ser un problema.

El ejemplo que se muestra a continuación es una muestra de una lista de exportación correcta, donde /usr y /exports son sistemas de ficheros locales:

# Exportar src y ports a cliente01 y cliente02, pero
# solo el cliente01 tiene acceso root
/usr/src /usr/ports -maproot=root    cliente01
/usr/src /usr/ports               cliente02
# Las maquinas cliente tienen acceso root y pueden montar todo lo que aparezca
# en /exports.  Cualquier sistema puede montar /exports/obj en modo
# solo lectura
/exports -alldirs -maproot=root      cliente01 cliente02
/exports/obj -ro

Se debe reiniciar el dæmon mountd siempre que se modifique el contenido del archivo /etc/exports para que los cambios surtan efecto. Esto se realiza enviando la señal HUP al proceso mountd:

# kill -HUP `cat /var/run/mountd.pid`

También se puede reiniciar FreeBSD para que se cargue la nueva configuración pero este mecanismo no resulta necesario si se ejecutan las órdenes como root, que ponen el servidor de NFS de nuevo en funcionamiento.

En el servidor de NFS:

# portmap
# nfsd -u -t -n 4
# mountd -r

En el cliente de NFS:

# nfsiod -n 4

En este punto todo debería estar preparado para poder anclar el sistema de ficheros remoto en la máquina cliente. En los siguientes ejemplos el nombre del servidor es server y el punto de montaje temporal utilizado por el cliente es client. Si se desea montar el sistema de ficheros de forma temporal o simplemente comprobar que la configuración funciona sin problemas se puede ejecutar una orden como la que se muestra a continuación con permisos de root en la máquina cliente:

# mount server:/home /mnt

Esta orden ancla el directorio /home del servidor en el directorio /mnt del cliente. Si todo funciona correctamente debería poder entrar en el directorio /mnt del cliente y ver todos los ficheros que se encuentran en el directorio /home del servidor.

Si queremos anclar automáticamente un sistema de ficheros remoto cuando la máquina está arrancando se puede añadir una línea como la siguiente dentro de /etc/fstab:

servidor:/home	/mnt	nfs	rw	0	0

fstab(5) comenta todas las opciones disponibles.

El protocolo NFS tiene múltiples usos prácticos. Los más típicos se enumeran a continuación:

El dæmon amd(8) (“the automatic mounter daemon”, o dæmon de montaje automático) automáticamente ancla un sistema de ficheros remoto cuando se tiene que acceder a un fichero perteneciente a dicho sistema. Los sistemas de ficheros que permanecen inactivos durante un determinado periodo de tiempo son automáticamente desmontados por el mismo dæmon. Este dæmon proporciona una alternativa sencilla a la utilización de los montajes permanentes que normalmente se especifican a través del fichero /etc/fstab.

amd trabaja actuando como un servidor servidor de NFS para los directorios /host y /net. Cuando se accede a algún fichero ubicado bajo estos directorios amd busca el punto de montaje remoto y automáticamente lo monta. El directorio /net se utiliza para anclar sistemas de ficheros remotos especificados mediante direcciones IP, mientras que el directorio /host almacena aquellos sistemas de ficheros remotos que han sido especificados mediante un nombre de máquina.

amd detecta cualquier intento de acceder a un fichero dentro del directorio /host/foobar/usr y se encarga de montar el sistema de ficheros remoto (/usr) en la máquina, en caso de que no estuviera ya anclado.

% showmount -e foobar
Exports list on foobar:
/usr                               10.10.10.0
/a                                 10.10.10.0
% cd /host/foobar/usr

Como se observa en el ejemplo, showmount muestra el directorio /usr como una exportación. Cuando se cambia el directorio actual al directorio /host/foobar/usr el dæmon amd intenta resolver el nombre foobar y automáticamente ancla el sistema de ficheros remoto.

El dæmon amd se puede ejecutar a partir de los scripts de inicio, utilizando la siguiente línea del archivo de configuración /etc/rc.conf:

amd_enable="YES"

Además, amd soporta opciones adicionales que pueden definirse mediante la variable amd_flags. Por defecto, la variable amd_flags posee las siguientes opciones:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

El archivo /etc/amd.map define las opciones por defecto con las cuales se anclan los sistemas de ficheros remotos. El archivo /etc/amd.conf define algunas características avanzadas para el dæmon amd.

Se ruega consultar las páginas del manual de amd(8) y de amd.conf(5) para obtener más información.

Determinados adaptadores Ethernet para sistemas basados en el bus ISA poseen restricciones que pueden producir serios problemas de red, en particular con el protocolo NFS. Estos problemas no son específicos de FreeBSD, pero los sistemas FreeBSD se ven afectados por ellos.

El problema surge casi siempre cuando el sistema (FreeBSD) está empotrado dentro de una red compuesta por estaciones de trabajo de alto rendimiento, como por ejemplo estaciones de Silicon Graphics y de Sun Microsystems. El montaje del sistema de ficheros remoto suele funcionar perfectamente y algunas operaciones sobre el el sistema de ficheros pueden tener éxito pero de repente el el servidor que no responde a las peticiones del cliente, aunque peticiones y respuestas de otros clientes funcionan con normalidad y se continúan procesando. Esto sucede en los sistemas clientes, tanto en sistemas FreeBSD como en otras estaciones de trabajo. En muchos sistemas, lo único que se puede hacer es resetear la máquina de forma abrupta, ya que el bloqueo producido por el protocolo NFS no se puede solucionar.

Aunque la solución “correcta” consiste en obtener un adaptador Ethernet con mayor rendimiento y capacidad, todavía se puede aplicar un parche sencillo que puede llegar a permitir un funcionamiento sin problemas. Si el sistema FreeBSD actúa como servidor de NFS se puede incluír la opción w=1024 cuando el ejecute una petición de montaje sobre dicho servidor. Si FreeBSD dicho servidor. Si FreeBSD actúa como cliente de NFS, se puede ejecutar mount(8) con el parámetro -r=1024. Estas opciones se pueden especificar en el /etc/fstab del cliente para que entren en funcionamiento cuando se realicen montajes automáticos y también se puede utilizar el parámetro -o de mount(8) cuando se realicen montajes manuales.

Resulta apropiado resaltar que existe un problema totalmente distinto que algunas veces se confunde con el que acabamos de describir, que aparece cuando el servidor y los clientes se encuentran en redes diferentes. Si nos encontramos en esta situación debemos asegurarnos de que nuestros “ routers” están encaminando correctamente los paquetes UDP que genera el protocolo NFS pues en caso contrario el sistema no funcionará, independientemente de los ajustes que se realicen en el cliente o en el servidor.

En los siguientes ejemplos fastws es el nombre de una estación de trabajo de altas prestaciones y freebox es el nombre de un sistema FreeBSD con un adaptador Ethernet de bajas prestaciones. Se pretende además exportar el directorio /sfcompartido (ver exports(5)) y el directorio /projecto. Tenga en cuenta que en cualquier caso puede resultar útil definir opciones adicionales a las que que se muestran en el siguiente ejemplo, como pueden ser hard, soft o bg. Esto dependerá de la aplicación que utilice el sistema de ficheros remoto.

Ejemplos de configuración para el sistema FreeBSD (freebox) que actúa como cliente. Configuración del archivo /etc/fstab de freebox:

fastws:/sfcompartido /projecto nfs rw,-r=1024 0 0

Orden de ejecución manual para freebox:

# mount -t nfs -o -r=1024 fastws:/sfcompartido /projecto

Ejemplos de configuración para el sistema FreeBSD que actúa como servidor. Configuración de /etc/fstab de fastws:

freebox:/sfcompartido /projecto nfs rw,-w=1024 0 0

Orden de ejecución manual para fastws:

# mount -t nfs -o -w=1024 freebox:/sfcompartido /projecto

Casi cualquier adaptador Ethernet de 16 bits permite operar sin operar sin las restricciones anteriores sobre el tamaño de lectura o escritura especificado por defecto.

Por si alguien estuviera interesado a continuación se muestra el error que aparece en estos casos, lo cual explica por qué decimos que el error resulta irrecuperable. NFS trabaja típicamente con un tamaño de “bloque” de 8 K (aunque se pueden producir fragmentos de menor tamaño). Debido a que el máximo tamaño de los paquetes Ethernet se encuentra alrededor de los 1500 bytes el “bloque” de NFS se trocea en varios paquetes Ethernet aunque desde el punto de vista del protocolo NFS se trata como si fuese un único paquete. Los trozos deben reensamblarse en el destino y se debe enviar una confirmación para el bloque recibido. Las estaciones de trabajo de altas prestaciones pueden soltar paquetes NFS de forma contínua uno después de otro, lo más juntos posible. Por otro lado en las tarjetas de red más pequeñas y de menor capacidad puede ocurrir que un paquete recien llegado a la tarjeta sobreescriba información perteneciente a un paquete anterior antes de que llegue a ser transmitido completamente, de tal forma que al recibirse el bloque NFS no puede ser ni reconstruido ni ni reconocido. Como resultado de este proceso la máquina tratará de enviar el mismo paquete transcurridos unos instantes de espera, pero se tratarán de enviar de nuevo los 8 K que constituyen un bloque NFS, y de esta forma se repetirá el el proceso, así hasta el infinito.

Si se mantiene el tamaño del bloque por debajo del tamaño de paquete máximo de Ethernet, podemos asegurar que cualquier paquete Ethernet transporta un bloque NFS, el cual puede asentirse individualmente, evitando así la explosión de paquetes y el eventual bloqueo del sistema.

Desbordamientos circulares del “buffer” (“ overruns”) pueden producirse si nos encontramos con una estación de trabajo de altas prestaciones que envía contínuamente mucho tráfico a un sistema convencional, pero con tarjetas Ethernet de buena calidad, estos desbordamientos resultan altamente improbables para el caso de los tamaños de bloque por defecto generados por el sistema NFS. Cuando se produce un desbordamiento, las unidades afectadas se retransmiten, y existe una gran probabilidad de que se reciban, se reensamblen y se confirmen.