Solución de problemas de Azure Files en Linux (SMB)

Aplica a: ✔️ comparticiones de archivos Azure SMB

En este artículo se enumeran los problemas comunes que pueden producirse al usar recursos compartidos de archivos Azure SMB con clientes Linux. También se proporcionan posibles causas de estos problemas y sus resoluciones.

Ejecución de diagnósticos

Las herramientas de diagnóstico pueden ayudar a garantizar que los clientes tengan los requisitos previos correctos y recopilen información de depuración sobre los problemas de campo que pueden ser difíciles de reproducir.

Uso de AzFileDiagnostics

Use AzFileDiagnostics para automatizar la detección de síntomas y asegurarse de que el cliente linux tiene los requisitos previos correctos. Le ayuda a configurar su entorno para obtener un rendimiento óptimo.

Uso de la herramienta Always-On Diagnostics

También puede usar la herramienta Always-On Diagnostics (AOD) para recopilar registros en clientes SMB y NFSv4 Linux. El demonio se ejecuta en segundo plano como un servicio del sistema y se puede configurar para detectar anomalías en varias fuentes, como registros de dmesg, datos de depuración, métricas de error y métricas de latencia. Puede capturar datos de tcpdump, nfsstat, mountstats y otros orígenes, junto con el uso de cpu y memoria del sistema.

La herramienta Always-On Diagnostics es compatible actualmente con sistemas que ejecutan SUSE Linux Enterprise Server 15 (SLES 15) y Red Hat Enterprise Linux 8 (RHEL 8). Siga los pasos de instalación correspondientes al sistema operativo:

Las marcas de tiempo se pierden al copiar archivos

En las plataformas Linux/Unix, se produce un error en el cp -p comando si diferentes usuarios poseen el archivo 1 y el archivo 2.

Causa

El indicador de forzado f en COPYFILE provoca la ejecución de cp -p -f en Unix. Este comando también falla en conservar la marca de tiempo del archivo que no te pertenece.

Solución alternativa

Use el usuario de la cuenta de almacenamiento para copiar los archivos:

• str_acc_name=[storage account name]
• sudo useradd $str_acc_name
• sudo passwd $str_acc_name
• su $str_acc_name
• cp -p filename.txt /share

ls: no se puede acceder a '<ruta>': Error de entrada/salida

Al intentar enumerar archivos en un recurso compartido de archivos de Azure mediante el ls comando , el comando se bloquea al enumerar los archivos. Verá este error:

ls: no se puede acceder a'<ruta>': error de entrada/salida

Solución

Actualice el kernel de Linux a una versión que incluya una corrección para este problema. Use una de las siguientes versiones:

• 4.4.87+
• 4.9.48+
• 4.12.11+
• Cualquier versión 4.13 o posterior

No se pueden crear enlaces simbólicos - ln: no se pudo crear el enlace simbólico 't': operación no admitida

Causa

De manera predeterminada, montar recursos compartidos de archivos de Azure en Linux mediante SMB no habilita la compatibilidad con enlaces simbólicos (symlinks). Es posible que vea un error como este:

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

Solución

El cliente SMB de Linux no admite la creación de vínculos simbólicos de estilo Windows a través del protocolo SMB 2 o 3. Actualmente, el cliente Linux admite otro estilo de vínculos simbólicos llamados Mishall+French para operaciones de creación y seguimiento. Los clientes que necesitan vínculos simbólicos pueden usar la mfsymlinks opción de montaje. Use mfsymlinks porque también es el formato que usan los Mac.

Para usar vínculos simbólicos, agregue la siguiente opción al final del comando de montaje de SMB:

,mfsymlinks

Por lo tanto, el comando tiene el siguiente aspecto:

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

A continuación, puede crear enlaces simbólicos tal como se sugiere en la wiki.

No se puede acceder a carpetas o archivos

No puede acceder a carpetas ni archivos desde el recurso compartido de archivos de Azure mientras está montado en Linux. Comandos como du y ls, así como las aplicaciones de terceros, pueden mostrar el error «No existe el archivo o el directorio» al intentar acceder al recurso compartido.

Causa 1

Las carpetas o archivos tienen nombres que incluyen caracteres codificados de forma diferente por el sistema que los carga. Por ejemplo, los archivos cargados desde un cliente macOS pueden tener un 0xF028 carácter o 0xF029 en lugar de 0x20 (espacio) o 0x2E (punto).

Solución 1

Utilice la opción mapchars al montar el recurso compartido en Linux.

En lugar de:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

Uso:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Causa 2

Al eliminar un archivo pero mantener el identificador abierto, el servidor SMB mantiene un archivo zombie hasta que cierra el identificador final del archivo. Cualquier intento de realizar operaciones en este archivo zombi podría dar lugar a errores como "No existe el archivo o el directorio" en Linux.

Solución 2

Restaure el archivo eliminado de la copia de seguridad más reciente si es necesario.

Problemas de DNS con la migración en vivo de cuentas de almacenamiento de Azure

Las E/S de archivos del sistema de archivos montado empiezan a generar errores que indican que el host está inactivo o que un permiso se ha denegado. Los registros dmesg de Linux en el cliente muestran errores repetidos como los siguientes:

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

También puede ver que el FQDN del servidor ahora se resuelve a una dirección IP diferente de aquella a la que está conectado actualmente. Este problema puede producirse en cualquier escenario en el que la dirección IP del servidor pueda cambiar, como la migración de cuentas. Otro escenario conocido es la conmutación por error de la cuenta de almacenamiento, ya que la asignación DNS puede cambiar.

Causa

Con fines de equilibrio de carga de capacidad, el sistema a veces migra cuentas de almacenamiento de un clúster de almacenamiento a otro. La migración de la cuenta actualiza las asignaciones de DNS para que apunten al clúster de destino, lo que redirige el tráfico de Azure Files desde el clúster de origen al clúster de destino. Esta actualización bloquea todo el tráfico al clúster de origen desde esa cuenta. Se espera que el cliente SMB recoja las actualizaciones de DNS y redirija más tráfico al clúster de destino. Sin embargo, debido a un error en el cliente de kernel de SMB de Linux, este redireccionamiento no surte efecto. Como resultado, el tráfico de datos sigue en el clúster de origen, lo que deja de atender esta cuenta después de la migración.

Solución alternativa

Puede mitigar este problema reiniciando el sistema operativo del cliente, pero es posible que se vuelva a producir si no actualiza el sistema operativo del cliente a una versión de distribución de Linux con compatibilidad con la migración de cuentas.

Aunque desmontar y volver a montar el recurso compartido podría parecer resolver el problema temporalmente, no es una solución permanente. Cuando el cliente se vuelve a conectar al servidor, el problema podría producirse de nuevo. La mitigación temporal se produce porque una nueva acción de montaje omite la memoria caché del kernel SMB y resuelve la dirección DNS en el espacio de usuario. Sin embargo, la caché DNS del kernel se utiliza durante cualquier recuperación de desconexión de red, lo que puede hacer que el problema se vuelva a repetir. Este comportamiento persiste incluso fuera de las migraciones de la cuenta de almacenamiento.

Para solucionar este problema mejor, borre la caché de la resolución DNS del kernel:

1. Para mostrar el estado del módulo de kernel dns_resolver , ejecute el siguiente comando:

   grep '.dns_resolver' /proc/keys
   

   Debería ver la salida del comando como en el ejemplo siguiente:

   132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1
   

2. Borre la caché del solucionador DNS del kernel mediante la ejecución del comando siguiente:

   sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))
   

3. Vuelva a mostrar el estado del módulo de kernel dns_resolver :

   grep '.dns_resolver' /proc/keys
   

   Debería ver la salida del comando como en el ejemplo siguiente, lo que indica que la memoria caché ahora está vacía:

   132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty
   

4. Desmonte y vuelva a montar el recurso compartido para mitigar el problema.

Solución

Para obtener una corrección permanente, actualice el sistema operativo del cliente a una versión de distribución de Linux con compatibilidad con la migración de cuentas. Varias correcciones para el cliente del kernel de SMB de Linux se envían al kernel de Linux de línea principal. Las distribuciones siguientes incluyen estas correcciones:

• Ubuntu: 20.04, 22.04, 24.04 y AKS 22.04 (las correcciones se han implementado en la versión del kernel 5.15.0-1068)
• RHEL: 8.6+
• SLES: 15SP2, 15SP3, 15SP4 y 15SP5
• Linux de Azure: 2.0 (las correcciones se han implementado en la versión del kernel 5.15.159.1) y 3.0

Algunas distribuciones retroportan estas correcciones. Compruebe si existen las siguientes correcciones en la versión de distribución que está usando:

• cifs: al ejecutar cifs_reconnect, volver a resolver el nombre de host

• cifs: use la salida de expiración de dns_query para programar la siguiente resolución.

• cifs: establezca un mínimo de 120 s para la siguiente resolución DNS.

• cifs: para establecer coincidencias con los servidores de archivos, asegúrese de que el nombre de host del servidor coincide.

• cifs: corrige la fuga de memoria de smb3_fs_context_dup::server_hostname

• dns: aplique un valor predeterminado de TTL para los registros obtenidos de getaddrinfo().

• claves: corrige la sobrescritura de la caducidad de las claves al instanciar

No se puede montar el recurso compartido de archivos SMB cuando FIPS está habilitado

Al habilitar Federal Information Processing Standard (FIPS) en una máquina virtual Linux, no se puede montar el recurso compartido de archivos de SMB. Los registros dmesg de Linux en el cliente muestran errores como:

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

Causa

El cliente del recurso compartido de archivos de SMB usa la autenticación NTLMSSP, que requiere el algoritmo de hash MD5. Sin embargo, en el modo FIPS, el algoritmo MD5 está restringido porque no es compatible con FIPS. MD5 es una función hash ampliamente usada que genera un valor hash de 128 bits. Sin embargo, MD5 se considera inseguro para fines criptográficos.

Comprobación de si el modo FIPS está habilitado

Para comprobar si el modo FIPS está habilitado en el cliente, ejecute el siguiente comando. Si el valor se establece en 1, FIPS está habilitado.

sudo cat /proc/sys/crypto/fips_enabled

Solución

Para resolver este problema, habilite la autenticación Kerberos para el recurso compartido de archivos SMB. Si FIPS está habilitado involuntariamente, consulte option2 para deshabilitarlo.

Opción 1: Habilitar la autenticación Kerberos para el recurso compartido de archivos SMB

Para montar un recurso compartido de archivos SMB en la máquina virtual Linux donde FIPS está habilitado, use la autenticación basada en identidades. Para más información, consulte Habilitar la autenticación de Active Directory sobre SMB para clientes Linux que acceden a Azure Files.

Opción 2: Deshabilitar FIPS para montar el recurso compartido de Samba

1. Cambie el valor sysctl de crypto.fips_enabled a 0 en /etc/sysctl.conf.

2. Modifique el GRUB_CMDLINE_LINUX_DEFAULT en el archivo /etc/default/grub y quite el parámetro fips=1.

3. Vuelva a generar el archivo de configuración de grub2 con el siguiente comando:

   sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   

4. Vuelva a generar la imagen initramfs con el siguiente comando:

   sudo dracut -fv
   

5. Reinicie la máquina virtual.

Para obtener más información, consulte los siguientes documentos de distribuidores de Linux:

• RedHat: ¿Por qué habilitar el modo FIPS en el kernel rompería los montajes CIFS?
• SUSE: el montaje CIFS falla con el error "error de montaje(2): No existe el archivo o el directorio"

¿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 NFS de Azure Files en Linux
• Solución de problemas de Azure File Sync