Solución de problemas de conectividad y acceso Azure Files (SMB)

  • Artículo

En este artículo se enumeran los problemas comunes que pueden producirse al intentar conectarse a recursos compartidos de archivos de Azure del Bloque de mensajes del servidor (SMB) desde clientes Windows o Linux y acceder a él. También proporciona posibles causas y soluciones para estos problemas.

Nota:

¿Le resultó útil este artículo? Su opinión es importante para nosotros. Use el botón Comentarios de esta página para indicarnos lo bien que ha funcionado este artículo o cómo podemos mejorarlo.

Importante

Este artículo solo se aplica a recursos compartidos SMB. Para obtener más información sobre los recursos compartidos del sistema de archivos de red (NFS), consulte Solución de problemas de recursos compartidos de archivos 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

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

Seleccione la pestaña Windows o Linux en función del sistema operativo cliente que use para acceder a recursos compartidos de archivos de Azure.

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

Error 5 al montar un recurso compartido de archivos de Azure

  • Error del sistema 5. Acceso denegado.

Causa 1: Canal de comunicación sin cifrar

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.

Solución para la causa 1

  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.

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

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.

Solución para la causa 2

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.

Causa 3: Los permisos de nivel de recurso compartido son incorrectos al usar la autenticación basada en identidades

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.

Solución para la causa 3

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.

Error 53, Error 67 o Error 87 al montar o desmontar un recurso compartido de archivos de Azure

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.

Causa 1: El puerto 445 está bloqueado

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

Nota:

Este comando devuelve la dirección IP actual de la cuenta de almacenamiento. No se garantiza que esta dirección IP siga siendo la misma y puede cambiar en cualquier momento. No codifique esta dirección IP de forma rígida en ningún script ni en una configuración de firewall.

Soluciones para la causa 1

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.

Causa 2: NTLMv1 está habilitado

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.

Solución para la causa 2

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

La aplicación o el servicio no pueden acceder a una unidad de Azure Files montada

Causa

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.

Solución

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.

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

Ninguna carpeta con una letra de unidad en "Mi equipo" o "Este EQUIPO"

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

Causa

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.

Solución

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.

Se produce un error en el comando net use si la cuenta de almacenamiento contiene una barra diagonal.

Causa

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.

Solución

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

  • Ejecute el siguiente comando de 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.

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

En un escenario de conmutación por error iniciado por el cliente con cuentas de almacenamiento con redundancia geográfica, los identificadores de archivos y las concesiones no se conservan en la conmutación por error. Los clientes deben desmontar y volver a montar los recursos compartidos de archivos.

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

Al intentar acceder a un recurso compartido de archivos de Azure o eliminarlo mediante el Azure Portal, es posible que reciba el siguiente error:

Sin acceso Código de error: 403

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

Solución para la causa 1

Compruebe que las reglas de red virtual y firewall están configuradas correctamente en la cuenta de almacenamiento. Para probar si las reglas de firewall o red virtual 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.

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

Solución para la causa 2

Vaya a la cuenta de almacenamiento en la que se encuentra el recurso compartido de archivos de Azure, seleccione Control de acceso (IAM) y compruebe que la cuenta de usuario tiene acceso a la cuenta de almacenamiento. Para más información, consulte Protección de la cuenta de almacenamiento con el control de acceso basado en rol de Azure (RBAC de Azure).

Bloqueos y concesiones de archivos

Si no puede modificar o eliminar un recurso compartido de archivos o una instantánea de Azure, puede deberse a bloqueos de archivos o concesiones. Azure Files proporciona dos maneras de evitar la modificación o eliminación accidental de recursos compartidos de archivos de Azure e instantáneas de recursos compartidos:

  • Bloqueos de recursos de cuenta de almacenamiento: todos los recursos de Azure, incluida la cuenta de almacenamiento, admiten bloqueos de recursos. Un administrador o servicios como Azure Backup pueden poner bloqueos en la cuenta de almacenamiento. Existen dos variaciones de bloqueos de recursos: modificar, que impide todas las modificaciones en la cuenta de almacenamiento y sus recursos, y eliminar, lo que solo impide eliminaciones de la cuenta de almacenamiento y sus recursos. Al modificar o eliminar recursos compartidos a través del Microsoft.Storage proveedor de recursos, los bloqueos de recursos se aplican a los recursos compartidos de archivos de Azure y a las instantáneas de recursos compartidos. La mayoría de las operaciones del portal, Azure PowerShell cmdlets para Azure Files con Rm en el nombre (por ejemplo, Get-AzRmStorageShare) y los comandos de la CLI de Azure en el share-rm grupo de comandos (por ejemplo, az storage share-rm list) usan el proveedor de Microsoft.Storage recursos. Algunas herramientas y utilidades, como Explorador de Storage, los cmdlets de administración de PowerShell Azure Files heredados sin Rm el nombre (por ejemplo, Get-AzStorageShare) y los comandos heredados de la CLI de Azure Files en el share grupo de comandos (por ejemplo, az storage share list) usan API heredadas en la API de FileREST que omiten el Microsoft.Storage proveedor de recursos y los bloqueos de recursos. Para obtener más información sobre las API de administración heredadas expuestas en la API de FileREST, consulte plano de control en Azure Files.

  • Concesiones de instantáneas de recursos compartidos o compartidos: las concesiones de recursos compartidos son una especie de bloqueo propietario para los recursos compartidos de archivos de Azure y las instantáneas de recursos compartidos de archivos. Los administradores pueden colocar concesiones en recursos compartidos de archivos de Azure individuales o instantáneas de recursos compartidos de archivos llamando a la API a través de un script o mediante servicios de valor agregado, como Azure Backup. Cuando se coloca una concesión en un recurso compartido de archivos de Azure o una instantánea de recurso compartido de archivos, la modificación o eliminación de la instantánea de recurso compartido de archivos o recurso compartido se puede realizar con el identificador de concesión. Los administradores también pueden liberar la concesión antes de las operaciones de modificación, que requiere el identificador de concesión, o interrumpir la concesión, que no requiere el identificador de concesión. Para obtener más información sobre las concesiones de recursos compartidos, consulte recurso compartido de concesión.

Dado que los bloqueos y concesiones de recursos pueden interferir con las operaciones de administrador previstas en la cuenta de almacenamiento o los recursos compartidos de archivos de Azure, es posible que desee quitar los bloqueos o concesiones de recursos que se hayan colocado en los recursos manualmente o automáticamente mediante servicios de valor agregado, como Azure Backup. El siguiente script quita todos los bloqueos y concesiones de recursos. No olvide reemplazar <resource-group> y <storage-account> por los valores adecuados para su entorno.

Antes de ejecutar el siguiente script, debe instalar la versión más reciente del módulo de PowerShell de Azure Storage.

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.

# 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

Seleccione la pestaña Windows o Linux en función del sistema operativo cliente que use para acceder a recursos compartidos de archivos de Azure.

En Windows, es posible que vea los siguientes errores.

Identificadores o concesiones de archivos huérfanos

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.

Nota:

Las concesiones REST las usan las aplicaciones para evitar que los archivos se eliminen o modifiquen. Antes de interrumpir las concesiones, debe identificar qué aplicación las está adquiriendo. De lo contrario, podría interrumpir el comportamiento de la aplicación.

Causa 1

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.

Solución 1

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

Nota:

Los Get-AzStorageFileHandle cmdlets y Close-AzStorageFileHandle se incluyen en el módulo Az PowerShell versión 2.4 o posterior. Para instalar el módulo Az PowerShell más reciente, consulte Instalación del módulo Azure PowerShell.

Causa 2

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

Solución 2

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

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

Si la snapshot opción del mount comando no se pasa en un formato reconocido, el mount comando puede producir un error. Para confirmarlo, compruebe los mensajes de registro del kernel (dmesg) y dmesg mostrará una entrada de registro como cifs: Bad value for 'snapshot'.

Solución

Asegúrese de pasar la snapshot opción del mount comando en el formato correcto. Consulte la página manual mount.cifs (por ejemplo, man mount.cifs). Un error común es pasar la marca de tiempo GMT en el formato incorrecto, como usar guiones o dos puntos en lugar de puntos. Para obtener más información, consulte Montaje de una instantánea de recurso compartido de archivos.

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

Causa

Si se pasa la opción de instantánea mount a partir @GMTde , pero el formato sigue siendo incorrecto (por ejemplo, con guiones y dos puntos en lugar de puntos), el mount comando puede producir un error.

Solución

Asegúrese de pasar la marca de tiempo GMT en el formato correcto, que es @GMT-year.month.day-hour.minutes.seconds. Para obtener más información, consulte Montaje de una instantánea de recurso compartido de archivos.

"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

Si la instantánea que intenta montar no existe, el mount comando puede producir este error. Para confirmarlo, compruebe los mensajes de registro del kernel (dmesg) y dmesg mostrará una entrada de registro como:

[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

Asegúrese de que existe la instantánea que intenta montar. Para obtener más información sobre cómo enumerar las instantáneas disponibles para un recurso compartido de archivos de Azure determinado, consulte Montaje de una instantánea de recurso compartido de archivos.

Cuota de disco o errores de red de demasiados identificadores abiertos

Seleccione la pestaña Windows o Linux en función del sistema operativo cliente que use para acceder a recursos compartidos de archivos de Azure.

Error 1816: no hay suficiente cuota disponible para procesar este comando

Causa

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.

Solución

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.

Nota:

Los Get-AzStorageFileHandle cmdlets y Close-AzStorageFileHandle se incluyen en el módulo Az PowerShell versión 2.4 o posterior. Para instalar el módulo Az PowerShell más reciente, consulte Instalación del módulo Azure PowerShell.

ERROR_UNEXP_NET_ERR (59) al realizar operaciones en un identificador

Causa

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.

Solución

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.

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

Cuando se copia un archivo a través de la red, el archivo se descifra en el equipo de origen, se transmite en texto no cifrado y se vuelve a cifrar en el destino. Sin embargo, es posible que vea el siguiente error al intentar copiar un archivo cifrado: "Está copiando el archivo en un destino que no admite el cifrado".

Causa

Este problema puede producirse si usa El sistema de cifrado de archivos (EFS). Los archivos cifrados con BitLocker se pueden copiar en Azure Files. Sin embargo, Azure Files no admite NTFS EFS.

Solución alternativa

Para copiar un archivo a través de la red, primero debe descifrarlo. Utilice uno de los métodos siguientes:

  • Use el comando copy /d . Permite que los archivos cifrados se guarden como archivos descifrados en el destino.
  • Establezca la siguiente clave del Registro:
    • Ruta de acceso = HKLM\Software\Policies\Microsoft\Windows\System
    • Tipo de valor = DWORD
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Valor = 1

Tenga en cuenta que la configuración de la clave del Registro afecta a todas las operaciones de copia realizadas en recursos compartidos de red.

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

El error ConditionHeadersNotSupported se produce al acceder al contenido hospedado en Azure Files a través de una aplicación que usa encabezados condicionales, como un explorador web, se produce un error de acceso. El error indica que no se admiten los encabezados de condición.

Captura de pantalla que muestra el mensaje de error ConditionHeadersNotSupported.

Causa

Los encabezados condicionales aún no se admiten. Las aplicaciones que las implementan tendrán que solicitar el archivo completo cada vez que se acceda al archivo.

Solución alternativa

Cuando se carga un nuevo archivo, la propiedad CacheControl de forma predeterminada es no-cache. Para forzar a la aplicación a solicitar el archivo cada vez, la propiedad CacheControl del archivo debe actualizarse de no-cache a no-cache, no-store, must-revalidate. Esto se puede lograr mediante Explorador de Azure Storage.

Screeshot que muestra la propiedad de archivo CacheControl.

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.