Hoy vamos a tratar de comprender las diferencias que existen en Unix / Linux entre los enlaces simbólicos (soft o symbolic links) y los enlaces duros (hard links).

Enlaces simbólicos (soft / symbolic links)

La manera más sencilla de comprender que es un enlace simbólico en Linux es compararlo con el “enlace directo” o “shortcut” en Windows. El fichero o directorio se encuentra en un único punto del disco y los enlaces son un puntero contra él. Cada enlace simbólico tiene su propio número de inodo lo que permite hacer enlaces simbólicos entre distintos sistemas de ficheros.

Para crear enlaces (tanto simbólicos como duros) usamos el comando ln. En este caso vamos a crear un enlace simbólico (parámetro

) del fichero test:

$ ln -s test enlace-a-test

Si listamos ambos veremos que el enlace tiene el carácter

que lo identifica como enlace simbólico:

$ ls -l
lrwxrwxrwx 1 alex alex 4 2011-04-27 18:59 enlace-a-test -> test
-rw-r--r-- 1 alex alex 0 2011-04-27 18:58 test

Para confirmar que el enlace simbólico tiene un inodo distinto usamos el comando stat:

$ stat test
  File: «test»
  Size: 0         	Blocks: 0          IO Block: 4096   archivo regular vacío
Device: 804h/2052d	Inode: 73793       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 18:58:53.124142406 +0200
Modify: 2011-04-27 18:58:53.124142406 +0200
Change: 2011-04-27 18:58:53.124142406 +0200

$ stat enlace-a-test
  File: «enlace-a-test» -> «test»
  Size: 4         	Blocks: 0          IO Block: 4096   vínculo simbólico
Device: 804h/2052d	Inode: 77212       Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 18:59:07.812139890 +0200
Modify: 2011-04-27 18:59:06.460112888 +0200
Change: 2011-04-27 18:59:06.460112888 +0200

También lo podemos verificar sacando el inodo en el ls (

):

$ ls -li
77212 lrwxrwxrwx 1 alex alex 4 2011-04-27 18:59 enlace-a-test -> test
73793 -rw-r--r-- 1 alex alex 0 2011-04-27 18:58 test

Hay que tener en cuenta, que en Linux / Unix (al igual que con los accesos directos de Windows), si borramos el fichero o directorio origen, el enlace simbólico permanece pero los datos desaparecen para siempre.
 

Enlaces duros (hard links)

Los enlaces duros lo que hacen es asociar dos o más ficheros compartiendo el mismo inodo. Esto hace que cada enlace duro es una copia exacta del resto de ficheros asociados, tanto de datos como de permisos, propietario, etc. Esto implica también que cuando se realicen cambios en uno de los enlaces o en el fichero este también se realizará en el resto de enlaces.

Los enlaces duros no pueden hacerse contra directorios y tampoco fuera del propio sistema de ficheros.

Vamos a crear un hard link contra el fichero “test” de antes y veremos que efectivamente comparten inodo y que los datos se sincronizan entre ambos:

$ ln test enlace-duro-test
$ ls -li
73793 -rw-r--r-- 2 alex alex 5 2011-04-27 19:09 enlace-duro-test
73793 -rw-r--r-- 2 alex alex 5 2011-04-27 19:09 test

En la primera columna verificamos que tienen el mismo número de inodo y en la tercera se especifica cuando enlaces duros tiene el fichero. Si hacéis cambios en uno de ellos veréis que también se hacen en el resto. Si por ejemplo cambiamos los permisos al fichero test:

$ chmod 0755 test
$ ls -li
73793 -rwxr-xr-x 2 alex alex 5 2011-04-27 19:09 enlace-duro-test
73793 -rwxr-xr-x 2 alex alex 5 2011-04-27 19:09 test

Y finalmente el stat de cada uno verifica todo lo que comentamos:

$ stat test
  File: «test»
  Size: 5         	Blocks: 8          IO Block: 4096   archivo regular
Device: 804h/2052d	Inode: 73793       Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 19:09:51.528132995 +0200
Modify: 2011-04-27 19:09:53.640114896 +0200
Change: 2011-04-27 19:11:42.516138726 +0200

$ stat enlace-duro-test
  File: «enlace-duro-test»
  Size: 5         	Blocks: 8          IO Block: 4096   archivo regular
Device: 804h/2052d	Inode: 73793       Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 19:09:51.528132995 +0200
Modify: 2011-04-27 19:09:53.640114896 +0200
Change: 2011-04-27 19:11:42.516138726 +0200

Diferencias entre soft y hard links

• Los enlaces simbólicos se pueden hacer con ficheros y directorios mientras que los duros solo entre ficheros.
• Los enlaces simbólicos se pueden hacer entre distintos sistemas de ficheros, los duros no.
• Los enlaces duros comparten el número de inodo, los simbólicos no.
• En los enlaces simbólicos si se borra el fichero o directorio original, la información se pierde, en los duros no.
• Los enlaces duros son copias exactas del fichero mientras que los simbólicos son meros punteros o “accesos directos”.

Si se os ocurre alguna diferencia o apunte más no dudéis en comentarlo.

En Unix existen tres bits de permisos especiales que pueden ser asignados a directorios y/o ficheros ejecutables, setuid (set user information), setgid (set group information) y sticky.

setuid

EL bit setuid es asignable a ficheros ejecutables, y permite que cuando un usuario ejecute dicho fichero, el proceso adquiera los permisos del propietario del fichero ejecutado. El ejemplo más claro de fichero ejecutable y con el bit setuid el

.

sirve para ejecutar una shell con identificadores de grupo y de usuario distintos al nuestro, por ello ha de tener este bit y así permitir adquirir al usuario temporalmente permisos administrativos para poder hacer el cambio de usuario.

Podemos ver que el bit está asignado (s) haciendo un ls:

$ ls -l /bin/su
-rwsr-xr-x 1 root root 31012 2009-04-04 07:49 /bin/su

Para asignar este bit a un fichero:

# chmod u+s /bin/su

Y para quitarlo:

# chmod u-s /bin/su

Lógicamente, conviene utilizar este bit con extremo cuidado ya que puede provocar una escalada de privilegios en situaciones inseguras. Para que veáis un ejemplo de lo que se podría hacer.

El usuario “alex” no tiene permisos para ejecutar correctamente un fdisk -l:

alex@linux:~$ fdisk -l

La salida es 0, pero si asignamos el bit setuid al binario de fdisk…

# ls -l /sbin/fdisk
-rwsr-xr-x 1 root root 93048 2009-02-18 20:43 /sbin/fdisk

Probamos de nuevo a ejecutar fdisk con el usuario “alex” y conseguimos privilegios de root:

alex@linux:~$ fdisk -l

Disco /dev/sda: 160.0 GB, 160041885696 bytes
255 cabezas, 63 sectores/pista, 19457 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x000c3c51

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *           1        3232    25959424    7  HPFS/NTFS
/dev/sda2            3233        9683    51817657+  83  Linux
/dev/sda3            9684        9855     1381590   82  Linux swap / Solaris
/dev/sda4            9856       19457    77128065   83  Linux

Luego nos acordamos de volver a quitarlo:

# chmod u-s /sbin/fdisk

setgid

Si el bit setuid permitía que el proceso adquiriera los permisos del propietario del fichero ejecutado, setgid hace lo mismo pero adquiriendo los privilegios del grupo asignado al fichero, también es asignable a directorios. Este bit entonces será muy útil cuando varios usuarios de un mismo grupo necesiten trabajar con recursos dentro de un mismo directorio.

En el siguiente ejemplo asignamos el bit setgid la carpeta /compartido, le asignamos permisos totales para el propietario y el grupo (770) y el bit segid (2):

$ mkdir compartido && chmod 2770 /compartido

Si hacemos un ls veremos el bit asignado:

$ ls -l
drwxrws--- 2 alex alex      4096 2011-04-24 21:27 compartido

Ahora vamos a hacer la prueba de crear un fichero dentro del directorio. Lo vamos a crear estando autenticados como root, pero al tener el bit setgid le asignará el grupo “alex” en lugar de root.

$ su
# touch test
root@sistemas:/home/alex/compartido# ls -l
total 0
-rw-r--r-- 1 root alex 0 2011-04-24 21:28 test
# whoami
root

En lugar de modo octal podéis asignar también los permisos setgid del siguiente modo:

$ chmog g+s /compartido

Y quitarlo:

$ chmog g-s /compartido

sticky

Este bit suele asignarse en directorios a los que todos los usuarios tienen acceso, y permite evitar que un usuario pueda borrar ficheros/directorios de otro usuario dentro de ese directorio, ya que todos tienen permiso de escritura. Seguro que lo estáis pensando, este bit se asigna siempre en /tmp y /var/tmp.

tmp tiene permisos 777, el bit sticky se asignaría del siguiente modo:

# chmod 1777 /tmp

También así:

chmod o+t /tmp

Y para quitarlo:

chmod o-t /tmp

Si hacemos un ls veremos la “t” asignada:

drwxrwxrwt  13 root root  4096 2011-04-24 20:55 tmp

Esta es una visión general de estos tres bits especiales asignables a ficheros ejecutables y directorios en Unix/Linux.

Hoy vamos a ver el modo de gestionar trabajos, procesos o aplicaciones que corren dentro de un sistema Linux/Unix. El objetivo es aprender a poner un proceso que se está ejecutando en segundo plano, suspenderlo, volver a ponerlo en primer plano, reactivarlo, etc.

Ejecutar un trabajo/proceso en segundo plano

Para ejecutar algo en segundo plano, debemos utilizar el carácter & y colocarlo tras el comando o proceso a ejecutar:

$ top &

Os recomiendo también revisar esta entrada sobre el comando nohup.

Visualizar los procesos que se encuentran en segundo plano

Para obtener un listado de los procesos que están ejecutándose en segundo plano utilizaremos el comando

(background). La salida del mismo nos indicará cada uno de los procesos con su número de trabajo asignado entre corchetes.

$ bg
[1]+ top &

Traer a primer plano los procesos que se encuentran en segundo plano

Para ello utilizaremos el comando

(foreground) junto con el ID del trabajo anteponiéndole %:

$ fg %1

Suspender un proceso que tenemos corriendo en primer plano

Si estamos ejecutando un trabajo en pantalla/terminal y queremos suspenderlo colocarlo en segundo plano utilizaremos la combinación de teclas Ctrl + Z. Automáticamente nos asignará el ID de trabajo para poder gestionarlo posteriormente:

top - 21:20:57 up 33 min,  2 users,  load average: 0.99, 0.98, 0.81
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
Cpu(s): 23.0%us,  4.7%sy,  0.0%ni, 70.5%id,  1.6%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:   2052640k total,   948528k used,  1104112k free,    55876k buffers
Swap:  1951888k total,        0k used,  1951888k free,   461444k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                  

  776 root      15  -5     0    0    0 S    0  0.0   0:00.02 kjournald2                                                                                                               

[1]+  Stopped                 top

Para volver a arrancarlo en primer plano después:

$ fg %1

Y para ponerlo en segundo plano:

$ bg %1

Esto es realmente útil en casos como por ejemplo, estamos ejecutando un script que se demora más de lo esperado y necesitamos ejecutarlo sin necesidad de una terminal, lo dejamos en segundo plano y seguirá corriendo sin necesidad de ningún entorno visual. También si solo disponemos de una única terminal y necesitamos realizar varias tareas simultaneamente.

Visualizar los trabajos en primer plano, suspendidos, en segundo plano

El comando

nos permite visualizar un listado de los trabajos en el sistema junto con su estado e identificador:

$ jobs
[1]   Stopped                 top
[2]-  Stopped                 top
[3]+  Stopped                 vim

Un resumen práctico sería el siguiente. Arrancamos un programa (por ejemplo thunderbird) desde línea de comandos:

$ thunderbird

Ocurre que necesitamos pararlo temporalmente. En la terminal desde la que lo hemos lanzado presionamos Ctrl + Z.

Ahora el programa está parado a la espera de ser reactivado cuando queramos:

$ thunderbird
^Z
[1]+  Stopped                 thunderbird
$ jobs
[1]+  Stopped                 thunderbird

Podemos arrancarlo de nuevo pero en segundo plano:

$ bg %1
[1]+ thunderbird &

O en primer plano:

$ fg %1

Recordad que es interesante revisar la ayuda (páginas man y –help) de los comandos para obtener información sobre su utilización y las posibilidades que nos ofrece.

En todas las variantes de Unix tenemos tres flujos estándar que, a modo de canales, conectan la entrada y salida (I/O) de un comando/aplicación con la terminal/consola cuando se ejecuta, son los siguientes:

• standard input (stdin)
• standard output (stdout)
• standard error (stderr)

Vamos a explicar los usos que podemos dar estos tres canales para enviar y recoger los datos que surgen de la ejecución de un script, comando o aplicación.

standard input (stdin)

Stdin, o standard input son los datos que son enviados al programa, quizás cara al usuario de terminal sea el menos utilizado ya que lo normal suele ser interpretar los datos que el programa o comando envía, y no al revés. Normalmente stdin es texto enviado por el usuario, vamos a ver un ejemplo.

En un script en perl, podemos solicitar la interacción del usuario mediante STDIN, por ejemplo en este caso recogemos mediante STDIN el valor de dos variables que el usuario escribe:

#!/usr/bin/perl
print "Introduce tu nombre:\n";
my $nombre = <STDIN>;
print "Introduce tu apellido:\n";
my $apellido = <STDIN>;

Otro ejemplo que se me ocurre es el que puse en la entrada de automatizar comandos FTP, en este caso a la conexión FTP le pasamos de antemano los comandos a ejecutar:

ftp -inv direccion_ip<<FINFTP
comando1
comando2
comando3
FINFTP

standard output (stdout)

A través de la salida estándar, “stdout” se reciben los datos que vuelca el comando o programa durante su ejecución, ejemplos sencillos de stdout serían por ejemplo el resultado de un “ls”,”cat” o cualquier otro comando de terminal. En cambio, hay otros comandos o programas que no muestran salida (a no ser que se especifique), como por ejemplo mover o copiar ficheros. Como ya sabemos cualquiera de estos flujos de datos se puede manipular, vamos a ver un ejemplo  para comprender sus posibilidades.

Si hicieramos un “ls” a una carpeta, la salida de datos (stdout) se muestra en nuestra terminal:

$ ls
backups  cpq    games  local  log   opt  spool  www
cache    crash  lib    lock   mail  run  tmp

Para manipular la salida estándar, utilizaremos el símbolo “>”. Si por ejemplo quisieramos que stdout fuera redirigido a un fichero de texto, haríamos así:

$ ls > fichero.txt

Como podréis comprobar, por pantalla no aparece el resultado del comando, sino que se ha almacenado en el fichero indicado:

$ cat fichero.txt
backups  cpq    games  local  log   opt  spool  www
cache    crash  lib    lock   mail  run  tmp

standard error (stderr)

A través del canal stderr los programas o comandos suelen enviar el informe de error de la ejecución de un comando en caso de fallar. En nuestros scripts o comandos podemos combinar el uso de stdout y stderr para separar la salida estándar de los errores, almacenarlos en registros independientes o manipularlos por separado.

En el siguiente ejemplo vamos a ejecutar un “ls” con parámetros incorrectos, por defecto la salida de errores se volcará en pantalla (terminal):

$ ls -7
ls: opción incorrecta -- '7'
Pruebe `ls --help' para más información.

Si quisieramos almacenar los errores de la ejecución del comando en caso de suceder, podemos volcarlos usando en lugar del símbolo “>” el número 2 seguido de “>”, “2>”:

$ ls -7 2> errores.log

Como podéis ver los errores ya no aparecen por pantalla, pero si abrimos el fichero de log tenemos el registro del fallo:

$ cat errores.log
ls: opción incorrecta -- '7'
Pruebe `ls --help' para más información.

Si quisieramos redirigir tanto el stdout como stderr al mismo sitio, en lugar de especificar dos veces el destino podemos hacerlo del siguiente modo “2>&1″. Vamos a ver un ejemplo

Stdout y stderr a un fichero de log:

$ ls -3 > fichero.log 2>&1

Vamos a ver un ejemplo práctico de mysql. El comando mysqldump vuelca a stdout el dump de una base de datos, seguro que nos es más útil en un fichero que por pantalla, así mismo, si surge algún error nos conviene revisarlo así que lo volcamos a otro fichero distinto de log:

$ mysqldump test > test.sql 2> error.log

Otra opción es querer que tanto stdout como stderr vayan directamente a la basura (/dev/null):

$ ls -l > /dev/null 2>&1

Este es el uso más básico que podemos dar a estos tres importantes flujos estandar Unix, si tenéis cualquier duda podéis consultarla a través de los comentarios.

La automatización de tareas vía FTP dentro de un script, puede resultar muy útil para scripts de copias de seguridad por ejemplo. Vamos a ver la forma de hacerlo y las posibilidades que nos ofrece.

La sintaxis básica para hacer la llamada a FTP dentro de un script en bash es la siguiente:

ftp -inv direccion_ip<<FINFTP
comando1
comando2
comando3
FINFTP

Comenzamos explicando los parámetros que pasamos al binario FTP,

sirve para desactivar el prompt interactivo,

sirve para impedir que se use la auto-autenticación, podéis quitarlo si vais a usar el acceso automático a través de .netrc, finalmente

es para verbose.

Posteriormente, dentro de la llamada a FTP ya se trata de añadir los comandos que cada uno necesite, en el siguiente ejemplo nos conectamos con usuario test y clave t3st al ftp 192.168.0.100 y subimos dos ficheros desde la carpeta local /home/local hacia la carpeta remota /.

#!/bin/bash
ftp -inv 192.168.0.100<<FINFTP
       user test t3st
       binary
       lcd /home/local
       cd /home/download
       put fichero1.txt
       put fichero2.txt
       bye
FINFTP

Una entrada rápida y concisa, si queréis ver un historico de los reinicios de una máquina, ejecutad el comando “last reboot”, mostrará la fecha y hora de los últimos reinicios así como la versión de kernel de la máquina:

~$ last reboot
reboot   system boot  2.6.28-11-generi Fri Oct 23 20:52 - 21:58  (01:06)
reboot   system boot  2.6.28-11-generi Thu Oct 22 23:31 - 23:54  (00:23)
reboot   system boot  2.6.28-11-generi Thu Oct 22 21:05 - 23:18  (02:13)

Recordad que el comando “last” tiene más utilidades, como por ejemplo ver los últimos accesos a la máquina, simplemente ejecutad “last”:

~$ last
alex     pts/1        :0.0             Fri Oct 23 21:56   still logged in
alex     pts/0        :0.0             Fri Oct 23 21:54 - 21:58  (00:04)
alex     pts/0        :0.0             Fri Oct 23 21:40 - 21:47  (00:06)
alex     tty7         :0               Fri Oct 23 20:52   still logged in

Un truco rápido con el comando Unix tr, vamos a convertir las letras mayúsculas a minúsculas de un fichero.

Fichero test.txt:

$ cat test.txt
minusculas
MAYUSCULAS

Convertir mayúsculas en minúsculas del fichero test.txt:

$ cat test.txt | tr [:upper:] [:lower:]
minusculas
mayusculas

Convertir minúsculas en mayúsculas del fichero test.txt:

$ cat test.txt | tr [:lower:] [:upper:]
MINUSCULAS
MAYUSCULAS

Por supuesto, el comando tr nos ofrece muchas más opciones para transformación de carácteres, os dejo la ayuda del comando, recordad que en las páginas man hay mucha más información.

$ tr --help
Modo de empleo: tr [OPCIÓN]... CONJUNTO1 [CONJUNTO2]
Traducir, comprimir, y/o borrar caracteres de la entrada estándar,
escribiendo a la  entrada estándar.

  -c, -C, --complement    primer compliment SET1
  -d, --delete            borrar caracteres en SET1, no traducir
  -s, --squeeze-repeats   reemplazar cada secuencia de entradas de un caracter repetido
                            esta es una lista de SET1 con una sóla coincidencia
                            de ese caracter
  -t, --truncate-set1     primero truncar SET1 a la longitud de SET2
      --help     muestra esta ayuda y finaliza
      --version  informa de la versión y finaliza

Los CONJUNTOs se especifican como cadenas de caracteres. La mayoría se
representan a sí mismos.
Las secuencias válidas son las siguientes:

  \NNN            carácter con valor octal NNN (de uno a tres dígitos)
  \\              barra invertida
  \a              pitido audible (BEL)
  \b              espacio hacia atrás
  \f              salto de página
  \n              salto de línea
  \r              retorno de carro
  \t              tabulación horizontal
  \v              tabulación vertical
  CAR1-CAR2       todos los caracteres comprendidos entre CAR1 y CAR2 contados
                  en orden ascendente
  [CAR*]          en CONJUNTO2, copias de CAR hasta que se alcance la longitud
                  de CONJUNTO1
  [CAR*REPITE]    copia REPITE veces CAR; REPITE es octal si comienza con 0
  [:alnum:]       todas las letras y dígitos
  [:alpha:]       todas las letras
  [:blank:]       todos los espacios en blanco horizontales
  [:cntrl:]       todos los caracteres de control
  [:digit:]       todos los dígitos
  [:graph:]       todos los caracteres imprimibles, sin incluir el espacio
  [:lower:]       todas las letras minúsculas
  [:print:]       todos los caracteres imprimibles, incluyendo el espacio
  [:punct:]       todos los caracteres de puntuación
  [:space:]       todos los espacios en blanco horizontales y verticales
  [:upper:]       todas las letras mayúsculas
  [:xdigit:]      todos los números hexadecimales
  [=CAR=]         todos los caracteres que son igual que CAR

Se produce la traducción si no se especifican CONJUNTO1 y CONJUNTO2, siempre
y cuando no aparezca la opción -d. -t se puede usar sólo al traducir.
CONJUNTO2 se expande a la longitud de CONJUNTO1, repitiendo su último
carácter tantas veces como sea necesario.  Los caracteres que sobran en
CONJUNTO2 no se tienen en cuenta. Solamente se garantiza que [:lower:]
y [:upper:] sean expandidos en orden ascendente; si se usa en
CONJUNTO2 al traducir, sólo se pueden usar en parejas, para
especificar conversión a mayúsculas.  -s usa CONJUNTO1 si no se está
traduciendo ni borrando; si no, la compresión usa CONJUNTO2 después de
la traducción o el borrado.

El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. Wikipedia

Vamos a suponer que tenemos montado un servidor con comparticiones NFS (otro día explicaré detalladamente como se monta un servidor NFS). En el caso de querer conectarnos a ese sistema de ficheros desde un equipo remoto (cliente), tendremos que hacerlo del siguiente modo:

mount host:/comparticion /punto/de/montaje

En el ejemplo encontramos:

• Host: IP o FQDN del servidor que está compartiendo vía NFS
• /compartición: Ruta que comparte el servidor NFS
• /punto/de/montaje: Lugar en el que queremos montar la compartición NFS (Punto de montaje)

Un ejemplo real podría ser:

$ mkdir /mnt/compartido
$ mount 192.168.0.199:/home/compartido /mnt/compartido

Una vez realizado, si hacemos un df veremos que efectivamente la unidad ha sido montada satisfactoriamente, y tenemos acceso a ella a través de /mnt/compartido. Para que esto se mantenga tras el reinicio de la máquina, hemos de incluir la línea correspondiente en el fichero /etc/fstab. Por ejemplo, para el ejemplo anterior añadiríamos una línea similar a lo que sigue.

La estructura de la línea es la siguiente:

<server>:</path/of/dir> </local/mnt/point> nfs <options> 0 0

Y en nuestro ejemplo (con opcion de read-write, lectura escritura):

192.168.0.199:/home/compartido /mnt/compartido nfs rw 0 0

Recomiendo no obstante revisar la documentación de Red-Hat pues detallan de forma extensa y muy buena todas las opciones disponibles.

Próximamente montaremos un servidor NFS desde cero.