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 Azure SMB con clientes Linux. También proporciona posibles causas y soluciones para estos problemas.

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

Importante

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

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

Se perdieron marcas de tiempo al copiar archivos

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

Causa

La marca f de fuerza en COPYFILE da como resultado la ejecución cp -p -f en Unix. Este comando también no puede conservar la marca de tiempo del archivo que no 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

ls: no se puede acceder a 'path>'<: 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. Obtiene el siguiente error:

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

Solución

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

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

No se pueden crear vínculos simbólicos: ln: no se pudo crear el vínculo simbólico 't': operación no admitida

Causa

De forma predeterminada, el montaje de recursos compartidos de archivos de Azure en Linux mediante SMB no habilita la compatibilidad con vínculos simbólicos (vínculos simbólicos). 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 denominados vínculos simbólicos minshall+francés para las operaciones de creación y seguimiento. Los clientes que necesiten vínculos simbólicos pueden usar la opción de montaje "mfsymlinks". Se recomienda "mfsymlinks" porque también es el formato que usan los Mac.

Para usar vínculos simbólicos, agregue lo siguiente al final del comando de montaje smb:

,mfsymlinks

Por lo tanto, el comando es similar al siguiente:

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 vínculos simbólicos como se sugiere en la wiki.

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

No puede acceder a carpetas o archivos desde el recurso compartido de archivos de Azure mientras se monta en Linux. Los comandos como du y ls o aplicaciones de terceros podrían producir un error "No tal archivo o directorio" al acceder al recurso compartido; sin embargo, puede cargar archivos en estas carpetas a través de 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 montar el recurso compartido en Linux:

En lugar de:

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

Use lo siguiente:

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 Azure Storage

Las E/S de archivo en el sistema de archivos montado comienzan a dar errores de "Host está inactivo" o "Permiso denegado". Los registros dmesg de Linux en el cliente muestran errores repetidos como:

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á conectado actualmente.

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 que el tráfico de Azure Files se redirija desde el clúster de origen al clúster de destino mediante la actualización de las asignaciones 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 tome 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 SMB de Linux, esta redirección no surte efecto. Como resultado, el tráfico de datos sigue yendo al clúster de origen, que ha dejado de atender esta cuenta después de la migración.

Solución alternativa

Puede mitigar este problema reiniciando el sistema operativo cliente, pero podría volver a encontrarse con el problema si no actualiza el sistema operativo 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 puede 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 usa durante cualquier recuperación de desconexión de red, lo que puede hacer que el problema se repita. Este comportamiento persiste incluso fuera de las migraciones de la cuenta de almacenamiento.

Para solucionar mejor este problema, borre la caché del solucionador DNS del kernel:

  1. Para mostrar el estado del módulo 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 siguiente comando:

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

  3. Vuelva a mostrar el estado del módulo 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é está ahora 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 de Linux anteriores, 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 una corrección permanente, actualice el sistema operativo 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 SMB de Linux al kernel principal de Linux. La versión del kernel 5.15+ y Keyutils-1.6.2+ tienen las correcciones. Algunas distribuciones han devuelto estas correcciones y 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, no se puede montar el recurso compartido de archivos 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

Importante

FIPS es un conjunto de estándares que el gobierno de Ee. UU. usa 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 utilizada que genera un valor hash de 128 bits. Sin embargo, MD5 se considera inseguro para fines criptográficos.

Cómo comprobar 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, se habilita FIPS.

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 obtener más información, consulte Habilitación de la autenticación de Active Directory a través de 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 archivo en /etc/default/grub y quite el parámetro fips=1.

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

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

  4. Recompile la imagen de 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 aún necesita ayuda, póngase en contacto con el soporte técnico para resolver el problema rápidamente.

Vea 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.