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

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

Ошибка 5 при подключении общей папки Azure

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

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

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

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

Решение по причине проблемы 1

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

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

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

Решение для второй причины

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

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

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

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

Убедитесь, что разрешения на уровне общего ресурса настроены правильно. См Назначение разрешений на уровне общего ресурса.

Ошибка 53, ошибка 67 или ошибка 87 при подключении или отключении общей папки Azure

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

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

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

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

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

Чтобы использовать командлет Test-NetConnection, необходимо установить модуль Azure PowerShell. Дополнительные сведения см. в модуле Install 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

Solution 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 over QUIC с Синхронизация файлов Azure.

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

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

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

Решение для второй причины

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Причина 3. Имя общей папки не существует или в имени общей папки опечатка

Ошибка 67 может возникать, если учетная запись хранения существует, а конечная точка SMB доступна, но пространство имен SMB или путь к общей папке не могут быть разрешены. Это не проблема с DNS, проблема проверки подлинности или проблема с разрешениями.

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

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

Ошибка 64 при подключении файлового хранилища Azure

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

Произошла системная ошибка 64. Указанное сетевое имя более недоступно.

Причина

Эта проблема, скорее всего, вызвана прокси-сервером или другим типом устройства преобразования сетевых адресов (NAT) в пути данных, который блокирует подключение для сопоставления Azure общей папки. В этом случае командлет Test-NetConnection PowerShell по-прежнему может проверить подключение через порт 445.

Эта проблема возникает, когда Active Directory компьютер или учетная запись пользователя, соответствующая учетной записи хранения Azure, на котором размещены профили пользователей FSLogix, не могут обрабатывать проверки подлинности Kerberos. Основные причины могут включать неправильные изменения атрибута msDS-SupportedEncryptionTypes или смену ключей доступа учетной записи хранения без обновления новых ключей в учетной записи Active Directory.

Решение

Чтобы устранить эту проблему, воспроизводите ее и соберите трассировку сети, чтобы получить дополнительные сведения о источнике ошибки. В большинстве случаев необходимо работать с администратором сети или брандмауэра, чтобы разрешить содержимому передаваться через сетевое устройство.

Ошибки Kerberos можно увидеть в трассировке сети, например потоки, помеченные как ошибка KRB в netsh трассировке. Чтобы устранить их, включите аутентификацию службы доменных услуг Active Directory для общих папок Azure, чтобы правильно настроить параметры проверки подлинности.

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

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

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

Причина

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

Решение

Проверьте, находятся ли какие-либо из следующих служб в состоянии Stopped в виртуальной машине 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 из командной строки с правами администратора сетевой диск сопоставляется от имени администратора. Так как сопоставленные диски ориентированы на пользователя, учетная запись пользователя, вошедшего в систему, не отображает диски, если они подключены в другой учетной записи пользователя.

Решение

Подключите сетевой ресурс из командной строки без прав администратора. Кроме того, вы можете следовать этой теме 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, а виртуальная машина не в том же регионе, что и учетная запись хранения.
• Если параметр Требуется безопасная передача или параметр Требуется шифрование в транзите для SMB включён в настройках учетной записи хранения, Файлы Azure разрешает только подключения, использующие SMB 3.x с шифрованием.

Решение

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

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

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

"Ошибка подключения(13): разрешение запрещено" при подключении общей папки Azure

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

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

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

Решение по причине проблемы 1

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

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

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

Решение для второй причины

Убедитесь, что правила виртуальной сети (VNET) и брандмауэра в учетной записи хранения правильно сконфигурированы и что порт 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.

Причина 5. Для шифрования канала SMB задано только AES-256-GCM

Если учетная запись хранения Azure настроена использовать только AES-256-GCM для шифрования канала SMB, операции подключения завершаются сбоем, если клиент по умолчанию использует AES-128-GCM.

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

Настройте клиент для требования AES-256-GCM, включив этот require_gcm_256 параметр:

# Load the CIFS module
modprobe cifs

# Set the parameter at runtime
echo 1 | sudo tee /sys/module/cifs/parameters/require_gcm_256

# Persist the configuration
echo "options cifs require_gcm_256=1" | sudo tee -a /etc/modprobe.d/cifs.conf

Вы также можете использовать DaemonSet Kubernetes для принудительного применения AES-256-GCM на каждом узле. См. следующий пример.

support-cifs-aes-256-gcm.yaml

"Ошибка монтирования(115): Операция в процессе выполнения" при монтировании Файлы Azure с помощью SMB 3.x

Причина

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

Решение

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

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

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

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

Причина

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

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

Решение

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

• Исправление повторного подключения, чтобы не отложить повторное подключение сеанса smb3 в течение длительного времени после повторного подключения сокета
• Вызов службы эхо сразу после повторного подключения сокета
• CIFS: исправление возможного повреждения памяти во время повторного подключения
• CIFS: исправлена возможная двойная блокировка мьютекса во время повторного подключения (для ядра версии 4.9 и более поздней версии)

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

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

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

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

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

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

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

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

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

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

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

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

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

Причина 1

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

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

Решение 1

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

Причина 2

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

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

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

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

Причина

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

Решение

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

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

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

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

Причина

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

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

Решение

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

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

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

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

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

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

Причина

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

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

Решение

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

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

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