Поделиться через

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

  • Статья

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

Примечание.

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

Внимание

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

Применяется к

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

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

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

Примечание.

Эта команда возвращает текущий 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 по QUIC.

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

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

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

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

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

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

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

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

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

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

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

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

Причина

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

Решение

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

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

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

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

Причина

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

Решение

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

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

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

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

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

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

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

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

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

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

Причина

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

Решение

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

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

Причина

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

Решение

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

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

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

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

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

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

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

Причина

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

Решение

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

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

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

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

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

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

Код ошибки доступа: 403

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

Примечание.

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

Причина 1

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

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

Решение 1

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

Примечание.

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

Причина 2

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

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

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

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

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

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Решение 2

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

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

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

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

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

Причина

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

Решение

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

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

Причина

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

Решение

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

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

Причина

Если моментальный снимок, который вы пытаетесь подключить, не существует, 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

Решение

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

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

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

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

Причина

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

Решение

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

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

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

Примечание.

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

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

Причина

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

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

Решение

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

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

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

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

Причина

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

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

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

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

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

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

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

Снимок экрана: сообщение об ошибке ConditionHeadersNotSupported.

Причина

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

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

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

Screeshot, показывающий свойство файла CacheControl.

См. также

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

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