Compartir a través de

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

  • Artículo

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

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 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 los recursos compartidos de archivos de Azure.

Cuando intente conectarse a un recurso compartido de archivos de Azure en Windows, es posible que vea los mensajes de error siguientes.

Error 5 al montar un recurso compartido de archivos de Azure

  • Error de sistema 5. Acceso denegado.

Causa 1: Canal de comunicación sin cifrar

Por seguridad, se bloquean las conexiones a recursos compartidos de archivos de Azure si el canal de comunicación no está cifrado y si 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 no cifradas del mismo centro de datos también se pueden bloquear si la configuración de transferencia segura requerida está habilitada en la cuenta de almacenamiento. Se proporciona un canal de comunicación cifrado solamente 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 compatible con el cifrado SMB (Windows 8/Windows Server 2012 o posterior).
  2. Conéctese desde una máquina virtual (VM) del 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 configuración de la 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 de red virtuales están habilitadas en la cuenta de almacenamiento

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

Solución para la causa 2

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

Causa 3: Los permisos de nivel de recurso compartido no son correctos cuando se usa la autenticación basada en identidades

Si los usuarios acceden al recurso compartido de archivos de Azure mediante la autenticación basada en identidades, se produce un error en el acceso al recurso compartido de archivos con el error "Acceso denegado" si los permisos de nivel de recurso compartido son incorrectos.

Solución para la causa 3

Compruebe que los permisos de nivel de recurso compartido están configurados correctamente. Consulte Asignación de permisos de nivel de recurso compartido. Las asignaciones de permisos de nivel de recurso compartido se admiten para grupos y usuarios que se han sincronizado desde AD DS a Identificador de Entra de Microsoft mediante Microsoft Entra Connect Sync o microsoft Entra Connect Cloud Sync. Confirme que los grupos y usuarios a los que se asignan permisos de nivel de recurso compartido no son grupos "solo en la nube" admitidos.

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 siguientes errores:

  • Error de sistema 53. No se ha encontrado la ruta de acceso de la red.
  • Error de sistema 67. No se encuentra el nombre de red especificado.
  • Error de sistema 87. El parámetro no es correcto.

Causa 1: El puerto 445 está bloqueado

Los errores del sistema 53 o 67 pueden producirse cuando se bloquea la comunicación de salida del puerto 445 a un centro de datos de Azure Files. Para ver el resumen de los ISP que permiten o deniegan el acceso desde el puerto 445, visite TechNet.

Para comprobar si el servidor de seguridad o el ISP está bloqueando el puerto 445, use la herramienta AzFileDiagnostics o el cmdlet Test-NetConnection.

Para usar el cmdlet Test-NetConnection, debe tener instalado el módulo Azure PowerShell. Para más información, consulte Instalación del módulo de Azure PowerShell. No olvide reemplazar <your-storage-account-name> y <your-resource-group-name> por los nombres correspondientes de su 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, 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 permanezca igual, podría cambiar en cualquier momento. No codifique de forma rígida esta dirección IP en los scripts o en una configuración de firewall.

Soluciones para la causa 1

Solución 1: Usar 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 con Windows Server 2022 Azure Edition mediante Azure File Sync. En esta configuración se usa el puerto 443, que está ampliamente abierto para admitir HTTPS, en lugar del puerto 445. Para más información sobre esta opción, consulte SMB a través de QUIC con Azure File Sync.

Solución 2: use VPN o ExpressRoute mediante la configuración de una red privada virtual (VPN) o ExpressRoute desde el entorno local a la cuenta de almacenamiento de Azure, con Azure Files expuesto 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 ayuda del administrador de ISP/TI Trabaje con el departamento de TI o el 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 Azure Files de PowerShell también admite REST además de SMB. El acceso a REST funciona a través del puerto 443 (tcp estándar). Existen diversas herramientas que se han escrito con la API REST y que ofrecen una experiencia de interfaz de usuario mejorada. Una de ellas es el Explorador de Storage. Descargue e instale el Explorador de Storage y conéctese a su recurso compartido de archivos respaldado por Azure Files. También puede usar PowerShell que también use la API REST.

Causa 2: NTLMv1 está habilitado

También se producen los errores del sistema 53 u 87 si se ha habilitado la comunicación NTLMv1 en el cliente. Azure Files solo admite la autenticación NTLMv2. Si se habilita NTLMv1, el cliente será menos seguro. Por lo tanto, se bloquea la comunicación con Azure Files.

Para determinar si esta es la causa del error, averigüe si la siguiente subclave del Registro no está establecida en un valor inferior a 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

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

Solución para la causa 2

Revierta el valor LmCompatibilityLevel al predeterminado, 3, en la siguiente subclave del registro:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Error al 0x800704b3 de código de error

Al intentar montar un recurso compartido de archivos de Azure, recibirá 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 ha escrito incorrectamente, no existe o el proveedor de red no está disponible actualmente. Intente volver a establecer la ruta de acceso o póngase en contacto con el administrador de red.

Causa

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

Solución

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 ubicación de red
  • Servicio Interfaz de almacenamiento en red
  • Cliente DHCP
  • Asistente NetBIOS sobre TCP/IP
  • Estación de trabajo

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

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

Causa

Las unidades se montan para usuarios individuales. Si la aplicación o el servicio se ejecuta con una cuenta de usuario diferente a la que ha montado la unidad, la aplicación no verá la unidad.

Solución

Pruebe una de estas 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 comando net use.

  • Use el comando cmdkey 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, mediante 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 correctamente a la letra de unidad, por lo que usar 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, podría recibir el mensaje de error siguiente cuando ejecute net use para la cuenta de servicio de red o del sistema: "Error de sistema 1312. Una sesión de inicio especificada no existe. 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).

No hay ninguna carpeta con una letra de unidad en "Mi PC" o "Este equipo"

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

Causa

De manera predeterminada, el Explorador de archivos de Windows no se ejecuta como administrador. Si se ejecuta net use desde un símbolo del sistema de administrador, la unidad de red se asigna como administrador. Dado que las unidades asignadas son específicas de los usuarios, la cuenta de usuario con la que se haya iniciado sesión no mostrará las unidades si estas se han montado con una cuenta de usuario distinta.

Solución

Monte el recurso compartido desde una línea de comandos que no sea 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 comando net use interpreta la barra diagonal (/) como opción de línea de comandos. Si el nombre de la cuenta de usuario comienza por una barra diagonal, se produce un error en la asignación de unidad.

Solución

Puede utilizar cualquiera de los siguientes pasos 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 este modo:

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

  • Encierre la clave entre comillas dobles para solucionar el problema, a menos que la barra diagonal sea el primer carácter. En ese caso, use el modo interactivo y escriba la contraseña por separado o vuelva a generar las claves para obtener una que no empiece por barra diagonal.

Se produce un error en el comando New-PSDrive con el error "el tipo de recurso de red no es correcto".

Causa

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

Solución

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

No se puede acceder, modificar o eliminar un recurso compartido de archivos de Azure (ni instantáneas de recursos compartidos)

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 archivo 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 Azure Portal, es posible que se produzca el siguiente error:

Sin acceso Código de error: 403

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

Solución para la causa 1

Compruebe que las reglas de firewall y de red virtual estén configuradas correctamente en la cuenta de almacenamiento. Para probar si las reglas de firewall o de red virtual son las que causan el problema, cambie temporalmente el valor en la cuenta de almacenamiento a Permitir el acceso desde todas las redes. Para más información, consulte Configuración de redes virtuales y firewalls 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 obtener más información, consulte cómo proteger su cuenta de almacenamiento mediante el control de acceso basado en roles de Azure (Azure RBAC).

Bloqueos y concesiones de archivos

Si no puede modificar o eliminar un recurso compartido de archivos o una instantánea de Azure, es posible que se deba a bloqueos de archivos o concesiones. Azure Files proporciona dos maneras de evitar la modificación o eliminación accidental de los recursos compartidos de archivos de Azure y las instantáneas de recursos compartidos:

  • Bloqueos de recursos de la cuenta de almacenamiento: todos los recursos de Azure, incluida la cuenta de almacenamiento, admiten bloqueos de recurso. Los bloqueos pueden colocarse en la cuenta de almacenamiento por parte de un administrador o por servicios como Azure Backup. Existen dos variaciones de bloqueos de recursos: modificar, lo 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 mediante el proveedor de recursos Microsoft.Storage, se aplicarán bloqueos de recursos en los recursos compartidos de archivos de Azure y en las instantáneas de recursos compartidos. La mayoría de las operaciones del portal, los cmdlets de Azure PowerShell 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 Microsoft.Storage proveedor de recursos. Algunas herramientas y utilidades, como Explorador de Storage, cmdlets de administración heredados de PowerShell de Azure Files sin Rm en el nombre (por ejemplo, Get-AzStorageShare) y 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 fileREST que omiten el Microsoft.Storage proveedor de recursos y los bloqueos de recursos. Para más información sobre las API de administración heredadas expuestas en la API de FileREST, consulte el plano de control en Azure Files.

  • Recurso compartido/concesiones de instantáneas de recurso compartido: las concesiones de recursos compartidos son un tipo de bloqueo de propietario para recursos compartidos de Azure e instantáneas de recursos compartidos de archivos. Las concesiones pueden colocarse en recursos compartidos de archivos de Azure individuales o instantáneas de recursos compartidos de archivos por parte de los administradores mediante una llamada a la API a través de un script o por servicios de valor agregado, como Azure Backup. Cuando se pone 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 estos 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, lo que requiere el identificador de concesión o interrumpir la concesión, que no requiere el identificador de concesión. Para más información sobre las concesiones de recursos compartidos, consulte Concesión de recursos compartidos.

Dado que los bloqueos y concesiones de recursos pueden interferir con las operaciones del administrador previstas en la cuenta de almacenamiento o los recursos compartidos de archivos de Azure, puede que desee quitar los que se hayan puesto en los recursos de forma manual o automática mediante servicios de valor agregado, como Azure Backup. El siguiente script elimina todos los bloqueos y concesiones de recursos. No olvide reemplazar <resource-group> y <storage-account> por los valores correctos para su entorno.

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

Importante

Los servicios de valor agregado que toman bloqueos de recursos y concesiones de recursos compartidos o instantáneas de estos en los recursos de Azure Files pueden volver a aplicar periódicamente los bloqueos y concesiones. La modificación o eliminación de recursos bloqueados por servicios de valor añadido puede afectar al funcionamiento normal de esos servicios, como la eliminación de instantáneas de recurso compartido 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/cambiar de 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 errores siguientes.

Identificadores o concesiones de archivos huérfanos

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

Al abrir un archivo desde un recurso compartido de archivos de Azure montado en SMB, la aplicación o el sistema operativo solicita un identificador de archivos, 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 usuarios pueden escribir en el archivo mientras lo tiene abierto.
  • ReadWrite: una combinación de los modos de uso compartido Read y Write.
  • Delete: otros usuarios pueden eliminar el archivo mientras está abierto.

Aunque como protocolo sin estado FileREST no tiene un concepto de identificadores de archivos, proporciona un mecanismo similar para mediar el acceso a los 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 archivos con un modo de uso compartido de archivos de None.

Aunque la finalidad de los identificadores y las concesiones de archivos es importante, a veces pueden estar huérfanos. Cuando esto sucede, se pueden producir problemas al modificar o eliminar archivos. Es posible que vea mensajes de error como estos:

  • El proceso no puede acceder al archivo porque otro proceso lo está utilizando.
  • La acción no se puede completar porque el archivo está abierto en otro programa.
  • Otro usuario ha bloqueado el documento para su edición.
  • El recurso especificado está marcado para su eliminación por parte de un cliente SMB.

La solución a este problema depende de si la causa es un identificador o una concesión de archivos huérfanos.

Nota:

Las aplicaciones usan concesiones REST para evitar que los archivos se eliminen o modifiquen. Antes de interrumpir las concesiones, debe identificar qué aplicación los adquiere. De lo contrario, es posible que interrumpa el comportamiento de la aplicación.

Causa 1

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

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

Solución 1

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

Nota:

Los cmdlets Get-AzStorageFileHandle yClose-AzStorageFileHandle se incluyen en la versión 2.4 o posterior del módulo de Az PowerShell. Para instalar el módulo Az de PowerShell más reciente, consulte Instalación del módulo de 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 su 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 liberar la concesión o interrumpirla. Para liberar la concesión, necesita el valor de LeaseId de la concesión, que se establece al crear esta. Este valor no es necesario 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 opción snapshot del comando mount no se pasa en un formato reconocido, el comando mount puede producir este 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 opción snapshot para el comando mount en el formato correcto. Consulte la página del manual de mount.cifs (por ejemplo, man mount.cifs). Un error común es pasar la marca de tiempo GMT en el formato incorrecto como, por ejemplo, el uso de guiones o dos puntos en lugar de puntos. Para obtener más información, vea 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 la opción mount de la instantánea se pasa a partir de @GMT, pero el formato sigue siendo incorrecto (por ejemplo, el uso de guiones y dos puntos en lugar de puntos), el comando mount puede producir este 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, vea Montaje de una instantánea de recurso compartido de archivos.

"Error de montaje(2): No se encontró el archivo o directorio" al intentar montar una instantánea de 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 la instantánea que está intentando montar existe. Para obtener más información sobre cómo enumerar las instantáneas disponibles para un recurso compartido de archivos de Azure determinado, vea Montaje de una instantánea de recurso compartido de archivos.

Errores de red o cuota de disco 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: cuota insuficiente para procesar este comando

Causa

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

Solución

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

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

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

Nota:

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

ERROR_UNEXP_NET_ERR (59) al realizar cualquier operación 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 del lado servidor debido a motivos de limitación. Cuando el cliente almacena en caché un gran número de identificadores, muchos de esos identificadores pueden entrar en una fase de reconexión al mismo tiempo, lo que crea una cola en el servidor que debe limitarse. La lógica de reintento y la limitación en el back-end para la reconexión tarda más 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, y donde todas las operaciones generan el mensaje ERROR_UNEXP_NET_ERR (59).

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

Solución

No mantenga un gran número de identificadores almacenados en caché. Cierre los identificadores y vuelva a intentarlo. Use los cmdlets de PowerShell Get-AzStorageFileHandle y Close-AzStorageFileHandle para ver o cerrar los 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 directorios raíz, es posible que alcance los límites de escala superior para 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 "El archivo se va a copiar a un destino que no es compatible con 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: "El archivo se va a copiar a un destino que no es compatible con el cifrado".

Causa

Este problema puede producirse si está usando Sistema de cifrado de archivos (EFS). Es posible copiar archivos cifrados por BitLocker en Azure Files. En cambio, 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
    • Nombre = CopyFileAllowDecryptedRemoteDestination
    • Valor = 1

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

Error ConditionHeadersNotSupported de una aplicación web al usar Azure Files desde el explorador

El error ConditionHeadersNotSupported se produce cuando se accede a contenido hospedado en Azure Files utilizando una aplicación que emplea encabezados condicionales, como un explorador web. El error indica que no se admiten los encabezados de condición.

Captura de pantalla que muestra el mensaje de error ConditionHeadersNotSupported.

Causa

Todavía no se admiten encabezados condicionales. Las aplicaciones que los implementen tendrán que solicitar el archivo completo cada vez que se accede al archivo.

Solución alternativa

Cuando se carga un nuevo archivo, la propiedad CacheControl de forma predeterminada no es caché. Para forzar que la aplicación solicite 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 el Explorador de Azure Storage.

Screeshot que muestra la propiedad del archivo CacheControl.

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.