Устранение неполадок с подключением и доступом Файлы 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 или Azure 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. В этом случае командлет PowerShell Test-NetConnection может по-прежнему успешно проверять подключение к порту 445.

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

Решение

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

Ошибки Kerberos можно увидеть в сетевой трассировке, например потоки, помеченные как KRB Error в трассировке 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, а виртуальная машина не в том же регионе, что и учетная запись хранения.
• Если для учетной записи хранения включен параметр Secure transfer required или параметр Require encryption in transit for 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 заблокирован.

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

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

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

Чтобы проверить и обновить правила виртуальной сети, используйте портал Azure или Azure CLI.

Чтобы использовать портал Azure, выполните следующие действия.

1. На портале Azure перейдите к учетной записи хранения.
2. В разделе "Безопасность и сеть" выберите "Сеть".
3. На вкладке Брандмауэры и виртуальные сети убедитесь, что выбран параметр Включено для выбранных виртуальных сетей и IP-адресов и что в разделе Виртуальные сети отображаются ваша виртуальная сеть и подсеть виртуальной машины.
4. Если подсеть не указана, нажмите кнопку "Добавить существующую виртуальную сеть", выберите виртуальную сеть и подсеть, а затем нажмите кнопку "Добавить". Выберите Сохранить, чтобы применить изменения.

Чтобы получить список текущих правил виртуальной сети с помощью Azure CLI, выполните следующую команду:

az storage account network-rule list --resource-group "<resource-group>" --account-name "<storage-account>" --query virtualNetworkRules

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

subnetid=$(az network vnet subnet show --resource-group "<resource-group>" --vnet-name "<vnet-name>" --name "<subnet-name>" --query id --output tsv)
az storage account network-rule add --resource-group "<resource-group>" --account-name "<storage-account>" --subnet $subnetid

Чтобы проверить подключение SMB после проверки правил сети, используйте средство AzFileDiagnostics.

Дополнительные сведения см. в статье Настройка брандмауэров службы хранилища 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 могут переносить изменения из ядра 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.

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

Причина 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).

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

Решение

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

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

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

Ошибка "[отклонено разрешение] Превышена квота диска" при попытке открыть файл

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

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

Причина

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

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

Решение

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

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

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