При попытке подключиться к общей папке Azure в ОС Windows могут возникнуть следующие сообщения об ошибке.
Ошибка 5 при подключении файлового ресурса Azure
- "Произошла системная ошибка 5. Отказано в доступе".
Причина 1: незашифрованный коммуникационный канал
Из соображений безопасности, если коммуникационный канал не зашифрован, а попытка подключения осуществляется не из того же центра обработки данных, в котором находятся файловые ресурсы Azure, то подключение к ним Azure будет заблокировано. Если в учетной записи хранения включен параметр Требуется безопасное перемещение, незашифрованные подключения в одном центре обработки данных также могут быть заблокированы. Шифрование коммуникационного канала выполняется, только если клиентская ОС конечного пользователя поддерживает шифрование SMB.
Windows 8, Windows Server 2012 и более поздние версии каждого системного согласования запросов, включая SMB 3.x, поддерживающий шифрование.
- Подключитесь из клиента, который поддерживает шифрование SMB (Windows 8 либо Windows Server 2012 или более поздней версии).
- Подключитесь с виртуальной машины, размещенной в том же центре обработки данных, что и учетная запись хранения Azure, используемая для общей папки Azure.
- Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения, если клиент не поддерживает шифрование SMB.
Причина 2: правила виртуальной сети или брандмауэра включены для учетной записи хранения
Трафик запрещается, если для учетной записи хранения настроены правила виртуальной сети и брандмауэра при условии, что IP-адрес клиента или виртуальная сеть не разрешают доступ.
Убедитесь, что правила виртуальной сети и брандмауэра надлежащим образом настроены для учетной записи хранения. Чтобы проверить, связана ли проблема с правилами виртуальной сети или брандмауэра, временно задайте для учетной записи хранения параметр Разрешить доступ из всех сетей. Подробнее см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей (предварительная версия).
Причина 3: неправильные разрешения на уровне общего ресурса при использовании проверки подлинности на основе удостоверений
Если пользователи получают доступ к общей папке Azure с помощью проверки подлинности на основе удостоверений, доступ к общей папке завершается ошибкой "Доступ запрещен". Если разрешения на уровне общего доступа неверны.
Убедитесь, что разрешения на уровне общего ресурса настроены правильно. См. раздел "Назначение разрешений на уровне общего ресурса". Назначения разрешений на уровне общего доступа поддерживаются для групп и пользователей, которые были синхронизированы с 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. Использование Синхронизация файлов 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.
Верните параметру LmCompatibilityLevel
значение по умолчанию (3) в следующем подразделе реестра:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Сбой с кодом ошибки 0x800704b3
При попытке подключить общую папку Azure вы получите следующую ошибку:
Код ошибки: 0x800704b3
Символическое имя: ERROR_NO_NET_OR_BAD_PATH
Описание ошибки: сетевой путь был введен неправильно, не существует, или поставщик сети в настоящее время недоступен. Повторите попытку повторного доступа к пути или обратитесь к администратору сети.
Эта ошибка может возникать, если какие-либо основные службы, связанные с сетью Windows, отключены как любая служба, которая явно зависит от этих сетевых служб, не запустится.
Проверьте, находятся ли какие-либо из следующих служб в состоянии "Остановлено " на виртуальной машине Windows:
- Сетевые подключения
- Служба списка сетей
- Служба сведений о подключенных сетях
- Служба интерфейса сохранения сети
- DHCP-клиент
- Вспомогательное приложение для NetBIOS TCP/IP
- Рабочая станция
Если вы найдете его, запустите службы и повторите попытку подключения общей папки Azure.
Приложение или служба не могут получить доступ к подключенному Файлы Azure диску
Диски подключаются для каждого пользователя. Если приложение или служба запущены под учетной записью пользователя, отличной от учетной записи, подключенной к диску, приложение не увидит диск.
Используйте одно из следующих решений:
Используйте для подключения дисков учетную запись пользователя, содержащую это приложение. Можно использовать такой инструмент, как PsExec.
Передайте имя и ключ учетной записи хранения в параметрах net use
имени пользователя и пароля команды.
cmdkey
Используйте команду, чтобы добавить учетные данные в Диспетчер учетных данных. Выполните это действие из командной строки в контексте учетной записи службы либо с помощью интерактивного входа, либо с помощью runas
.
cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
Сопоставьте общий ресурс напрямую, не используя букву подключенного диска. Некоторые приложения могут неправильно подключиться к букве диска, поэтому использование полного пути UNC может быть более надежным:
net use * \\storage-account-name.file.core.windows.net\share
После выполнения этих инструкций при выполнении команды net use для учетной записи системы или сети может появиться следующее сообщение об ошибке: "Произошла системная ошибка 1312. Указанный сеанс входа в систему не существует (A specified logon session does not exist). Возможно, это уже было завершено". Если появится эта ошибка, убедитесь, что имя пользователя, передаваемое в net use
сведения о домене (например: [storage account name].file.core.windows.net
).
В области "Мой компьютер" или "Этот компьютер" отсутствует папка с буквой диска
Если вы сопоставляете общую папку Azure как администратор с помощью net use
команды, общий ресурс, как представляется, отсутствует.
По умолчанию Windows проводник не запускается от имени администратора. При выполнении net use
из командной строки администрирования сетевой диск сопоставляются с администратором. Так как сопоставленные диски ориентированы на пользователя, учетная запись пользователя, вошедшего в систему, не отображает диски, если они подключены в другой учетной записи пользователя.
Подключите общую папку из командной строки без прав администратора. Кроме того, вы можете следовать этому разделуEnableLinkedConnections
TechNet, чтобы настроить значение реестра.
Если учетная запись хранения содержит косую черту (/), то выполнение команды net use завершается сбоем
Команда net use
интерпретирует косую черту вперед (/) как параметр командной строки. Если имя учетной записи пользователя начинается с косой черты, то сопоставление диска завершится сбоем.
Чтобы обойти эту проблему, выполните одно из следующих действий.
Выполните следующую команду PowerShell:
New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
Из пакетного файла выполнить команду можно следующим образом.
Echo new-smbMapping ... | powershell -command –
Заключите значение ключа в двойные прямые кавычки (если первый знак не является косой чертой). Если значение ключа начинается с косой черты (/), используйте интерактивный режим и введите пароль отдельно или повторно создайте ключи, которые не начинаются с этого знака.
Команда New-PSDrive завершается ошибкой "Тип сетевого ресурса некорректна"
Это сообщение об ошибке может появиться, если общая папка недоступна. Например, порт 445 заблокирован или возникла проблема с разрешением DNS.
Убедитесь, что порт 445 открыт и проверяет разрешение DNS и подключение к общей папке.
Клиенты Linux могут использовать AzFileDiagnostics для автоматизации обнаружения симптомов и обеспечения правильности необходимых компонентов.
Ниже приведены распространенные причины этой проблемы:
- Вы используете дистрибутив Linux с устаревшим клиентом SMB. Дополнительные сведения о распространенных дистрибутивах Linux в Azure с совместимыми клиентами см. в статье Использование Файлов Azure с Linux.
- Служебные программы SMB (cifs-utils) не установлены на клиенте.
- Минимальная версия SMB 2.1 недоступна на клиенте.
- Шифрование SMB 3.x не поддерживается на клиенте. В приведенной выше таблице представлен список дистрибутивов Linux, поддерживающих подключение из локальной среды и между регионами с использованием шифрования. В других дистрибутивах нужно использовать ядро 4.11 или более поздней версии.
- Вы пытаетесь подключиться к общей папке Azure с виртуальной машины Azure, и виртуальная машина не в том же регионе, что и учетная запись хранения.
- Если для учетной записи хранения включен параметр Требуется безопасное перемещение, то служба файлов Azure разрешает подключения только по протоколу SMB 3.x с шифрованием.
Чтобы устранить эту проблему, используйте средство устранения неполадок с подключением в службе файлов Azure для Linux. Это средство предоставляет следующие возможности:
- Помогает проверить среду выполнения клиента.
- Выявляет несовместимые конфигурации клиента, которые приведут к ошибкам доступа в файлах Azure.
- Предоставляет рекомендации для самостоятельного исправления.
- Собирает диагностические трассировки.
"Mount error(13): Permission denied" (Ошибка подключения(13). Отказ в разрешении) при подключении общей папки Azure
Причина 1: незашифрованный коммуникационный канал
По соображениям безопасности подключения к общим папкам Azure блокируются, если канал связи не зашифрован, и попытка подключения не выполняется из того же центра обработки данных, где находятся общие папки Azure. Незашифрованные подключения в одном центре обработки данных также могут быть заблокированы, если в учетной записи хранения включен параметр Требуется безопасное перемещение. Зашифрованный канал связи предоставляется только в том случае, если клиентская ОС пользователя поддерживает шифрование SMB.
Подробнее см. в статье Предварительные требования для подключения файлового ресурса Azure с помощью Linux и пакета cifs-utils.
- Подключитесь из клиента, который поддерживает шифрование SMB или подключитесь из виртуальной машины в том же центре обработки данных, что и учетная запись хранения Azure, используемая для общей папки Azure.
- Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения, если клиент не поддерживает шифрование SMB.
Причина 2. В учетной записи хранения включены правила виртуальной сети или брандмауэра или порт 445 заблокирован.
Если для учетной записи хранения настроены правила виртуальной сети и брандмауэра, доступ сетевого трафика будет запрещен, если IP-адрес клиента или виртуальная сеть не разрешают доступ. Кроме того, если ваша компания или ISP блокирует исходящий порт 445, вы не сможете подключить общую папку.
Убедитесь, что правила виртуальной сети и брандмауэра настроены правильно в учетной записи хранения и разрешенный порт 445. Чтобы проверить, вызвана ли проблема виртуальными сетями или правилами брандмауэра, можно временно изменить параметр учетной записи хранения, чтобы разрешить доступ из всех сетей. Подробнее см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей (предварительная версия).
Файлы Azure поддерживает только NTLMv2 (только ключ учетной записи хранения) и проверку подлинности Kerberos для общих папок SMB. NTLMv1 не поддерживается. Ядро 3.3 и более поздние версии по умолчанию для NTLMv2, если не переопределен параметр подключения sec
. Ядра 4.4 и более поздних версий включите NTLMv2 по умолчанию и отключите LANMAN. В конфигурациях по умолчанию NTLMv1 хранится только в качестве варианта согласования. Дополнительные сведения см. в документации по ОС.
Убедитесь, что команды подключения SMB не переопределяют проверку подлинности NTLMv2 по умолчанию с помощью sec
параметра. Этот sec
параметр никогда не должен использоваться ntlm
или ntlmi
при подключении к общим папкам SMB Azure. Если вы устанавливаете глобальные параметры в файле /etc/samba/smb.conf, убедитесь, что вы не отключаете NTLMv2.
Причина 4. Доступ к ключу учетной записи хранения отключен или запрещен с помощью политики
Если доступ к ключу учетной записи хранения отключен или запрещен для учетной записи хранения, маркеры SAS и ключи доступа не будут работать.
Вместо этого используйте проверку подлинности на основе удостоверений. Сведения о предварительных требованиях и инструкциях см. в статье "Включение проверки подлинности Active Directory через SMB для клиентов Linux, обращаюющихся к Файлы Azure".
Отображается ошибка «Mount error(115): Operation now in progress» (Ошибка подключения (115). Идет выполнение операции) при подключении службы файлов Azure с помощью SMB 3.x
Сейчас некоторые дистрибутивы Linux не поддерживают функции шифрования в SMB 3.x. Из-за этого при попытке подключения службы файлов Azure с помощью SMB 3.x пользователь может получить сообщение об ошибке 115. SMB 3.x с полным шифрованием поддерживается только в последней версии дистрибутива Linux.
Функция шифрования протокола SMB 3.x для Linux появилась в ядре версии 4.11. Эта функция позволяет подключать общую папку Azure из локальной среды или другого региона Azure. Некоторые дистрибутивы Linux, возможно, изменились с ядра 4.11 на старые версии ядра Linux, которые они поддерживают. Чтобы определить, поддерживает ли ваша версия Linux SMB 3.x с шифрованием, обратитесь к разделу Use Файлы Azure with Linux.
Если клиент SMB Linux не поддерживает шифрование, подключите Файлы Azure с помощью SMB 2.1 с виртуальной машины Linux, которая находится в том же центре обработки данных Azure, что и общая папка. Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения.
Отображается сообщение "Mount error(112): Host is down" (Ошибка подключения (112). Узел не работает) из-за истечения времени ожидания повторного подключения
Ошибка подключения (112) возникает в клиенте Linux, если он бездействует в течение длительного времени. После длительного простоя клиент отключается и время ожидания подключения.
Подключение может бездействовать по следующим причинам:
- Сбои сетевого подключения, которые препятствуют повторному установке TCP-подключения к серверу при использовании параметра подключения по умолчанию "soft".
- Последние исправления повторного подключения, которые отсутствуют в старых ядрах.
Эта проблема повторного подключения в ядре Linux исправлена в рамках следующих изменений:
Однако эти изменения еще не переносились ко всем дистрибутивам Linux. Если вы используете популярный дистрибутив Linux, вы можете проверить, Файлы Azure с Linux, чтобы узнать, какая версия дистрибутива имеет необходимые изменения ядра.
Можно обойти эту проблему, указав жесткое подключение. Жесткое подключение вынудит клиент ожидать установки подключения или явного прерывания. Вы можете использовать этот вариант, чтобы избежать ошибок из-за истечения времени ожидания сети. Тем не менее этот способ может породить неопределенное время ожидания. Будьте готовы останавливать подключения при необходимости.
Если не удается выполнить обновление до последних версий ядра, можно решить эту проблему, поместив в файловый ресурс Azure файл и перезаписывая его каждые 30 секунд (или чаще). Это должна быть операция записи, такая как перезапись даты создания или изменения файла. В противном случае можно получить кэшированные результаты, в итоге операция записи не активирует повторное подключение.