Compartir a través de

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

  • Artículo

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

Puede usar AzFileDiagnostics para automatizar la detección de síntomas y asegurarse de que el cliente Linux tenga los requisitos previos correctos. Le ayuda a configurar su entorno para obtener un rendimiento óptimo. También puede encontrar esta información en el solucionador de problemas de recursos compartidos archivos de Azure.

Importante

Este artículo solo se aplica a los recursos compartidos de SMB. Para obtener información sobre los recursos compartidos de NFS, consulte Solución de problemas de recursos compartidos de archivos de NFS de Azure.

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

Las marcas de tiempo se perdieron 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

La marca f de fuerza en COPYFILE da como resultado la cp -p -f ejecución en Unix. Este comando tampoco conserva la marca de tiempo del archivo que no el usuario posee.

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

Es: No se puede acceder a '<ruta de acceso>': 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:

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

Solución

Actualice el kernel de Linux a las siguientes versiones que tengan una solución para este problema:

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Todas las versiones que sean mayores o iguales que 4.13

No se pueden crear vínculos simbólicos. En: No se pudo crear un vínculo simbólico "t": operación no admitida

Causa

De manera predeterminada, el montaje de recursos compartidos de archivos de Azure en Linux mediante SMB no posibilita la compatibilidad con vínculos 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 opción de montaje "mfsymlinks". Se recomienda "mfsymlinks", porque también es el formato que usan equipos Mac.

Para poder usar symlinks, agregue el siguiente código al final de su 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 symlinks como se sugiere en la wiki.

No se puede acceder a carpetas o archivos cuyo nombre contiene un espacio o un punto al final

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, o aplicaciones de terceros, pueden generar el error "No se encontró el archivo o directorio" al acceder al recurso compartido. Sin embargo, sí se pueden cargar archivos en estas carpetas mediante Azure Portal.

Causa

Las carpetas o archivos se cargaron desde un sistema que codifica los caracteres al final del nombre en un carácter diferente. Los archivos cargados desde un equipo Macintosh pueden tener un carácter "0xF028" o "0xF029" en lugar de 0x20 (espacio) o 0X2E (punto).

Solución

Use la opción mapchars en el recurso compartido al montarlo 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

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 verá que el FQDN del servidor ahora se resuelve en una dirección IP diferente a la que está conectada 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 porque la asignación de DNS puede cambiar.

Causa

Con fines de equilibrio de carga de capacidad, las cuentas de almacenamiento a veces se migran en vivo de un clúster de almacenamiento a otro. La migración de cuentas desencadena tráfico de Azure Files que se redirigirá desde el clúster de origen al clúster de destino mediante la actualización de las asignaciones de DNS para que apunten al clúster de destino. Esto 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 dirigiéndose al clúster de origen, que ha dejado de atender a 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.

Nota

En algunas distribuciones anteriores de Linux, es posible que los pasos de mitigación anteriores no funcionen. En tales casos, reiniciar el sistema operativo cliente es la única mitigación conocida.

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. Se han enviado varias correcciones para el cliente de kernel de SMB de Linux al kernel de Linux de línea principal. Las distribuciones siguientes tienen las 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 han vuelto a importar estas correcciones. Puede comprobar si existen las siguientes correcciones en la versión de distribución que usa:

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

Cuando Federal Information Processing Standard (FIPS) está habilitado en una máquina virtual Linux, el recurso compartido de archivos SMB no se puede montar. 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

Importante

FIPS es un conjunto de estándares que usa el gobierno estadounidense para garantizar la seguridad y la integridad de los sistemas informáticos. Cuando un sistema está en modo FIPS, cumple los requisitos criptográficos específicos descritos por estos estándares.

Causa

El cliente del recurso compartido de archivos SMB usa la autenticación NTLMSSP, que requiere el algoritmo 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 Kerberos/Azure AD. 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 samba

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

  2. Modifique en /etc/default/grub el GRUB_CMDLINE_LINUX_DEFAULT archivo 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:

¿Necesita ayuda?

Si sigue necesitando ayuda, póngase en contacto con el soporte técnico para resolver el problema rápidamente.

Consulte también

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.