Устранение неполадок с подключением и доступом Файлы Azure (SMB)

При попытке подключиться к общей папке Azure в ОС Windows могут возникнуть следующие сообщения об ошибке.

Ошибка 5 при подключении файлового ресурса Azure

• "Произошла системная ошибка 5. Отказано в доступе".

Причина 1: незашифрованный коммуникационный канал

Из соображений безопасности, если коммуникационный канал не зашифрован, а попытка подключения осуществляется не из того же центра обработки данных, в котором находятся файловые ресурсы Azure, то подключение к ним Azure будет заблокировано. Если в учетной записи хранения включен параметр Требуется безопасное перемещение, незашифрованные подключения в одном центре обработки данных также могут быть заблокированы. Шифрование коммуникационного канала выполняется, только если клиентская ОС конечного пользователя поддерживает шифрование SMB.

Windows 8, Windows Server 2012 и более поздние версии каждого системного согласования запросов, включая SMB 3.x, поддерживающий шифрование.

Решение для причины 1

1. Подключитесь из клиента, который поддерживает шифрование SMB (Windows 8 либо Windows Server 2012 или более поздней версии).
2. Подключитесь с виртуальной машины, размещенной в том же центре обработки данных, что и учетная запись хранения Azure, используемая для общей папки Azure.
3. Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения, если клиент не поддерживает шифрование SMB.

Причина 2: правила виртуальной сети или брандмауэра включены для учетной записи хранения

Трафик запрещается, если для учетной записи хранения настроены правила виртуальной сети и брандмауэра при условии, что IP-адрес клиента или виртуальная сеть не разрешают доступ.

Решение для причины 2

Убедитесь, что правила виртуальной сети и брандмауэра надлежащим образом настроены для учетной записи хранения. Чтобы проверить, связана ли проблема с правилами виртуальной сети или брандмауэра, временно задайте для учетной записи хранения параметр Разрешить доступ из всех сетей. Подробнее см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей (предварительная версия).

Причина 3: неправильные разрешения на уровне общего ресурса при использовании проверки подлинности на основе удостоверений

Если пользователи получают доступ к общей папке Azure с помощью проверки подлинности на основе удостоверений, доступ к общей папке завершается ошибкой "Доступ запрещен". Если разрешения на уровне общего доступа неверны.

Решение для причины 3

Убедитесь, что разрешения на уровне общего ресурса настроены правильно. См. раздел "Назначение разрешений на уровне общего ресурса". Назначения разрешений на уровне общего доступа поддерживаются для групп и пользователей, которые были синхронизированы с AD DS с идентификатором Microsoft Entra Connect с помощью синхронизации Microsoft Entra Connect или облачной синхронизации Microsoft Entra Connect. Убедитесь, что группы и пользователи, которым назначены разрешения на уровне общего ресурса, не поддерживаются только облачные группы.

Ошибка 53, 67 или 87 при попытке подключения или отключения файлового ресурса Azure

При попытке подключить общую папку из локального или другого центра обработки данных могут возникнуть следующие ошибки:

• "Произошла системная ошибка 53. Сетевой путь не найден".
• "Произошла системная ошибка 67. Не найдено сетевое имя".
• "Произошла системная ошибка 87. Неправильный параметр".

Причина 1: порт 445 заблокирован

Системная ошибка 53 или 67 может произойти, если исходящие подключения через порт 445 к центру обработки данных службы файлов Azure заблокированы. Чтобы просмотреть сведения о поставщиках услуг Интернета, поддерживающих (или не поддерживающих) подключение через порт 445, перейдите на сайт TechNet.

Чтобы проверить, не блокирует ли брандмауэр или поставщик услуг Интернета порт 445, используйте средство AzFileDiagnostics или командлет Test-NetConnection.

Чтобы использовать командлет Test-NetConnection, необходимо установить модуль Azure PowerShell. Дополнительные сведения см. в статье Как установить модуль Azure PowerShell. Не забудьте заменить <your-storage-account-name> и <your-resource-group-name> соответствующими именами для вашей учетной записи хранения.

$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

Если установка прошла успешно, отобразятся следующие выходные данные.

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

Решения для причины 1

Решение 1. Использование Синхронизация файлов Azure в качестве конечной точки QUIC можно использовать Синхронизация файлов Azure в качестве обходного решения для доступа к Файлы Azure от клиентов с заблокированным портом 445. Хотя служба "Файлы Azure" не поддерживает напрямую SMB по QUIC, Windows Server 2022 Azure Edition поддерживает протокол QUIC. Вы можете создать упрощенный кэш общих папок Azure на виртуальной машине Windows Server 2022 Azure Edition с помощью Синхронизации файлов Azure. В этой конфигурации используется порт 443, который имеет широкие возможности для поддержки HTTPS, а не порта 445. Дополнительные сведения об этом параметре см. в разделе SMB по QUIC.

Решение 2. Использование VPN или ExpressRoute путем настройки виртуальной частной сети (VPN) или ExpressRoute из локальной учетной записи хранения Azure с Файлы Azure, предоставляемыми во внутренней сети с помощью частных конечных точек, трафик будет проходить через безопасный туннель, а не через Интернет. Следуйте инструкциям по настройке VPN для доступа к Файлы Azure из Windows.

Решение 3. Разблокируйте порт 445 с помощью ит-администратора или ИТ-администратора , чтобы открыть исходящий порт 445 в диапазоны IP-адресов Azure.

Решение 4. Используйте средства на основе REST API, такие как Обозреватель службы хранилища или PowerShell Файлы Azure также поддерживает REST в дополнение к SMB. Доступ к REST осуществляется через порт 443 (стандартный протокол TCP). Существуют различные средства, написанные с помощью REST API, которые обеспечивают широкий интерфейс пользовательского интерфейса. Обозреватель службы хранилища является одним из них. Скачайте и установите Обозреватель службы хранилища, а затем подключитесь к общей папке с помощью Файлов Azure. Вы также можете использовать PowerShell , которая также использует REST API.

Причина 2: включена аутентификация NTLMv1

Системная ошибка 53 или 87 может произойти, если в клиенте включена аутентификация NTLMv1. Служба файлов Azure поддерживает только проверку подлинности NTLMv2. Протокол проверки подлинности NTLMv1 делает клиент менее безопасным, в результате чего взаимодействие со службой файлов Azure блокируется.

Чтобы определить, является ли это причиной ошибки, убедитесь, что в следующем подразделе реестра не задано значение меньше 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Дополнительные сведения см. в статье LmCompatibilityLevel на сайте TechNet.

Решение для причины 2

Верните параметру LmCompatibilityLevel значение по умолчанию (3) в следующем подразделе реестра:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Сбой с кодом ошибки 0x800704b3

При попытке подключить общую папку Azure вы получите следующую ошибку:

Код ошибки: 0x800704b3
Символическое имя: ERROR_NO_NET_OR_BAD_PATH
Описание ошибки: сетевой путь был введен неправильно, не существует, или поставщик сети в настоящее время недоступен. Повторите попытку повторного доступа к пути или обратитесь к администратору сети.

Причина

Эта ошибка может возникать, если какие-либо основные службы, связанные с сетью Windows, отключены как любая служба, которая явно зависит от этих сетевых служб, не запустится.

Решение

Проверьте, находятся ли какие-либо из следующих служб в состоянии "Остановлено " на виртуальной машине Windows:

• Сетевые подключения
• Служба списка сетей
• Служба сведений о подключенных сетях
• Служба интерфейса сохранения сети
• DHCP-клиент
• Вспомогательное приложение для NetBIOS TCP/IP
• Рабочая станция

Если вы найдете его, запустите службы и повторите попытку подключения общей папки Azure.

Приложение или служба не могут получить доступ к подключенному Файлы Azure диску

Причина

Диски подключаются для каждого пользователя. Если приложение или служба запущены под учетной записью пользователя, отличной от учетной записи, подключенной к диску, приложение не увидит диск.

Решение

Используйте одно из следующих решений:

• Используйте для подключения дисков учетную запись пользователя, содержащую это приложение. Можно использовать такой инструмент, как PsExec.

• Передайте имя и ключ учетной записи хранения в параметрах net use имени пользователя и пароля команды.

• cmdkey Используйте команду, чтобы добавить учетные данные в Диспетчер учетных данных. Выполните это действие из командной строки в контексте учетной записи службы либо с помощью интерактивного входа, либо с помощью runas.

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

• Сопоставьте общий ресурс напрямую, не используя букву подключенного диска. Некоторые приложения могут неправильно подключиться к букве диска, поэтому использование полного пути UNC может быть более надежным:

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

После выполнения этих инструкций при выполнении команды net use для учетной записи системы или сети может появиться следующее сообщение об ошибке: "Произошла системная ошибка 1312. Указанный сеанс входа в систему не существует (A specified logon session does not exist). Возможно, это уже было завершено". Если появится эта ошибка, убедитесь, что имя пользователя, передаваемое в net use сведения о домене (например: [storage account name].file.core.windows.net).

В области "Мой компьютер" или "Этот компьютер" отсутствует папка с буквой диска

Если вы сопоставляете общую папку Azure как администратор с помощью net use команды, общий ресурс, как представляется, отсутствует.

Причина

По умолчанию Windows проводник не запускается от имени администратора. При выполнении net use из командной строки администрирования сетевой диск сопоставляются с администратором. Так как сопоставленные диски ориентированы на пользователя, учетная запись пользователя, вошедшего в систему, не отображает диски, если они подключены в другой учетной записи пользователя.

Решение

Подключите общую папку из командной строки без прав администратора. Кроме того, вы можете следовать этому разделуEnableLinkedConnections TechNet, чтобы настроить значение реестра.

Если учетная запись хранения содержит косую черту (/), то выполнение команды net use завершается сбоем

Причина

Команда net use интерпретирует косую черту вперед (/) как параметр командной строки. Если имя учетной записи пользователя начинается с косой черты, то сопоставление диска завершится сбоем.

Решение

Чтобы обойти эту проблему, выполните одно из следующих действий.

• Выполните следующую команду PowerShell:

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

  Из пакетного файла выполнить команду можно следующим образом.

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

• Заключите значение ключа в двойные прямые кавычки (если первый знак не является косой чертой). Если значение ключа начинается с косой черты (/), используйте интерактивный режим и введите пароль отдельно или повторно создайте ключи, которые не начинаются с этого знака.

Команда New-PSDrive завершается ошибкой "Тип сетевого ресурса некорректна"

Причина

Это сообщение об ошибке может появиться, если общая папка недоступна. Например, порт 445 заблокирован или возникла проблема с разрешением DNS.

Решение

Убедитесь, что порт 445 открыт и проверяет разрешение DNS и подключение к общей папке.

Клиенты Linux могут использовать AzFileDiagnostics для автоматизации обнаружения симптомов и обеспечения правильности необходимых компонентов.

Ниже приведены распространенные причины этой проблемы:

• Вы используете дистрибутив Linux с устаревшим клиентом SMB. Дополнительные сведения о распространенных дистрибутивах Linux в Azure с совместимыми клиентами см. в статье Использование Файлов Azure с Linux.
• Служебные программы SMB (cifs-utils) не установлены на клиенте.
• Минимальная версия SMB 2.1 недоступна на клиенте.
• Шифрование SMB 3.x не поддерживается на клиенте. В приведенной выше таблице представлен список дистрибутивов Linux, поддерживающих подключение из локальной среды и между регионами с использованием шифрования. В других дистрибутивах нужно использовать ядро 4.11 или более поздней версии.
• Вы пытаетесь подключиться к общей папке Azure с виртуальной машины Azure, и виртуальная машина не в том же регионе, что и учетная запись хранения.
• Если для учетной записи хранения включен параметр Требуется безопасное перемещение, то служба файлов Azure разрешает подключения только по протоколу SMB 3.x с шифрованием.

Решение

Чтобы устранить эту проблему, используйте средство устранения неполадок с подключением в службе файлов Azure для Linux. Это средство предоставляет следующие возможности:

• Помогает проверить среду выполнения клиента.
• Выявляет несовместимые конфигурации клиента, которые приведут к ошибкам доступа в файлах Azure.
• Предоставляет рекомендации для самостоятельного исправления.
• Собирает диагностические трассировки.

"Mount error(13): Permission denied" (Ошибка подключения(13). Отказ в разрешении) при подключении общей папки Azure

Причина 1: незашифрованный коммуникационный канал

По соображениям безопасности подключения к общим папкам Azure блокируются, если канал связи не зашифрован, и попытка подключения не выполняется из того же центра обработки данных, где находятся общие папки Azure. Незашифрованные подключения в одном центре обработки данных также могут быть заблокированы, если в учетной записи хранения включен параметр Требуется безопасное перемещение. Зашифрованный канал связи предоставляется только в том случае, если клиентская ОС пользователя поддерживает шифрование SMB.

Подробнее см. в статье Предварительные требования для подключения файлового ресурса Azure с помощью Linux и пакета cifs-utils.

Решение для причины 1

1. Подключитесь из клиента, который поддерживает шифрование SMB или подключитесь из виртуальной машины в том же центре обработки данных, что и учетная запись хранения Azure, используемая для общей папки Azure.
2. Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения, если клиент не поддерживает шифрование SMB.

Причина 2. В учетной записи хранения включены правила виртуальной сети или брандмауэра или порт 445 заблокирован.

Если для учетной записи хранения настроены правила виртуальной сети и брандмауэра, доступ сетевого трафика будет запрещен, если IP-адрес клиента или виртуальная сеть не разрешают доступ. Кроме того, если ваша компания или ISP блокирует исходящий порт 445, вы не сможете подключить общую папку.

Решение для причины 2

Убедитесь, что правила виртуальной сети и брандмауэра настроены правильно в учетной записи хранения и разрешенный порт 445. Чтобы проверить, вызвана ли проблема виртуальными сетями или правилами брандмауэра, можно временно изменить параметр учетной записи хранения, чтобы разрешить доступ из всех сетей. Подробнее см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей (предварительная версия).

Причина 3. Клиент SMB настроен для использования NTLMv1

Файлы Azure поддерживает только NTLMv2 (только ключ учетной записи хранения) и проверку подлинности Kerberos для общих папок SMB. NTLMv1 не поддерживается. Ядро 3.3 и более поздние версии по умолчанию для NTLMv2, если не переопределен параметр подключения sec . Ядра 4.4 и более поздних версий включите NTLMv2 по умолчанию и отключите LANMAN. В конфигурациях по умолчанию NTLMv1 хранится только в качестве варианта согласования. Дополнительные сведения см. в документации по ОС.

Решение для причины 3

Убедитесь, что команды подключения SMB не переопределяют проверку подлинности NTLMv2 по умолчанию с помощью sec параметра. Этот sec параметр никогда не должен использоваться ntlm или ntlmi при подключении к общим папкам SMB Azure. Если вы устанавливаете глобальные параметры в файле /etc/samba/smb.conf, убедитесь, что вы не отключаете NTLMv2.

Причина 4. Доступ к ключу учетной записи хранения отключен или запрещен с помощью политики

Если доступ к ключу учетной записи хранения отключен или запрещен для учетной записи хранения, маркеры SAS и ключи доступа не будут работать.

Решение для причины 4

Вместо этого используйте проверку подлинности на основе удостоверений. Сведения о предварительных требованиях и инструкциях см. в статье "Включение проверки подлинности Active Directory через SMB для клиентов Linux, обращаюющихся к Файлы Azure".

Отображается ошибка «Mount error(115): Operation now in progress» (Ошибка подключения (115). Идет выполнение операции) при подключении службы файлов Azure с помощью SMB 3.x

Причина

Сейчас некоторые дистрибутивы Linux не поддерживают функции шифрования в SMB 3.x. Из-за этого при попытке подключения службы файлов Azure с помощью SMB 3.x пользователь может получить сообщение об ошибке 115. SMB 3.x с полным шифрованием поддерживается только в последней версии дистрибутива Linux.

Решение

Функция шифрования протокола SMB 3.x для Linux появилась в ядре версии 4.11. Эта функция позволяет подключать общую папку Azure из локальной среды или другого региона Azure. Некоторые дистрибутивы Linux, возможно, изменились с ядра 4.11 на старые версии ядра Linux, которые они поддерживают. Чтобы определить, поддерживает ли ваша версия Linux SMB 3.x с шифрованием, обратитесь к разделу Use Файлы Azure with Linux.

Если клиент SMB Linux не поддерживает шифрование, подключите Файлы Azure с помощью SMB 2.1 с виртуальной машины Linux, которая находится в том же центре обработки данных Azure, что и общая папка. Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения.

Отображается сообщение "Mount error(112): Host is down" (Ошибка подключения (112). Узел не работает) из-за истечения времени ожидания повторного подключения

Ошибка подключения (112) возникает в клиенте Linux, если он бездействует в течение длительного времени. После длительного простоя клиент отключается и время ожидания подключения.

Причина

Подключение может бездействовать по следующим причинам:

• Сбои сетевого подключения, которые препятствуют повторному установке TCP-подключения к серверу при использовании параметра подключения по умолчанию "soft".
• Последние исправления повторного подключения, которые отсутствуют в старых ядрах.

Решение

Эта проблема повторного подключения в ядре Linux исправлена в рамках следующих изменений:

• Исправление повторного подключения к неотложенному сеансу переподключения mb3 через продолжительное время после повторного подключения сокета
• Вызов службы echo сразу же после повторного подключения сокета
• CIFS: устранение возможного повреждения содержимого памяти во время повторного подключения
• CIFS: устранение возможной двойной блокировки мьютекса во время повторного подключения — для ядра v4.9 и более поздних версий

Однако эти изменения еще не переносились ко всем дистрибутивам Linux. Если вы используете популярный дистрибутив Linux, вы можете проверить, Файлы Azure с Linux, чтобы узнать, какая версия дистрибутива имеет необходимые изменения ядра.

Обходное решение

Можно обойти эту проблему, указав жесткое подключение. Жесткое подключение вынудит клиент ожидать установки подключения или явного прерывания. Вы можете использовать этот вариант, чтобы избежать ошибок из-за истечения времени ожидания сети. Тем не менее этот способ может породить неопределенное время ожидания. Будьте готовы останавливать подключения при необходимости.

Если не удается выполнить обновление до последних версий ядра, можно решить эту проблему, поместив в файловый ресурс Azure файл и перезаписывая его каждые 30 секунд (или чаще). Это должна быть операция записи, такая как перезапись даты создания или изменения файла. В противном случае можно получить кэшированные результаты, в итоге операция записи не активирует повторное подключение.

В Windows могут появиться следующие ошибки.

Дескриптора или аренды потерянных файлов

Одно из основных назначений общей папки состоит в том, что несколько пользователей и приложений могут одновременно взаимодействовать с находящимися в ней файлами и каталогами. Для обеспечения этого взаимодействия файловые ресурсы предоставляют несколько способов обработки доступа к файлам и каталогам.

При открытии файла из подключенного файлового ресурса Azure по протоколу SMB приложение или операционная система запрашивают файловый дескриптор, который является ссылкой на этот файл. Помимо прочего, приложение задает режим общего доступа к файлам при запросе дескриптора файлов, который указывает уровень эксклюзивности доступа к файлу, применяемому Файлы Azure:

• None: у вас есть исключительный доступ.
• Read: другие могут читать файл, пока он открыт у вас.
• Write: другие могут писать в файл, пока он открыт у вас.
• ReadWrite: сочетание режимов совместного использования Read и Write.
• Delete: другие могут удалить файл, пока он открыт у вас.

Хотя в качестве протокола без отслеживания состояния протокол FileREST не имеет концепции дескрипторов файлов, он предоставляет аналогичный механизм для предоставления доступа к файлам и папкам, которые могут использовать скрипт, приложение или службу: аренду файлов. При аренде файла он обрабатывается как эквивалентный дескриптору файлов с режимом общего доступа к файлам None.

Хотя дескрипторы файлов и механизм аренды служат важной цели, иногда и дескрипторы, и аренда могут быть утеряны. В таком случае могут возникать проблемы с изменением или удалением файлов. Могут отображаться такие сообщения об ошибках:

• Процесс не может получить доступ к файлу, поскольку файл используется другим процессом.
• Завершить действие невозможно, так как файл открыт в другой программе.
• Документ заблокирован для редактирования другим пользователем.
• Указанный ресурс помечен для удаления клиентом SMB.

Решение этой проблемы зависит от того, вызвана ли она потерянным дескриптором или арендой файла.

Причина 1

Дескриптор файла не позволяет изменить или удалить файл/каталог. Для просмотра открытых дескрипторов можно использовать командлет PowerShell Get-AzStorageFileHandle.

Если все клиенты SMB закрыли открытые дескрипторы файла или каталога, но проблема не была устранена, можно принудительно закрыть дескриптор файла.

Решение 1

Чтобы принудительно закрыть дескриптор файла, используйте командлет PowerShell Close-AzStorageFileHandle.

Причина 2

Аренда файла предотвращает изменение или удаление файла. Вы можете проверить, имеет ли файл аренду файла с помощью следующих команд PowerShell. Замените <resource-group>, <file-share><storage-account>и <path-to-file> соответствующими значениями для вашей среды.

# 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

Если у файла есть аренда, возвращаемый объект должен содержать следующие свойства:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Решение 2

Чтобы удалить аренду файла, можно освободить аренду или прервать ее. Чтобы освободить аренду, требуется идентификатор LeaseId аренды, который задается при создании аренды. Вам не нужен Идентификатор аренды для разрыва аренды.

В следующем примере показано, как прервать аренду для файла, указанного в причине 2 (этот пример продолжится с переменными PowerShell из причины 2):

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

Клиенты Linux могут использовать AzFileDiagnostics для автоматизации обнаружения симптомов и обеспечения правильности необходимых компонентов.

В Linux могут появиться следующие проблемы.

Открытые дескрипторы файлов или каталогов

Причина

Эта проблема обычно возникает, если файл или каталог имеет открытый дескриптор.

Решение

Если клиенты SMB закрыли все открытые дескрипторы, но проблема появляется снова, выполните следующие действия.

• Для просмотра открытых дескрипторов используйте командлет PowerShell Get-AzStorageFileHandle.

• Чтобы закрыть открытые дескрипторы, используйте командлет PowerShell Close-AzStorageFileHandle.

Ошибка 1816 ― недостаточно квот для обработки команды

Причина

Ошибка 1816 возникает, когда достигнуто максимальное количество одновременно открытых дескрипторов для файла или каталога в файловом ресурсе Azure. Дополнительные сведения см. в разделе Целевые показатели масштабируемости службы файлов Azure.

Решение

Сократите количество одновременно открытых дескрипторов, закрыв некоторые из них, и повторите попытку. Дополнительные сведения см. в статье Производительность хранилища Microsoft Azure и контрольный список масштабируемости.

Чтобы просмотреть открытые дескрипторы для общей папки, каталога или файла, используйте командлет PowerShell Get-AzStorageFileHandle.

Чтобы закрыть открытые дескрипторы для общей папки, каталога или файла, используйте командлет PowerShell Close-AzStorageFileHandle.

ERROR_UNEXP_NET_ERR (59) при выполнении любых операций с дескриптором

Причина

Если вы кэшируете или храните большое количество открытых дескрипторов в течение длительного времени, может возникнуть эта ошибка на стороне сервера из-за причин регулирования. Когда большое количество дескрипторов кэшируются клиентом, многие из этих дескрипторов могут перейти на этап повторного подключения одновременно, создавая очередь на сервере, который необходимо регулировать. Логика повторных попыток и регулирование серверной части для повторного подключения занимает больше времени ожидания клиента. Эта ситуация проявляется как клиент не в состоянии использовать существующий дескриптор для любой операции, при этом все операции завершаются сбоем с ERROR_UNEXP_NET_ERR (59).

Существуют также пограничные случаи, когда дескриптор клиента отключается от сервера (например, сетевой сбой в течение нескольких минут), который может вызвать эту ошибку.

Решение

Не сохраняйте большое количество дескрипторов в кэше. Закройте дескриптор, а затем повторите попытку. Используйте Get-AzStorageFileHandle командлеты Close-AzStorageFileHandle PowerShell для просмотра и закрытия открытых дескрипторов.

Если вы используете общие папки Azure для хранения контейнеров профилей или образов дисков для масштабируемого развертывания виртуального рабочего стола или других рабочих нагрузок, которые открывают дескрипторы файлов, каталогов и (или) корневого каталога, можно достичь ограничений верхнего масштаба для одновременных открытых дескрипторов. В этом случае используйте дополнительную общую папку Azure и распределите контейнеры или образы между общими папками.

Клиенты Linux могут использовать AzFileDiagnostics для автоматизации обнаружения симптомов и обеспечения правильности необходимых компонентов.

Отображается сообщение "[permission denied] Disk quota exceeded" ([Отказано в разрешении]. Превышена дисковая квота) при попытке открыть файл

В Linux может появиться сообщение об ошибке, похожее на следующее:

<имя> файла [разрешение запрещено] Превышена квота диска

Причина

Вы достигли верхнего предела параллельных открытых дескрипторов, которые разрешены для файла или каталога.

Файлы Azure поддерживает 10 000 открытых дескрипторов в корневом каталоге и 2000 открытых дескрипторов на файл и каталог в общей папке.

Решение

Уменьшите количество параллельных открытых дескрипторов, закрывая некоторые дескрипторы, а затем повторите операцию.

Чтобы просмотреть открытые дескрипторы для общей папки, каталога или файла, используйте командлет PowerShell Get-AzStorageFileHandle.

Чтобы закрыть открытые дескрипторы для общей папки, каталога или файла, используйте командлет PowerShell Close-AzStorageFileHandle.