Azure Files: Solución de problemas de conectividad (SMB)

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

No se puede conectar a un recurso compartido de archivos de Azure ni montarlo

Al intentar conectarse a un recurso compartido de archivos de Azure en Windows, es posible que reciba los siguientes mensajes de error.

• Error del sistema 5. Acceso denegado.

Por motivos de seguridad, las conexiones a recursos compartidos de archivos de Azure se bloquean si el canal de comunicación no está cifrado y el intento de conexión no se realiza desde el mismo centro de datos donde residen los recursos compartidos de archivos de Azure. Si la opción Transferencia segura necesaria está habilitada en la cuenta de almacenamiento, también se bloquean las conexiones sin cifrar dentro del mismo centro de datos. Solo se proporciona un canal de comunicación cifrado si el sistema operativo cliente del usuario final admite el cifrado SMB.

Windows 8, Windows Server 2012 y versiones posteriores de cada sistema negocian solicitudes que incluyen SMB 3.x, que admite el cifrado.

1. Conéctese desde un cliente que admita el cifrado SMB (Windows 8/Windows Server 2012 o posterior).
2. Conéctese desde una máquina virtual (VM) en el mismo centro de datos que la cuenta de almacenamiento de Azure que se usa para el recurso compartido de archivos de Azure.
3. Compruebe que la opción Transferencia segura necesaria está deshabilitada en la cuenta de almacenamiento si el cliente no admite el cifrado SMB.

El tráfico de red se deniega si la red virtual (VNET) y las reglas de firewall están configuradas en la cuenta de almacenamiento, a menos que la dirección IP del cliente o la red virtual aparezcan en la lista de permitidos.

Compruebe que las reglas de red virtual y firewall están configuradas correctamente en la cuenta de almacenamiento. Para probar si la red virtual o las reglas de firewall están causando el problema, cambie temporalmente la configuración de la cuenta de almacenamiento a Permitir el acceso desde todas las redes. Para más información, consulte Configuración de firewalls y redes virtuales de Azure Storage.

Si los usuarios acceden al recurso compartido de archivos de Azure mediante Active Directory (AD) o Servicios de dominio de Microsoft Entra autenticación, el acceso al recurso compartido de archivos produce un error con el error "Acceso denegado" si los permisos de nivel de recurso compartido son incorrectos.

Valide que los permisos están configurados correctamente:

• Servicios de dominio de Active Directory (AD DS) consulte Asignación de permisos de nivel de recurso compartido.

  Las asignaciones de permisos de nivel de recurso compartido son compatibles con grupos y usuarios que se han sincronizado de AD DS a Microsoft Entra ID mediante Microsoft Entra Connect Sync o Microsoft Entra Connect Cloud Sync. Confirme que los grupos y los usuarios a los que se les asignan permisos de nivel de recurso compartido no son grupos "solo en la nube" no admitidos.

• Servicios de dominio de Microsoft Entra consulte Asignación de permisos de nivel de recurso compartido.

Al intentar montar un recurso compartido de archivos desde el entorno local o desde otro centro de datos, es posible que reciba los errores siguientes:

• Se ha producido el error del sistema 53. No se ha encontrado la ruta de acceso de la red.
• Error del sistema 67. No se encuentra el nombre de red.
• Error del sistema 87. El parámetro es incorrecto.

El error del sistema 53 o el error del sistema 67 pueden producirse si se bloquea la comunicación saliente del puerto 445 a un centro de datos de Azure Files. Para ver el resumen de los ISP que permiten o no permiten el acceso desde el puerto 445, vaya a TechNet.

Para comprobar si el firewall o isp bloquea el puerto 445, use la herramienta AzFileDiagnostics o el Test-NetConnection cmdlet .

Para usar el Test-NetConnection cmdlet, se debe instalar el módulo Azure PowerShell. Consulte Instalar Azure PowerShell módulo para obtener más información. No olvide reemplazar <your-storage-account-name> y <your-resource-group-name> por los nombres pertinentes de la cuenta de almacenamiento.

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

Si la conexión se realizó correctamente, debería ver la siguiente salida:

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

Solución 1: use Azure File Sync como punto de conexión QUIC Puede usar Azure File Sync como solución alternativa para acceder a Azure Files desde clientes que tienen bloqueado el puerto 445. Aunque Azure Files no admite directamente SMB a través de QUIC, Windows Server 2022 Azure Edition admite el protocolo QUIC. Puede crear una caché ligera de los recursos compartidos de archivos de Azure en una máquina virtual de Windows Server 2022 Azure Edition mediante Azure File Sync. Esta configuración usa el puerto 443, que es de salida ampliamente abierto para admitir HTTPS, en lugar del puerto 445. Para obtener más información sobre esta opción, consulte SMB a través de QUIC con Azure File Sync.

Solución 2: uso de VPN o ExpressRoute Al configurar una red privada virtual (VPN) o ExpressRoute desde el entorno local a la cuenta de almacenamiento de Azure, con Azure Files expuestas en la red interna mediante puntos de conexión privados, el tráfico pasará por un túnel seguro en lugar de a través de Internet. Siga las instrucciones para configurar una VPN para acceder a Azure Files desde Windows.

Solución 3: desbloquear el puerto 445 con la ayuda del administrador de ISP/TI Trabaje con su departamento de TI o ISP para abrir el puerto 445 de salida a los intervalos IP de Azure.

Solución 4: use herramientas basadas en API REST como Explorador de Storage o PowerShell Azure Files también admite REST además de SMB. El acceso REST funciona a través del puerto 443 (tcp estándar). Hay varias herramientas que se escriben mediante la API REST que permiten una experiencia de interfaz de usuario enriquecida. Explorador de Storage es uno de ellos. Descargue e instale Explorador de Storage y conéctese al recurso compartido de archivos respaldado por Azure Files. También puede usar PowerShell que también usa la API REST.

El error del sistema 53 o el error del sistema 87 pueden producirse si la comunicación NTLMv1 está habilitada en el cliente. Azure Files solo admite la autenticación NTLMv2. Tener NTLMv1 habilitado crea un cliente menos seguro. Por lo tanto, la comunicación se bloquea para Azure Files.

Para determinar si esta es la causa del error, compruebe que la siguiente subclave del Registro no está establecida en un valor menor que 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Para obtener más información, vea el tema LmCompatibilityLevel en TechNet.

Revierta el LmCompatibilityLevel valor al valor predeterminado de 3 en la siguiente subclave del Registro:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Al intentar montar un recurso compartido de archivos de Azure, recibe el siguiente error:

Código de error: 0x800704b3
Nombre simbólico: ERROR_NO_NET_OR_BAD_PATH
Descripción del error: la ruta de acceso de red se escribió incorrectamente, no existe o el proveedor de red no está disponible actualmente. Intente volver a escribir la ruta de acceso o póngase en contacto con el administrador de red.

Este error puede producirse si los servicios principales relacionados con la red de Windows están deshabilitados, ya que cualquier servicio que dependa explícitamente de esos servicios de red no se iniciará.

Compruebe si alguno de los siguientes servicios está en estado Detenido en la máquina virtual Windows:

• Conexiones de red
• Servicio de lista de redes
• Reconocimiento de la ubicación de red
• Servicio de interfaz de almacén de red
• Cliente DHCP
• Asistente de NetBIOS de TCP/IP
• Estación de trabajo

Si encuentra alguno, inicie los servicios y vuelva a intentar montar el recurso compartido de archivos de Azure.

Las unidades se montan por usuario. Si la aplicación o el servicio se ejecutan en una cuenta de usuario diferente a la que montó la unidad, la aplicación no verá la unidad.

Use una de las siguientes soluciones:

• Monte la unidad desde la misma cuenta de usuario que contiene la aplicación. Puede usar una herramienta como PsExec.

• Pase el nombre y la clave de la cuenta de almacenamiento en los parámetros de nombre de usuario y contraseña del net use comando.

• Use el cmdkey comando para agregar las credenciales al Administrador de credenciales. Realice esta acción desde una línea de comandos en el contexto de la cuenta de servicio, ya sea a través de un inicio de sesión interactivo o mediante runas.

  Consola

  cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
  

• Asigne el recurso compartido directamente sin usar una letra de unidad asignada. Es posible que algunas aplicaciones no se vuelvan a conectar a la letra de unidad correctamente, por lo que el uso de la ruta de acceso UNC completa podría ser más confiable:

  net use * \\storage-account-name.file.core.windows.net\share

Después de seguir estas instrucciones, es posible que reciba el siguiente mensaje de error al ejecutar net use para la cuenta de servicio del sistema o red: "Error del sistema 1312. No existe una sesión de inicio de sesión especificada. Es posible que ya se haya terminado". Si aparece este error, asegúrese de que el nombre de usuario que se pasa a net use incluye información de dominio (por ejemplo: [storage account name].file.core.windows.net).

Si asigna un recurso compartido de archivos de Azure como administrador mediante el net use comando , parece que falta el recurso compartido.

De forma predeterminada, Windows Explorador de archivos no se ejecuta como administrador. Si ejecuta net use desde un símbolo del sistema administrativo, asigne la unidad de red como administrador. Dado que las unidades asignadas están centradas en el usuario, la cuenta de usuario que ha iniciado sesión no muestra las unidades si están montadas en otra cuenta de usuario.

Monte el recurso compartido desde una línea de comandos que no es de administrador. Como alternativa, puede seguir este tema de TechNet para configurar el valor del EnableLinkedConnections Registro.

El net use comando interpreta una barra diagonal (/) como una opción de línea de comandos. Si el nombre de la cuenta de usuario comienza con una barra diagonal, se produce un error en la asignación de unidades.

Puede usar cualquiera de los pasos siguientes para solucionar el problema:

• Ejecute el siguiente comando de PowerShell:

  PowerShell

   

  New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
  

  Desde un archivo por lotes, puede ejecutar el comando de esta manera:

  Echo new-smbMapping ... | powershell -command –

• Coloque comillas dobles alrededor de la clave para solucionar este problema, a menos que la barra diagonal sea el primer carácter. Si es así, use el modo interactivo y escriba la contraseña por separado o vuelva a generar las claves para obtener una clave que no comience con una barra diagonal.

Es posible que vea este mensaje de error si el recurso compartido de archivos no es accesible. Por ejemplo, el puerto 445 está bloqueado o hay un problema de resolución de DNS.

Asegúrese de que el puerto 445 está abierto y compruebe la resolución DNS y la conectividad con el recurso compartido de archivos.

Linux

Las causas comunes de este problema son:

• Está usando una distribución de Linux con un cliente SMB obsoleto. Consulte Uso de Azure Files con Linux para obtener más información sobre las distribuciones comunes de Linux disponibles en Azure que tienen clientes compatibles.
• Las utilidades SMB (cifs-utils) no están instaladas en el cliente.
• La versión mínima de SMB, 2.1, no está disponible en el cliente.
• El cifrado SMB 3.x no se admite en el cliente. En la tabla anterior se proporciona una lista de distribuciones de Linux que admiten el montaje desde el entorno local y entre regiones mediante el cifrado. Otras distribuciones requieren kernel 4.11 y versiones posteriores.
• Está intentando conectarse a un recurso compartido de archivos de Azure desde una máquina virtual de Azure y la máquina virtual no está en la misma región que la cuenta de almacenamiento.
• Si la opción Transferencia segura necesaria está habilitada en la cuenta de almacenamiento, Azure Files solo permitirá conexiones que usen SMB 3.x con cifrado.

Para resolver el problema, use la herramienta de solución de problemas para Azure Files errores de montaje en Linux. Esta herramienta:

• Ayuda a validar el entorno de ejecución del cliente.
• Detecta la configuración de cliente incompatible que provocaría un error de acceso para Azure Files.
• Proporciona instrucciones prescriptivas sobre la corrección automática.
• Recopila los seguimientos de diagnóstico.

Por motivos de seguridad, las conexiones a recursos compartidos de archivos de Azure se bloquean si el canal de comunicación no está cifrado y el intento de conexión no se realiza desde el mismo centro de datos donde residen los recursos compartidos de archivos de Azure. Las conexiones sin cifrar dentro del mismo centro de datos también se pueden bloquear si la opción Transferencia segura necesaria está habilitada en la cuenta de almacenamiento. Solo se proporciona un canal de comunicación cifrado si el sistema operativo cliente del usuario admite el cifrado SMB.

Para más información, consulte Requisitos previos para montar un recurso compartido de archivos de Azure con Linux y el paquete cifs-utils.

1. Conéctese desde un cliente que admita el cifrado SMB o conéctese desde una máquina virtual en el mismo centro de datos que la cuenta de almacenamiento de Azure que se usa para el recurso compartido de archivos de Azure.
2. Compruebe que la opción Transferencia segura necesaria está deshabilitada en la cuenta de almacenamiento si el cliente no admite el cifrado SMB.

Si la red virtual (VNET) y las reglas de firewall están configuradas en la cuenta de almacenamiento, se denegará el acceso al tráfico de red a menos que se permita el acceso a la dirección IP del cliente o a la red virtual.

Compruebe que las reglas de red virtual y firewall están configuradas correctamente en la cuenta de almacenamiento. Para probar si las redes virtuales o las reglas de firewall están causando el problema, cambie temporalmente la configuración de la cuenta de almacenamiento a Permitir el acceso desde todas las redes. Para más información, consulte Configuración de firewalls y redes virtuales de Azure Storage.

Algunas distribuciones de Linux aún no admiten características de cifrado en SMB 3.x. Los usuarios pueden recibir un mensaje de error "115" si intentan montar Azure Files mediante SMB 3.x debido a una característica que falta. SMB 3.x con cifrado completo solo se admite en la versión más reciente de una distribución de Linux.

La característica de cifrado para SMB 3.x para Linux se introdujo en el kernel 4.11. Esta característica permite el montaje de un recurso compartido de archivos de Azure desde el entorno local o desde otra región de Azure. Es posible que algunas distribuciones de Linux hayan realizado cambios atrasados del kernel 4.11 a las versiones anteriores del kernel de Linux que mantienen. Para ayudar a determinar si la versión de Linux admite SMB 3.x con cifrado, consulte Uso de Azure Files con Linux.

Si el cliente SMB de Linux no admite el cifrado, monte Azure Files mediante SMB 2.1 desde una máquina virtual Linux que se encuentra en el mismo centro de datos de Azure que el recurso compartido de archivos. Compruebe que la opción Transferencia segura necesaria está deshabilitada en la cuenta de almacenamiento.

Se produce un error de montaje "112" en el cliente Linux cuando el cliente ha estado inactivo durante mucho tiempo. Después de un tiempo de inactividad prolongado, el cliente se desconecta y la conexión agota el tiempo de espera.

La conexión puede estar inactiva por los siguientes motivos:

• Errores de comunicación de red que impiden volver a establecer una conexión TCP con el servidor cuando se usa la opción de montaje "suave" predeterminada.
• Correcciones de reconexión recientes que no están presentes en kernels anteriores.

Este problema de reconexión en el kernel de Linux ahora se ha corregido como parte de los siguientes cambios:

• Corrección de la reconexión para no aplazar la reconexión de sesión smb3 mucho después de volver a conectar el socket
• Llamar al servicio de eco inmediatamente después de volver a conectar el socket
• CIFS: corrección de posibles daños en la memoria durante la reconexión
• CIFS: corrección de un posible bloqueo doble de exclusión mutua durante la reconexión (para kernel v4.9 y versiones posteriores)

Sin embargo, es posible que estos cambios no se porte aún a todas las distribuciones de Linux. Si usa una distribución de Linux popular, puede comprobar Usar Azure Files con Linux para ver qué versión de la distribución tiene los cambios necesarios en el kernel.

Para solucionar este problema, especifique un montaje duro. Un montaje duro obliga al cliente a esperar hasta que se establece una conexión o hasta que se interrumpe explícitamente. Puede usarlo para evitar errores debido a los tiempos de espera de red. Sin embargo, esta solución alternativa podría provocar esperas indefinidas. Esté preparado para detener las conexiones según sea necesario.

Si no puede actualizar a las versiones más recientes del kernel, puede solucionar este problema manteniendo un archivo en el recurso compartido de archivos de Azure en el que se escribe cada 30 segundos o menos. Debe ser una operación de escritura, como volver a escribir la fecha de creación o modificación en el archivo. De lo contrario, puede obtener resultados almacenados en caché y es posible que la operación no desencadene la reconexión.

No se puede acceder, modificar o eliminar un recurso compartido de archivos de Azure (o una instantánea de recurso compartido)

Error "El nombre de usuario o la contraseña son incorrectos" después de una conmutación por error iniciada por el cliente

Error "Sin acceso" al intentar acceder a un recurso compartido de archivos de Azure o eliminarlo

Causa 1: Las reglas de red virtual o firewall están habilitadas en la cuenta de almacenamiento

Solución para la causa 1

Causa 2: La cuenta de usuario no tiene acceso a la cuenta de almacenamiento

Solución para la causa 2

Bloqueos y concesiones de archivos

 Importante

Los servicios de valor agregado que toman bloqueos de recursos y comparten concesiones de instantáneas en los recursos de Azure Files pueden volver a aplicar periódicamente bloqueos y concesiones. La modificación o eliminación de recursos bloqueados por servicios de valor agregado puede afectar al funcionamiento normal de esos servicios, como la eliminación de instantáneas de recursos compartidos administradas por Azure Backup.

PowerShell

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

No se puede modificar, mover o cambiar el nombre o eliminar un archivo o directorio

Windows

En Windows, es posible que vea los siguientes errores.

Uno de los propósitos clave de un recurso compartido de archivos es que varios usuarios y aplicaciones pueden interactuar simultáneamente con archivos y directorios del recurso compartido. Para ayudar con esta interacción, los recursos compartidos de archivos proporcionan varias formas de mediar el acceso a archivos y directorios.

Al abrir un archivo desde un recurso compartido de archivos de Azure montado a través de SMB, el sistema operativo o la aplicación solicita un identificador de archivo, que es una referencia al archivo. Entre otras cosas, la aplicación especifica un modo de uso compartido de archivos cuando solicita un identificador de archivo, que especifica el nivel de exclusividad del acceso al archivo aplicado por Azure Files:

• None: tiene acceso exclusivo.
• Read: otros usuarios pueden leer el archivo mientras lo tiene abierto.
• Write: otros pueden escribir en el archivo mientras lo tiene abierto.
• ReadWrite: una combinación de los Read modos de uso compartido y .Write
• Delete: otros usuarios pueden eliminar el archivo mientras lo tiene abierto.

Aunque como protocolo sin estado, el protocolo FileREST no tiene un concepto de identificadores de archivo, proporciona un mecanismo similar para mediar el acceso a archivos y carpetas que el script, la aplicación o el servicio pueden usar: concesiones de archivos. Cuando se concede un archivo, se trata como equivalente a un identificador de archivo con un modo de uso compartido de archivos de None.

Aunque los identificadores de archivos y las concesiones tienen un propósito importante, a veces los identificadores de archivos y las concesiones pueden quedar huérfanos. Cuando esto sucede, esto puede causar problemas en la modificación o eliminación de archivos. Es posible que vea mensajes de error como:

• El proceso no puede acceder al archivo porque otro proceso usa el archivo.
• La acción no se puede completar porque el archivo está abierto en otro programa.
• Otro usuario bloquea el documento para su edición.
• Un cliente SMB marca el recurso especificado para su eliminación.

La resolución de este problema depende de si esto se debe a un identificador de archivo huérfano o a una concesión.

Un identificador de archivo impide que se modifique o elimine un archivo o directorio. Puede usar el cmdlet De PowerShell Get-AzStorageFileHandle para ver los identificadores abiertos.

Si todos los clientes SMB han cerrado sus identificadores abiertos en un archivo o directorio y el problema continúa ocurriendo, puede forzar el cierre de un identificador de archivo.

Para forzar el cierre de un identificador de archivo, use el cmdlet Close-AzStorageFileHandle de PowerShell.

Una concesión de archivos impide que se modifique o elimine un archivo. Puede comprobar si un archivo tiene una concesión de archivos con los siguientes comandos de PowerShell. Reemplace <resource-group>, <storage-account>, <file-share>y <path-to-file> por los valores adecuados para el entorno.

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

Si un archivo tiene una concesión, el objeto devuelto debe contener las siguientes propiedades:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Para quitar una concesión de un archivo, puede liberarla o interrumpirla. Para liberar la concesión, necesita el Valor LeaseId de la concesión, que se establece al crear la concesión. No necesita el Valor LeaseId para interrumpir la concesión.

En el ejemplo siguiente se muestra cómo interrumpir la concesión del archivo indicado en la causa 2 (este ejemplo continúa con las variables de PowerShell de la causa 2):

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

Linux

En Linux, es posible que vea los siguientes problemas.

Este problema suele producirse si el archivo o directorio tiene un identificador abierto.

Si los clientes SMB han cerrado todos los identificadores abiertos y el problema continúa ocurriendo, realice lo siguiente:

• Use el cmdlet Get-AzStorageFileHandle de PowerShell para ver los identificadores abiertos.

• Use el cmdlet Close-AzStorageFileHandle de PowerShell para cerrar los identificadores abiertos.

No se puede montar una instantánea de recurso compartido de archivos de Azure en Linux

"Error de montaje(22): argumento no válido" al intentar montar una instantánea de recurso compartido de archivos de Azure en Linux

Causa

Solución

"Token de instantánea incorrecto" al intentar montar una instantánea de recurso compartido de archivos de Azure en Linux

Causa

Solución

"Error de montaje(2): no hay ningún archivo o directorio de este tipo" al intentar montar una instantánea del recurso compartido de archivos de Azure

Causa

Output

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

Solución

Cuota de disco o errores de red de demasiados identificadores abiertos

El error 1816 se produce cuando se alcanza el límite superior de identificadores abiertos simultáneos permitidos para un archivo o directorio en el recurso compartido de archivos de Azure. Para obtener más información, consulte Azure Files destinos de escala.

Reduzca el número de identificadores abiertos simultáneos cerrando algunos identificadores y, a continuación, vuelva a intentarlo. Para obtener más información, consulte Microsoft Azure Storage lista de comprobación de rendimiento y escalabilidad.

Para ver los identificadores abiertos de un recurso compartido de archivos, directorio o archivo, use el cmdlet Get-AzStorageFileHandle de PowerShell.

Para cerrar los identificadores abiertos de un recurso compartido de archivos, un directorio o un archivo, use el cmdlet Close-AzStorageFileHandle de PowerShell.

Si almacena en caché o mantiene un gran número de identificadores abiertos durante mucho tiempo, es posible que vea este error en el lado servidor debido a motivos de limitación. Cuando el cliente almacena en caché un gran número de identificadores, muchos de ellos pueden entrar en una fase de reconexión al mismo tiempo, creando una cola en el servidor que debe limitarse. La lógica de reintento y la limitación en el back-end para volver a conectarse tardan más tiempo que el tiempo de espera del cliente. Esta situación se manifiesta como un cliente que no puede usar un identificador existente para ninguna operación, con todas las operaciones con errores con ERROR_UNEXP_NET_ERR (59).

También hay casos perimetrales en los que el identificador de cliente se desconecta del servidor (por ejemplo, una interrupción de red que dura varios minutos) que podrían provocar este error.

No mantenga un gran número de identificadores almacenados en caché. Cierre los identificadores y vuelva a intentarlo. Use Get-AzStorageFileHandle y Close-AzStorageFileHandle los cmdlets de PowerShell para ver o cerrar identificadores abiertos.

Si usa recursos compartidos de archivos de Azure para almacenar contenedores de perfiles o imágenes de disco para una implementación de escritorio virtual a gran escala u otras cargas de trabajo que abran identificadores en archivos, directorios o el directorio raíz, es posible que alcance los límites de escala superior para los identificadores abiertos simultáneos. En este caso, use un recurso compartido de archivos de Azure adicional y distribuya los contenedores o imágenes entre los recursos compartidos.

Linux

En Linux, es posible que reciba un mensaje de error similar al siguiente:

<filename> [permiso denegado] Cuota de disco superada

Ha alcanzado el límite superior de identificadores abiertos simultáneos permitidos para un archivo o directorio.

Azure Files admite 10 000 identificadores abiertos en el directorio raíz y 2000 identificadores abiertos por archivo y directorio dentro del recurso compartido.

Reduzca el número de identificadores abiertos simultáneos cerrando algunos identificadores y reintentar la operación.

Para ver los identificadores abiertos de un recurso compartido de archivos, directorio o archivo, use el cmdlet Get-AzStorageFileHandle de PowerShell.

Para cerrar los identificadores abiertos de un recurso compartido de archivos, un directorio o un archivo, use el cmdlet Close-AzStorageFileHandle de PowerShell.

Error "Está copiando un archivo en un destino que no admite el cifrado"

Causa

Solución alternativa

Error ConditionHeadersNotSupported desde una aplicación web mediante Azure Files desde el explorador

Causa

Solución alternativa