Solución de problemas de recursos compartidos de archivos NFS de Azure
Nota:
CentOS al que se hace referencia en este artículo es una distribución de Linux y llegará al final del ciclo de vida (EOL). Tenga en cuenta su uso y planifique en consecuencia. Para obtener más información, consulte Guía de fin de vida de CentOS.
En este artículo se enumeran algunos problemas comunes relacionados con los recursos compartidos de archivos NFS de Azure y se proporcionan posibles causas y soluciones alternativas.
Importante
El contenido de este artículo solo se aplica a los recursos compartidos de archivos NFS. Para solucionar problemas de SMB en Linux, consulte Solución de problemas de Azure Files en Linux (SMB). Los recursos compartidos de archivos NFS de Azure no se admiten para Windows.
Se aplica a
Tipo de recurso compartido de archivos | SMB | NFS |
---|---|---|
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS | ||
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS | ||
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS |
Error en chgrp "nombre de archivo": argumento no válido (22)
Causa 1: idmapping no está deshabilitado
Dado que Azure Files no permite UID o GID alfanuméricos, debe deshabilitar idmapping.
Causa 2: idmapping estaba deshabilitado, pero se volvió a habilitar tras encontrar un nombre de archivo o de directorio incorrecto
Incluso si deshabilita correctamente idmapping, se puede volver a habilitar automáticamente en algunos casos. Por ejemplo, cuando Azure Files encuentra un nombre de archivo incorrecto, devuelve un error. Al ver este código de error, el cliente de Linux de NFS v4.1 decide volver a habilitar idmapping y envía las solicitudes futuras con UID/GID alfanuméricos. Para obtener una lista de los caracteres no admitidos en Azure Files, consulte este artículo. El carácter de los dos puntos es uno de los caracteres no admitidos.
Solución alternativa
Asegúrese de haber deshabilitado idmapping y de que no haya nada que vuelva a habilitarlo. A continuación, realice los pasos siguientes:
Desmonte el recurso compartido.
Deshabilite idmapping con:
sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
Vuelva a montar el recurso compartido.
Si ejecuta rsync, ejecute rsync con el
—numeric-ids
argumento de un directorio que no tenga un directorio o un nombre de archivo incorrectos.
No se puede crear un recurso compartido de NFS
Causa: Configuración de la cuenta de almacenamiento no admitida
NFS solo está disponible en las cuentas de almacenamiento con la siguiente configuración:
- Nivel: Prémium
- Tipo de cuenta: FileStorage
- Regiones: lista de las regiones admitidas
Solución
Siga las instrucciones de Cómo crear un recurso compartido de archivos NFS.
No se puede conectar o montar un recurso compartido de archivos NFS de Azure
Causa 1: La solicitud se origina desde un cliente en una red o una IP que no son de confianza
A diferencia de SMB, la autenticación de NFS no se basa en el usuario. La autenticación de un recurso compartido se basa en la configuración de la regla de seguridad de red. Por eso, para tener la certeza de que los clientes solo establezcan conexiones seguras con su recurso compartido de archivos NFS, debe usar el punto de conexión de servicio o los puntos de conexión privados. Para acceder a los recursos compartidos desde un entorno local, además de los puntos de conexión privados, debe configurar una VPN o ExpressRoute. Se han omitido las direcciones IP agregadas a la lista de permitidos de la cuenta de almacenamiento para el firewall. Debe usar uno de los siguientes métodos para configurar el acceso a un recurso compartido de NFS:
-
Se accede a través del punto de conexión público.
Solo está disponible en la misma región.
No se puede usar el emparejamiento de VNet para acceder a los recursos compartidos.
Cada red virtual o subred debe agregarse individualmente a la lista de permitidos.
Para el acceso local, puede usar puntos de conexión de servicio con ExpressRoute y conexiones de sitio a sitio y de punto a sitio. Se recomienda usar un punto de conexión privado porque es más seguro.
En el diagrama siguiente se muestra la conectividad mediante puntos de conexión públicos:
-
El acceso es más seguro que con el punto de conexión de servicio.
El acceso al recurso compartido de archivos NFS a través de un vínculo privado está disponible desde y hacia la región de Azure de la cuenta de almacenamiento (entre regiones o local).
El emparejamiento de red virtual con redes virtuales hospedadas en el punto de conexión privado proporciona acceso al recurso compartido de archivos NFS a los clientes en las redes virtuales emparejadas.
Se pueden usar puntos de conexión privados con ExpressRoute y conexiones de punto a sitio y de sitio a sitio.
Causa 2: La opción Se requiere transferencia segura está habilitada
Los recursos compartidos de archivos de Azure NFS no admiten actualmente el cifrado doble. Azure proporciona una capa de cifrado para todos los datos en tránsito entre los centros de datos de Azure mediante MACSec. Solo se puede acceder a los recursos compartidos de NFS desde redes virtuales de confianza y a través de túneles VPN. No hay ningún cifrado de capa de transporte adicional disponible en los recursos compartidos de NFS.
Solución
Deshabilite Transferencia segura necesaria en la hoja de configuración de la cuenta de almacenamiento.
Causa 3: no se ha instalado el paquete nfs-utils, nfs-client o nfs-common
Antes de ejecutar el mount
comando, instale el paquete nfs-utils, nfs-client o nfs-common.
Para comprobar si el paquete NFS está instalado, ejecute: .
Los mismos comandos de esta sección se aplican a CentOS y Oracle Linux.
sudo rpm -qa | grep nfs-utils
Solución
Si el paquete no está instalado, instálelo mediante el comando específico distro.
Los mismos comandos de esta sección se aplican a CentOS y Oracle Linux.
Versión 7.X del sistema operativo
sudo yum install nfs-utils
Versión del sistema operativo 8.X o 9.X
sudo dnf install nfs-utils
Causa 4: El firewall bloquea el puerto 2049
El protocolo NFS se comunica con su servidor a través del puerto 2049. Asegúrese de que el puerto esté abierto para la cuenta de almacenamiento (el servidor NFS).
Solución
Compruebe que el puerto 2049 está abierto en el cliente mediante la ejecución del siguiente comando. Si el puerto no está abierto, ábralo.
sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049
Causa 5: Cuenta de almacenamiento eliminada
Si no puede montar el recurso compartido de archivos debido a un error: se agota el tiempo de espera de la conexión, es posible que la cuenta de almacenamiento que contiene el recurso compartido de archivos se elimine accidentalmente.
Solución
Recupere la cuenta de almacenamiento. A continuación, elimine y vuelva a crear el punto de conexión privado para que esté asociado al nuevo identificador de recurso de la cuenta de almacenamiento.
ls no responde con la enumeración de directorios grandes en algunos kernels
Causa: Se introdujo un error en el kernel de Linux v5.11 y se corrigió en v5.12.5
Algunas versiones del kernel tienen un error que hace que los listados de directorios den lugar a una secuencia infinita de READDIR. Los directorios muy pequeños donde todas las entradas se pueden enviar en una sola llamada no tienen este problema. El error se introdujo en el kernel de Linux v5.11 y se corrigió en v5.12.5. Por lo tanto, todas las versiones intermedias tienen el error. RHEL 8.4 tiene esta versión de kernel.
Solución alternativa: Degradación o actualización del kernel
Cambie a una versión anterior o posterior del kernel para resolver el problema.
Los comandos del sistema producen el error "Archivo no encontrado"
Causa
Es posible que las aplicaciones de Linux de 32 bits que dependen de números de inode no funcionen según lo esperado con Azure Files debido al formato de los números de inode de 64 bits generados por el servicio NFS.
Solución
Para solucionar este problema, use uno de los métodos siguientes:
Comprima los números de inode de 64 bits a 32 bits mediante la
nfs.enable_ino64=0
opción de arranque del kernel.Establezca el parámetro de módulo agregando
options nfs enable_ino64=0
al archivo /etc/modprobe.d/nfs.conf y reiniciando la máquina virtual.
También puede conservar esta opción de arranque del kernel en el archivo grub.conf . Para más información, consulte la documentación de la distribución de Linux.
No se puede cambiar la propiedad de los archivos y directorios
Causa
El sistema operativo cliente aplica permisos en recursos compartidos de archivos NFS en lugar del servicio Azure Files. Si la configuración Root Squash está habilitada en un recurso compartido de archivos NFS, el usuario raíz del sistema cliente se trata como un usuario anónimo (sin privilegios) con fines de control de acceso. Esto significa que incluso si ha iniciado sesión como raíz en el sistema cliente, no puede usar el chown
comando para cambiar la propiedad de los archivos y directorios que no posee.
Solución
En Azure Portal, vaya al recurso compartido de archivos y seleccione Propiedades. Cambie el valor de Root Squash a No Root Squash. Para más información, consulte Configuración de squash raíz para Azure Files.
Con No Root Squash habilitado, el usuario raíz del sistema cliente tiene los mismos privilegios que el usuario raíz en el sistema de servidor. Ahora puede usar chown
para cambiar la propiedad de cualquier archivo o directorio del recurso compartido, independientemente del propietario actual. Después de realizar los cambios, puede volver a habilitar Root Squash si es necesario.
¿Necesita ayuda?
Si sigue necesitando ayuda, póngase en contacto con el soporte técnico para resolver el problema rápidamente.
Consulte también
- Solucionar problemas de Azure Files
- Solución de problemas de rendimiento de Azure Files
- Solución de problemas de conectividad de Azure Files (SMB)
- Solución de problemas de autenticación y autorización de Azure Files (SMB)
- Solución de problemas generales de SMB de Azure Files en Linux
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.