Daemons NFS

Para admitir las actividades NFS, varios daemons se inician cuando un sistema entra en el nivel de ejecución 3 o el modo multiusuario. Los deaemons mountd y nfsd se ejecutan en sistemas que son servidores. El inicio automático de los daemons del servidor depende de la existencia de entradas etiquetadas con el tipo de sistema de archivos NFS en /etc/dfs/sharetab. Para admitir el bloqueo de archivos NFS, los daemons lockd y statd se ejecutan en los clientes y servidores NFS. Sin embargo, a diferencia de las versiones anteriores de NFS, en NFS versión 4, los daemons lockd, statd, mountd y nfslogd no se utilizan.

Esta sección describe los siguientes daemons.

• Daemon automountd

• Daemon lockd

• Daemon mountd

• Daemon nfs4cbd

• Daemon nfsd

• Daemon nfslogd

• Daemon nfsmapid

• Daemon statd

Daemon automountd

Este daemon gestiona el montaje y desmontaje de las solicitudes del servicio autofs. La sintaxis del comando es la siguiente:

automountd [ -Tnv ] [ -D name= valor ]

El comando se comporta de las siguientes formas:

• -T habilita el seguimiento.

• -n deshabilita la exploración en todos los nodos de autofs.

• -v selecciona registrar todos los mensajes de estado en la consola.

• -D nombre=valor sustituye el valor por la variable de mapa de montaje automático que se indica mediante nombre.

El valor por defecto para el mapa de montaje automático es /etc/auto_master. Utilice la opción -T para la resolución de problemas.

Daemon lockd

Este daemon admite las operaciones de bloqueo de registro en archivos NFS. El daemon lockd administra las conexiones RPC entre el cliente y el servidor para el protocolo de administrador de bloqueo de red (NLM). Normalmente, el daemon se inicia sin opciones. Con este comando puede utilizar tres opciones. Consulte la página del comando man lockd(1M). Estas opciones pueden utilizarse desde la línea de comandos o editando la cadena correspondiente en /etc/default/nfs. A continuación, se muestran descripciones de palabras clave que se pueden establecer en el archivo /etc/default/nfs.

Como LOCKD_GRACE_PERIOD , GRACE_PERIOD=período_gracia en /etc/default/nfs establece la cantidad de segundos que deben transcurrir después del reinicio de un servidor para que el cliente reclame los bloqueos de NFS versión 3, proporcionados por NLM, y los bloqueos de la versión 4. Por lo tanto, el valor para GRACE_PERIOD controla la duración del período de gracia para la recuperación del bloqueo, para las versiones 3 y 4 de NFS.

El parámetro LOCKD_RETRANSMIT_TIMEOUT=tiempo_espera en /etc/default/nfs selecciona la cantidad de segundos que se debe esperar antes de retransmitir una solicitud de bloqueo al servidor remoto. Esta opción afecta al servicio NFS por parte del cliente. El valor predeterminado para tiempo_espera es 15 s. Si disminuye el valor de tiempo_espera, puede mejorar el tiempo de respuesta para los clientes NFS en una red “con ruido”. Sin embargo, este cambio puede provocar una carga adicional del servidor al aumentar la frecuencia de solicitudes de bloqueo. El mismo parámetro se puede utilizar desde la línea de comandos iniciando el daemon con la opción -t tiempo_espera.

El parámetro LOCKD_SERVERS= nthreads en /etc/default/nfs especifica el número máximo de subprocesos simultáneos que el servidor maneja por conexión. Base el valor para nthreads en la carga que se espera para el servidor NFS. El valor predeterminado es 20. Cada cliente NFS que utiliza TCP utiliza una sola conexión con el servidor NFS. Por lo tanto, cada cliente puede utilizar un máximo de 20 subprocesos simultáneos en el servidor.

Todos los clientes NFS que utilizan UDP comparten una única conexión con el servidor NFS. En estas condiciones, puede que tenga que aumentar el número de subprocesos que están disponibles para la conexión UDP. Un cálculo mínimo sería permitir dos subprocesos para cada cliente UDP. Sin embargo, este número es específico para la carga de trabajo en el cliente, por lo que dos subprocesos por cliente podría no ser suficiente. La desventaja frente al uso de más subprocesos es que cuando se usan los subprocesos, se usa más memoria en el servidor NFS. Sin embargo, si nunca se utilizan los subprocesos, aumentar nthreads no tiene ningún efecto. Se puede utilizar el mismo parámetro desde la línea de comandos al iniciar el daemon con la opción nthreads.

Daemon mountd

Este daemon gestiona solicitudes de montaje de sistema de archivos desde sistemas remotos y proporciona control de acceso. El daemon mountd comprueba /etc/dfs/sharetab para determinar qué sistemas de archivos están disponibles para el montaje remoto y qué sistemas están autorizados a hacer el montaje remoto. Puede utilizar la opción -v y la opción -r con este comando. Consulte la página del comando man mountd(1M).

La opción -v ejecuta el comando en modo detallado. Cada vez que un servidor NFS determina el acceso que se debe otorgar a un cliente, se imprime un mensaje en la consola. La información que se genera puede ser útil al intentar determinar por qué un cliente no puede acceder a un sistema de archivos.

La opción -r rechaza todas las solicitudes de montaje futuras de los clientes. Esta opción no afecta a los clientes que ya tienen un sistema de archivos montado.

Daemon nfs4cbd

nfs4cbd, que es para el uso exclusivo del cliente NFS versión 4, gestiona los puntos finales de comunicación para el programa de devolución de llamadas de NFS versión 4. El daemon no tiene ninguna interfaz accesible para el usuario. Para obtener más información, consulte la página del comando mannfs4cbd(1M).

Daemon nfsd

Este daemon gestiona otras solicitudes de sistema de archivos de cliente. Con este comando puede utilizar varias opciones. Consulte la página del comando man nfsd(1M) para ver una lista completa. Estas opciones pueden utilizarse desde la línea de comandos o editando la cadena correspondiente en /etc/default/nfs.

El parámetro NFSD_LISTEN_BACKLOG=longitud en /etc/default/nfs ajusta la duración de la cola de conexión sobre transportes orientados a la conexión para NFS y TCP. El valor predeterminado es de 32 entradas. La misma selección se puede realizar desde la línea de comandos al iniciar nfsd con la opción -l.

El parámetro NFSD_MAX_CONNECTIONS=#-conn en /etc/default/nfs selecciona el número máximo de conexiones por transporte orientado a la conexión. El valor por defecto para #-conn es ilimitado. El mismo parámetro se puede utilizar desde la línea de comandos al iniciar el daemon con la opción -c #-conn.

El parámetro NFSD_SERVER=nservers en /etc/default/nfs selecciona el número máximo de solicitudes simultáneas que un servidor puede manejar. El valor predeterminado para nservers es 16. La misma selección se puede realizar desde la línea de comandos al iniciar nfsd con la opción nservers.

A diferencia de las versiones anteriores de este daemon, nfsd no reproduce varias copias para manejar solicitudes simultáneas. Al comprobar la tabla de procesos con ps, sólo se muestra una copia del daemon en ejecución.

Daemon nfslogd

Este daemon proporciona el registro operativo. Las operaciones de NFS que se registran con un servidor están basadas en las opciones de configuración que se definen en /etc/default/nfslogd. Cuando el registro del servidor NFS está habilitado, el núcleo escribe en un archivo de memoria intermedia los registros de todas las operaciones de RPC en un sistema de archivos seleccionado. A continuación nfslogd realiza el posprocesamiento de estas solicitudes. El cambio de servicio de nombres se utiliza para ayudar a asignar UID a inicios de sesión y direcciones IP a nombres de host. Si no se puede encontrar ninguna coincidencia a través de los servicios de nombres identificados, el número se registra.

El comando nfslogd también se encarga de la asignación de los identificadores de archivo para los nombres de ruta. El daemon realiza un seguimiento de estas asignaciones en una tabla de asignaciones de identificador de archivo a ruta. Existe una tabla de asignaciones para cada etiqueta identificada en /etc/nfs/nfslogd. Después del procesamiento posterior, los registros se escriben en archivos de registro ASCII.

Daemon nfsmapid

La versión 4 del protocolo NFS (RFC3530) ha cambiado la forma en que los identificadores de usuarios o grupos (UID o GID) son intercambiados entre el cliente y el servidor. El protocolo exige que el cliente NFS versión 4 y el servidor NFS versión 4 intercambien los atributos de grupo y propietario de archivo como cadenas con el formato usuario@nfsv4_domain o grupo@nfsv4_domain respectivamente.

Por ejemplo, el usuario known_user tiene el UID 123456 en un cliente NFS versión 4 cuyo nombre de host completo es system.example.com. Para que el cliente pueda realizar solicitudes al servidor NFS versión 4, el cliente debe asignar el UID 123456 a known_user@example.com y, a continuación, enviar este atributo al servidor NFS versión 4. El servidor NFS versión 4 espera recibir los atributos de archivo de grupo y usuario en el formato user_or_group@nfsv4_domain. Después de que el servidor recibe known_user@example.com desde el cliente, el servidor asigna la cadena al UID 123456 local, que es entendida por el sistema de archivos subyacente. Esta funcionalidad asume que cada UID y GID en la red es único y que los dominios NFS versión 4 en el cliente coinciden con los dominios NFS versión 4 en el servidor.

El cliente y el servidor NFS versión 4 son capaces de realizar conversiones de entero a cadena y de cadena a entero. Por ejemplo, en respuesta a una operación GETATTR, el servidor NFS versión 4 asigna los UID y GID obtenidos del sistema de archivos subyacente en sus respectivas representaciones en una cadena y envía esta información al cliente. Asimismo, el cliente debe también asignar los UID y GID a representaciones de cadenas. Por ejemplo, en respuesta al comando chown, el cliente asigna los nuevos UID o GID a una representación de cadena antes de enviar una operación SETATTR al servidor.

Tenga en cuenta, sin embargo, que el cliente y el servidor responden diferente ante cadenas no reconocidas:

• Si el usuario no existe en el servidor, incluso dentro de la misma configuración de dominio NFS versión 4, el servidor rechaza la llamada de procedimiento remoto (RPC) y devuelve un mensaje de error al cliente. Esta situación limita las operaciones que puede realizar el usuario remoto.

• Si el usuario existe en el cliente y en el servidor, pero los dominios no coinciden, el servidor rechaza las operaciones de modificación de atributo (por ejemplo, SETATTR) que necesitan que el servidor asigne la cadena de usuario entrante en un valor entero que el sistema de archivos subyacente pueda comprender. Para que los clientes y servidores NFS versión 4 funcionen adecuadamente, sus dominios NFS versión 4, la parte de la cadena después del signo @, deben coincidir.

• Si el cliente NFS versión 4 no reconoce un usuario o nombre de grupo obtenido del servidor, el cliente no puede asignar la cadena a su ID exclusivo, un valor de entero. En estas circunstancias, el cliente asigna la cadena de usuario o grupo entrante al usuario nobody. Esta asignación a nobody crea distintos problemas para aplicaciones diferentes. Para la funcionalidad NFS versión 4, fallarán las operaciones que modifican los atributos de archivo.

Puede cambiar el nombre de dominio de los clientes y servidores mediante el comando sharectl con la opción siguiente.

nfsmapid_domain

Establece un dominio común para clientes y servidores. Sustituye el comportamiento predeterminado de utilizar el nombre de dominio DNS local. Para obtener información sobre las tareas, consulte Configuración de servicios NFS.

Archivos de configuración y nfsmapid

A continuación se describe cómo el daemon nfsmapid utiliza los archivos /etc/nsswitch.conf y /etc/resolv.conf:

• nfsmapid utiliza funciones de biblioteca estándar de C para solicitar contraseña e información de grupo desde servicios de nombres en segundo plano. Estos servicios de nombres están controlados por los valores del archivo /etc/nsswitch.conf. Los cambios en el archivo nsswitch.conf afectan las operaciones nfsmapid. Para obtener más información acerca del archivo nsswitch.conf, consulte la página del comando man nsswitch.conf(4).

• Para asegurarse de que los clientes NFS versión 4 sean capaces de montar sistemas de archivos de diferentes dominios, nfsmapid se basa en la configuración del registro de recursos DNS TXT (RR), _nfsv4idmapdomain. Para obtener más información sobre la configuración del registro de recursos _nfsv4idmapdomain, consulte Comando nfsmapid y registros DNS TXT. También, tenga en cuenta lo siguiente:

  • El DNS TXT RR debe estar configurado explícitamente en el servidor DNS con la información de dominio deseada.

  • El archivo /etc/resolv.conf debe estar configurado con los parámetros deseados a fin de habilitar el comando resolver para que encuentre el servidor DNS y busque en los registros TXT los dominios NFS versión 4 para el cliente y el servidor.

  Para obtener más información, consulte lo siguiente:

  • Reglas de precedencia

  • Configuración del dominio predeterminado NFS versión 4

  • Página del comando man resolv.conf(4)

Reglas de precedencia

Para que nfsmapid funcione correctamente, los clientes y servidores NFS versión 4 deben tener el mismo dominio. Para garantizar la coincidencia de los dominios NFS versión 4, nfsmapid sigue estas estrictas reglas de precedencia:

1. El daemon primero comprueba el archivo /etc/default/nfs para ver si contiene un valor que se haya asignado a la palabra clave NFSMAPID_DOMAIN. Si se encuentra un valor, dicho valor asignado cobra importancia con respecto a cualquier otra preferencia. El valor asignado se anexa a las cadenas de atributos salientes y se compara con las cadenas de atributos entrantes. Para obtener más información sobre las palabras clave en el archivo /etc/default/nfs, consulte Palabras clave para el archivo /etc/default/nfs. Para obtener información de procedimiento, consulte Configuración de servicios NFS.

   ---

   Nota - El uso de la configuración NFSMAPID_DOMAIN no es ampliable y no se recomienda para grandes implementaciones.

   ---

2. Si no se asignó ningún valor a NFSMAPID_DOMAIN, el daemon busca un nombre de dominio desde un DNS TXT RR. nfsmapid se basa en directivas en el archivo /etc/resolv.conf que son utilizadas por el conjunto de rutinas en el comando resolver. El comando resolver busca el TXT RR _nfsv4idmapdomain a través de los servidores DNS configurados. Tenga en cuenta que el uso de registros DNS TXT es más ampliable. Por este motivo, el uso continuo de los registros TXT se prefiere más que la definición de la palabra clave en el archivo /etc/default/nfs.

3. Si ningún registro DNS TXT se ha configurado para proporcionar un nombre de dominio, el daemon nfsmapid utiliza el valor especificado por las directivas domain o search en el archivo /etc/resolv.conf , y la directiva se especifica como la última precedencia.

   En el ejemplo siguiente, donde se utilizan las directivas domain y search, el daemon nfsmapid utiliza el primer dominio que se muestra después de la directiva search, que es company.com.

   domain example.company.com
   search company.com foo.bar.com

4. Si el archivo /etc/resolv.conf no existe, nfsmapid obtiene el nombre del dominio NFS versión 4 siguiendo el comportamiento del comando domainname. En concreto, si el archivo /etc/defaultdomain existe, nfsmapid utiliza el contenido de dicho archivo para el dominio NFS versión 4. Si el archivo /etc/defaultdomain no existe, nfsmapid utiliza el nombre de dominio que ofrece el servicio de nombres configurado de la red. Para obtener más información, consulte la página del comando man domainname(1M).

Comando nfsmapid y registros DNS TXT

La naturaleza ubicua de DNS proporciona un almacenamiento eficiente y un mecanismo de distribución para el nombre de dominio NFS versión 4. Además, debido a la inherente escalabilidad de DNS, el uso de registros de recursos DNS TXT es el método preferido para configurar el nombre de dominio NFS versión 4 para grandes implementaciones. Debe configurar el registro TXT _nfsv4idmapdomain en los servidores DNS del nivel de la empresa. Dichas configuraciones aseguran que cualquier cliente o servidor NFS versión 4 pueda encontrar su dominio NFS versión 4 al atravesar el árbol DNS.

El siguiente es un ejemplo de una entrada preferida para habilitar el servidor DNS a fin de proporcionar el nombre de dominio NFS versión 4:

_nfsv4idmapdomain        IN        TXT            "foo.bar"

En este ejemplo, el nombre de dominio para configurar es el valor entre comillas dobles. Tenga en cuenta que no se especifica ningún campo ttl y que no se anexa ningún dominio a _nfsv4idmapdomain, que es el valor en el campo owner. Esta configuración permite que el registro TXT utilice la entrada ${ORIGEN} de la zona del registro de inicio de autoridad (SOA). Por ejemplo, en diferentes niveles del espacio de nombres de dominio, el registro puede ser el siguiente:

_nfsv4idmapdomain.subnet.yourcorp.com.    IN    TXT    "foo.bar"
_nfsv4idmapdomain.yourcorp.com.           IN    TXT    "foo.bar"

Esta configuración proporciona a los clientes DNS la flexibilidad de utilizar el archivo resolv.conf para buscar hacia arriba en la jerarquía del árbol DNS. Consulte la página del comando man resolv.conf(4). Esta capacidad proporciona una mayor probabilidad de encontrar el registro TXT. Para más flexibilidad, los subdominios de DNS de nivel inferior pueden definir sus propios registros de recursos DNS TXT (RR). Esta capacidad le permite a los subdominios DNS de nivel inferior sustituir el registro TXT definido por el dominio DNS de nivel superior.

Comprobación del dominio NFS versión 4

Antes de asignar un valor para el dominio NFS versión 4 de la red, compruebe si un dominio NFS versión 4 ya se ha configurado para su red. Los siguientes ejemplos proporcionan formas de identificar los dominios NFS versión 4.

• Para identificar el dominio NFS versión 4 desde un DNS TXT RR, utilice los comandos nslookup o dig.

  A continuación se proporciona un ejemplo de resultado del comando nslookup:

  # nslookup -q=txt _nfsv4idmapdomain
  Server:         10.255.255.255
  Address:        10.255.255.255#53
  
  _nfsv4idmapdomain.example.company.com text = "company.com"

  Consulte este ejemplo de resultado para el comando dig:

  # dig +domain=example.company.com -t TXT _nfsv4idmapdomain
  ...
  ;; QUESTION SECTION:
  ;_nfsv4idmapdomain.example.company.com. IN    TXT
  
  ;; ANSWER SECTION:
  _nfsv4idmapdomain.example.company.com. 21600 IN TXT   "company.com"
  
  ;; AUTHORITY SECTION:
  ...

  Para obtener información sobre la configuración de un DNS TXT RR, consulte Comando nfsmapid y registros DNS TXT.

• Si la red no está configurada con un DNS TXT RR de NFS versión 4, utilice el siguiente comando para identificar el dominio NFS versión 4 del nombre de dominio DNS:

  # egrep domain /etc/resolv.conf
  domain example.company.com

• Si el archivo /etc/resolv.conf no está configurado para proporcionar un nombre de dominio DNS para el cliente, utilice el siguiente comando para identificar el dominio desde la configuración de dominio NFS versión 4 de la red:

  # cat /var/run/nfs4_domain
  company.com

• Si utiliza otro servicio de nombres, como NIS, utilice el siguiente comando para identificar el dominio para el servicio de asignación de nombres configurado para su red:

  # domainname
  it.example.company.com

Para obtener más información, consulte las páginas del comando man:

• nslookup(1M)

• dig(1M)

• resolv.conf(4)

• domainname(1M)

Configuración del dominio predeterminado NFS versión 4

En esta sección se describe cómo la red obtiene el dominio predeterminado que desee:

• Para la mayoría de las versiones actuales, consulte Configuración de un dominio predeterminado NFS versión 4.

• Para la primera versión de Solaris 10, consulte Configuración de un dominio predeterminado NFS versión 4 en la versión Solaris 10.

Configuración de un dominio predeterminado NFS versión 4

En la primera versión de Solaris 10, el dominio se definía durante el primer reinicio del sistema, después de instalar el SO. En versiones posteriores, el dominio NFS versión 4 se define durante la instalación del SO. Para proporcionar esta funcionalidad, se han agregado las siguientes funciones:

• El comando sysidtool incluye el programa sysidnfs4. Este programa se ejecuta durante el proceso de instalación para establecer si la red tiene configurado un dominio NFS versión 4. Consulte las páginas del comando man sysidtool(1M) y sysidnfs4(1M).

• El archivo sysidcfg tiene una nueva palabra clave, nfs4_domain. Esta palabra clave se puede utilizar para definir el dominio NFS versión 4. Tenga en cuenta que otras palabras clave también se pueden definir en el archivo sysidcfg. Consulte la página del comando man sysidcfg(4).

A continuación se describe cómo opera la funcionalidad:

1. El programa sysidnfs4 comprueba el archivo /etc/.sysIDtool.state para determinar si se ha identificado un dominio NFS versión 4.

   • Si el archivo .sysIDtool.state muestra que un dominio NFS versión 4 se ha configurado para la red, el programa sysidnfs4 no realiza controles complementarios. Vea el siguiente ejemplo de un archivo .sysIDtool.state:

     1       # System previously configured?
     1       # Bootparams succeeded?
     1       # System is on a network?
     1       # Extended network information gathered?
     1       # Autobinder succeeded?
     1       # Network has subnets?
     1       # root password prompted for?
     1       # locale and term prompted for?
     1       # security policy in place
     1       # NFSv4 domain configured
     xterms

     El 1 que aparece antes de # NFSv4 domain configured confirma que el dominio NFS versión 4 se ha configurado.

   • Si el archivo .sysIDtool.state muestra que no se ha configurado ningún dominio NFS versión 4 para la red, el programa sysidnfs4 debe hacer más comprobaciones. Vea el siguiente ejemplo de un archivo .sysIDtool.state:

     1       # System previously configured?
     1       # Bootparams succeeded?
     1       # System is on a network?
     1       # Extended network information gathered?
     1       # Autobinder succeeded?
     1       # Network has subnets?
     1       # root password prompted for?
     1       # locale and term prompted for?
     1       # security policy in place
     0       # NFSv4 domain configured
     xterms

     El 0 que aparece antes de # NFSv4 domain configured confirma que el dominio NFS versión 4 no se ha configurado.

2. Si no hay ningún dominio NFS versión 4 identificado, el programa sysidnfs4 comprueba la palabra clave nfs4_domain en el archivo sysidcfg.

   • Si un valor para nfs4_domain existe, ese valor se asigna a la palabra clave NFSMAPID_DOMAIN en el archivo /etc/default/nfs. Tenga en cuenta que cualquier valor asignado a NFSMAPID_DOMAIN sustituye la capacidad de selección de dominios dinámica del daemonnfsmapid. Para obtener más información sobre la capacidad de selección de dominios dinámica de nfsmapid, consulte Reglas de precedencia.

   • Si no hay ningún valor para nfs4_domain, el programa sysidnfs4 identifica el dominio que nfsmapid deriva de los servicios de nombres configurados del sistema operativo. Este valor derivado se presenta como un dominio predeterminado en una solicitud interactiva que le ofrece la opción de aceptar el valor predeterminado o asignar otro dominio NFS versión 4.

Esta funcionalidad hace que lo siguiente sea obsoleto:

• La secuencia de comandos de ejemplo JumpStart, set_nfs4_domain, que se proporcionó en la distribución de medios inicial de Solaris 10 ya no es necesaria y se desaconseja.

• El archivo /etc/.NFS4inst_state.domain, creado por la implementación anterior del programa sysidnfs4, ya no es necesario.

Para obtener información específica sobre el proceso de instalación de Solaris, consulte lo siguiente:

• Guía de instalación de Oracle Solaris 10 9/10: instalaciones básicas

• Guía de instalación de Oracle Solaris 10 9/10: instalaciones basadas en red

Configuración de un dominio predeterminado NFS versión 4 en la versión Solaris 10

En la primera versión de Solaris 10 de NFS versión 4, si la red incluye varios dominios DNS, pero sólo tiene un solo espacio de nombre UID y GID, todos los clientes deben utilizar un valor para NFSMAPID_DOMAIN. Para los sitios que usen DNS, nfsmapid resuelve este problema al obtener el nombre del dominio a partir del valor asignado a _nfsv4idmapdomain. Para obtener más información, consulte Comando nfsmapid y registros DNS TXT. Si la red no está configurada para usar DNS, durante el primer inicio del sistema, el SO usa la utilidad sysidconfig(1M) para proporcionar las siguientes solicitudes para un nombre de dominio de NFS versión 4:

This system is configured with NFS version 4, which uses a 
domain name that is automatically derived from the system's 
name services. The derived domain name is sufficient for most 
configurations. In a few cases, mounts that cross different 
domains might cause files to be owned by nobody due to the 
lack of a common domain name.

Do you need to override the system's default NFS verion 4 domain 
name (yes/no)? [no]

La respuesta predeterminada es [no]. Si selecciona [no], puede ver lo siguiente:

For more information about how the NFS version 4 default domain name is 
derived and its impact, refer to the man pages for nfsmapid(1M) and 
nfs(4), and the System Administration Guide: Network Services.

Si selecciona [sí], verá esta solicitud:

Enter the domain to be used as the NFS version 4 domain name.
NFS version 4 domain name []:

Información adicional sobre nfsmapid

Para obtener más información sobre nfsmapid, consulte lo siguiente:

• Página del comando man nfsmapid(1M)

• Página del comando man nfs(4)

• http://www.ietf.org/rfc/rfc1464.txt

• ACL y nfsmapid en NFS versión 4

Daemon statd

Este daemon trabaja con lockd para proporcionar funciones de bloqueo y recuperación para el administrador de bloqueo. El daemon statd realiza un seguimiento de los clientes que mantienen bloqueos en un servidor NFS. Si un servidor se bloquea, al reiniciar statd en el servidor, se contacta statd en el cliente. El cliente statd entonces puede intentar reclamar cualquier bloqueo en el servidor. El cliente statd también informa al servidor statd cuando un cliente se ha bloqueado a fin de que se puedan borrar los bloqueos del cliente en el servidor. No tiene opciones para seleccionar con este daemon. Para obtener más información, consulte la página del comando man statd(1M).

En la versión 7 de Solaris, se ha mejorado la forma en la que statd realiza un seguimiento de los clientes. En todas las versiones anteriores de Solaris, statd creaba archivos en /var/statmon/sm para cada cliente mediante el nombre de host no completo del cliente. Esta nomenclatura de archivos causaba problemas si disponía de dos clientes en diferentes dominios que compartían un nombre de host o si los clientes no residían en el mismo dominio que el servidor NFS. Como el nombre de host no completo sólo contiene el nombre de host, sin ningún dominio ni información de dirección IP, la versión anterior de statd no tenía forma de diferenciar entre estos tipos de clientes. Para solucionar este problema, statd de Solaris 7 crea un enlace simbólico en /var/statmon/sm al nombre de host no completo mediante la dirección IP del cliente. El nuevo enlace se parece a lo siguiente:

# ls -l /var/statmon/sm
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv4.192.168.255.255 -> myhost
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host
--w-------   1 daemon          11 Apr 29 16:32 myhost
--w-------   1 daemon          11 Apr 29 16:32 v6host

En este ejemplo, el nombre del host del cliente es myhost y la dirección IP del cliente es 192.168.255.255. Si otro host con el nombre myhost estaba montando un sistema de archivos, dos enlaces simbólicos darían lugar al nombre del host.