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

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

Примечание.

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

Важно!

Эта статья относится только к общим папкам SMB. Дополнительные сведения об общих ресурсах сетевой файловой системы (NFS) см. в статье Устранение неполадок с общими папками Azure NFS.

Сфера применения

Тип общей папки	SMB	NFS
Общие папки уровня "Стандартный" (GPv2), LRS/ZRS
Общие папки уровня "Стандартный" (GPv2), GRS/GZRS
Общие папки уровня "Премиум" (FileStorage), LRS/ZRS

Не удается подключиться к общей папке Azure или подключить ее

Выберите вкладку Windows или Linux в зависимости от операционной системы клиента, которую вы используете для доступа к общим папкам Azure.

Windows

При попытке подключиться к общей папке 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 с помощью Active Directory (AD) или Доменные службы Microsoft Entra проверки подлинности, доступ к общей папке завершается ошибкой "Доступ запрещен", если разрешения на уровне общего ресурса неверны.

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

Убедитесь, что разрешения настроены правильно:

• доменные службы Active Directory (AD DS) см. раздел Назначение разрешений на уровне общего ресурса.

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

• Доменные службы Microsoft Entra см. раздел Назначение разрешений на уровне общего ресурса.

Ошибка 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

Примечание.

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

Решения для причины 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 over QUIC с Синхронизация файлов Azure.

Решение 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. Указанный сеанс входа не существует. Возможно, она уже прекращена". Если возникает эта ошибка, убедитесь, что имя пользователя, переданное в net use , содержит сведения о домене (например, [storage account name].file.core.windows.net).

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

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

Причина

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

Решение

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

Команда 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

Распространенные причины этой проблемы:

• Вы используете дистрибутив 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.
• Содержит предписывающие рекомендации по самостоятельному исправлению.
• Собирает диагностика трассировки.

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

Причина 1. Незашифрованный канал связи

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

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

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

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

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

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

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

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

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

"Ошибка подключения(112): узел не работает" из-за истечения времени ожидания повторного подключения

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

Причина

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

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

Решение

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

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

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

Обходной путь

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

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

Не удается получить доступ, изменить или удалить общую папку Azure (или предоставить общий доступ к snapshot)

Ошибка "Неправильное имя пользователя или пароль" после отработки отказа, инициированной клиентом

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

Ошибка "Нет доступа" при попытке доступа к общей папке Azure или ее удалении

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

Нет доступа: 403

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

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

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

Причина 2. У вашей учетной записи пользователя нет доступа к учетной записи хранения

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

Перейдите к учетной записи хранения, в которой находится общая папка Azure, выберите Управление доступом (IAM) и убедитесь, что у вашей учетной записи пользователя есть доступ к учетной записи хранения. Дополнительные сведения см. в статье Защита учетной записи хранения с помощью управления доступом на основе ролей Azure (Azure RBAC).

Блокировки и аренда файлов

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

• Блокировки ресурсов учетной записи хранения. Все ресурсы Azure, включая учетную запись хранения, поддерживают блокировки ресурсов. Блокировки могут быть помещены в учетную запись хранения администратором или службами, такими как Azure Backup. Существует два варианта блокировки ресурсов: изменение, которое предотвращает все изменения учетной записи хранения и ее ресурсов, и удаление, которое предотвращает только удаление учетной записи хранения и ее ресурсов. При изменении или удалении общих папок через Microsoft.Storage поставщик ресурсов блокировка ресурсов применяется к общим папкам Azure и моментальным снимкам общих папок. Большинство операций портала, Azure PowerShell командлетов для Файлы Azure с командами Rm в имени (например, Get-AzRmStorageShare), и Azure CLI в share-rm группе команд (например, az storage share-rm list) используют Microsoft.Storage поставщик ресурсов. Некоторые средства и служебные программы, такие как Обозреватель службы хранилища, устаревшие Файлы Azure командлеты управления PowerShell без Rm указания имени (например, Get-AzStorageShare), и устаревшие команды cli Файлы Azure в share группе команд (например, az storage share list) используют устаревшие API в API FileREST, которые обходят Microsoft.Storage поставщик ресурсов и блокировки ресурсов. Дополнительные сведения о устаревших API управления, предоставляемых в API FileREST, см. в разделе Уровень управления в Файлы Azure.

• Аренда общих ресурсов и общих ресурсов snapshot. Аренда общих ресурсов — это своего рода частная блокировка для общих папок Azure и моментальных снимков общих папок. Администраторы могут использовать аренду для отдельных общих папок Azure или моментальных снимков общих папок путем вызова API с помощью скрипта или служб с добавленной стоимостью, таких как Azure Backup. Когда аренда помещается в общую папку Azure или общую папку snapshot, изменение или удаление snapshot файлового ресурса или общей папки можно выполнить с помощью идентификатора аренды. Администраторы также могут освободить аренду перед операциями изменения, для которых требуется идентификатор аренды, или разорвать аренду, для которой не требуется идентификатор аренды. Дополнительные сведения об аренде общих общей папки см. в разделе Арендная папка.

Так как блокировки и аренды ресурсов могут мешать предполагаемым операциям администратора в вашей учетной записи хранения или общих папках Azure, вы можете удалить все блокировки и аренды ресурсов, которые были помещены в ресурсы вручную или автоматически службами с дополнительными преимуществами, такими как Azure Backup. Следующий скрипт удаляет все блокировки ресурсов и аренды. Не забудьте заменить <resource-group> и <storage-account> соответствующими значениями для вашей среды.

Перед выполнением следующего сценария необходимо установить последнюю версию модуля PowerShell службы хранилища Azure.

Важно!

Службы с дополнительными преимуществами, которые принимают блокировки ресурсов и совместное использование и snapshot аренду ресурсов Файлы Azure, могут периодически повторно использовать блокировки и аренды. Изменение или удаление заблокированных ресурсов службами с добавленной стоимостью может повлиять на обычную работу этих служб, например удаление моментальных снимков общих папок, управляемых Azure Backup.

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

Не удается изменить, переместить, переименовать или удалить файл или каталог

Выберите вкладку Windows или Linux в зависимости от операционной системы клиента, которую вы используете для доступа к общим папкам Azure.

Windows

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

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

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

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

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

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

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

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

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

Примечание.

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

Причина 1

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

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

Решение 1

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

Примечание.

Командлеты Get-AzStorageFileHandle и Close-AzStorageFileHandle включены в модуль Az PowerShell версии 2.4 или более поздней. Сведения об установке последней версии модуля Az PowerShell см. в статье Установка модуля Azure PowerShell.

Причина 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 аренды, заданное при создании аренды. Для прерывания аренды значение LeaseId не требуется.

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

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

Linux

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

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

Причина

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

Решение

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

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

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

Примечание.

Командлеты Get-AzStorageFileHandle и Close-AzStorageFileHandle включены в модуль Az PowerShell версии 2.4 или более поздней. Сведения об установке последней версии модуля Az PowerShell см. в статье Установка модуля Azure PowerShell.

Не удается подключить общую папку Azure snapshot в Linux

"Ошибка подключения(22): недопустимый аргумент" при попытке подключения общей папки Azure snapshot в Linux

Причина

snapshot Если параметр для mount команды не передается в распознаваемом формате, mount команда может завершиться ошибкой с этой ошибкой. Чтобы подтвердить это, проверка сообщениях журнала ядра (dmesg), а dmesg отобразит запись журнала, cifs: Bad value for 'snapshot'например .

Решение

Убедитесь, что вы передаете snapshot параметр для mount команды в правильном формате. См. страницу вручную mount.cifs (например, man mount.cifs). Распространенной ошибкой является передача метки времени GMT в неправильном формате, например использование дефисов или двоеточий вместо точек. Дополнительные сведения см. в разделе Подключение общей папки snapshot.

"Недопустимый маркер snapshot" при попытке подключения общей папки Azure snapshot в Linux

Причина

Если параметр snapshot mount передается, начиная с @GMT, но формат по-прежнему неправильный (например, использование дефисов и двоеточий вместо точек), mount команда может завершиться ошибкой.

Решение

Убедитесь, что вы передаете метку времени GMT в правильном формате, то есть @GMT-year.month.day-hour.minutes.seconds. Дополнительные сведения см. в разделе Подключение общей папки snapshot.

"Ошибка подключения(2): нет такого файла или каталога" при попытке подключить общую папку Azure snapshot

Причина

Если snapshot, которую вы пытаетесь подключить, не существует, mount команда может завершиться ошибкой. Чтобы подтвердить это, проверка сообщения журнала ядра (dmesg), а dmesg отобразит запись журнала, например:

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

Решение

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

Ошибки квоты диска или сети из-за слишком большого количества открытых дескрипторов

Выберите вкладку Windows или Linux в зависимости от операционной системы клиента, которую вы используете для доступа к общим папкам Azure.

Windows

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

Причина

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

Решение

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

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

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

Примечание.

Командлеты Get-AzStorageFileHandle и Close-AzStorageFileHandle включены в модуль Az PowerShell версии 2.4 или более поздней. Сведения об установке последней версии модуля Az PowerShell см. в статье Установка модуля Azure PowerShell.

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

Причина

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

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

Решение

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

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

Linux

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

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

<filename> [отказано в разрешении] Превышена квота диска

Причина

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

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

Решение

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

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

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

Примечание.

Командлеты Get-AzStorageFileHandle и Close-AzStorageFileHandle включены в модуль Az PowerShell версии 2.4 или более поздней. Сведения об установке последней версии модуля Az PowerShell см. в статье Установка модуля Azure PowerShell.

Ошибка "Вы копируете файл в место назначения, которое не поддерживает шифрование"

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

Причина

Эта проблема может возникнуть, если вы используете шифрующую файловую систему (EFS). Файлы, зашифрованные BitLocker, можно скопировать в Файлы Azure. Однако Файлы Azure не поддерживает NTFS EFS.

Обходной путь

Чтобы скопировать файл по сети, необходимо сначала расшифровать его. Используйте один из следующих способов:

• Используйте команду copy /d . Это позволяет сохранять зашифрованные файлы в качестве расшифрованных файлов в месте назначения.
• Задайте следующий раздел реестра:
  • Путь = HKLM\Software\Policies\Microsoft\Windows\System
  • Тип значения = DWORD
  • Name = CopyFileAllowDecryptedRemoteDestination
  • Значение = 1

Имейте в виду, что установка раздела реестра влияет на все операции копирования, выполняемые в сетевых общих папках.

Ошибка ConditionHeadersNotSupported из веб-приложения с помощью Файлы Azure из браузера

Ошибка ConditionHeadersNotSupported возникает при сбое доступа к содержимому, размещенного в Файлы Azure через приложение, использующее условные заголовки, например веб-браузер. Ошибка указывает, что заголовки условий не поддерживаются.

Причина

Условные заголовки пока не поддерживаются. Приложения, реализующие их, должны запрашивать полный файл каждый раз при доступе к файлу.

Обходной путь

При отправке нового файла свойство CacheControl по умолчанию не является кэшем. Чтобы заставить приложение запрашивать файл каждый раз, необходимо обновить свойство CacheControl файла с no-cache до no-cache, no-store, must-revalidate. Этого можно добиться с помощью Обозреватель службы хранилища Azure.

См. также

• Устранение неполадок Файлы Azure
• Устранение неполадок с производительностью Файлы Azure
• Устранение неполадок проверки подлинности и авторизации Файлы Azure (SMB)
• Устранение Файлы Azure общих проблем SMB в Linux
• Устранение Файлы Azure общих проблем с NFS в Linux
• Устранение неполадок Синхронизация файлов Azure

Свяжитесь с нами для получения помощи

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