Устранение неполадок общих папок Azure NFS

Примечание.

CentOS, на который ссылается в этой статье, является дистрибутивом Linux и достигнет конца жизни (EOL). Думайте об использовании и планировании соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

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

Внимание

Содержимое этой статьи относится только к общим папкам NFS. Сведения об устранении неполадок SMB в Linux см. в статье "Устранение неполадок Файлы Azure в Linux (SMB)". Общие папки Azure NFS не поддерживаются для Windows.

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

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

Сбой команды chgrp "имя_файла": недопустимый аргумент (22)

Причина 1. Бездействия не отключена

Так как Файлы Azure запрещает буквенно-цифровые идентификаторы UID/GID, необходимо отключить простой.

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

Даже если вы правильно отключаете бездействия, его можно автоматически повторно включить в некоторых случаях. Например, если Файлы Azure обнаруживает неправильное имя файла, он отправляет ошибку. После просмотра этого кода ошибки клиент Linux NFS 4.1 решает повторно включить идентификацию и отправляет будущие запросы с буквенно-цифровым uiD/GID. Список неподдерживаемых символов в службе "Файлы Azure" см. в этой статье. Одним из неподдерживаемых символов является двоеточие.

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

Убедитесь, что вы отключили простой и что ничего не включаете повторно. В этом случае выполните следующие шаги.

1. Отключите общую папку.

2. Отключение простоя с помощью:

   sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

3. Подключите общую папку обратно.

4. При выполнении rsync выполните rsync с —numeric-ids аргументом из каталога, который не имеет плохого имени каталога или файла.

Не удалось создать общую папку NFS

Причина: неподдерживаемые параметры учетной записи хранения

Файловая система NFS доступна только для учетных записей хранения со следующей конфигурацией:

• уровень — Premium;
• вид учетной записи — FileStorage;
• регионы — список поддерживаемых регионов.

Решение

Следуйте инструкциям из статьи "Создание общей папки NFS".

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

Причина 1. Запрос поступает от клиента из недоверенной сети или с недоверенным IP-адресом

В отличие от SMB, NFS не имеет пользовательской проверки подлинности. Проверка подлинности для общей папки основана на конфигурации правила безопасности сети. Чтобы клиенты устанавливали безопасные подключения только к NFS, необходимо использовать конечную точку службы или частные конечные точки. Чтобы получить доступ к общим ресурсам из локальной среды, помимо частных конечных точек, необходимо настроить VPN-подключение или ExpressRoute. IP-адреса, добавленные в список разрешений учетной записи хранения для брандмауэра, игнорируются. Для настройки доступа к общей папке NFS необходимо использовать один из следующих методов.

• Конечная точка службы

  • Доступна для общедоступной конечной точки.

  • Доступна только в том же регионе.

  • Пиринг виртуальных сетей нельзя использовать для предоставления доступа.

  • Вы должны добавить в список разрешений каждую виртуальную сеть или подсеть по отдельности.

  • Для локального доступа можно использовать конечные точки службы с поддержкой ExpressRoute, а также VPN типов "точка — сеть" и "сеть — сеть". Рекомендуем использовать частную конечную точку, так как она безопаснее.

    На следующей схеме показано подключение с помощью общедоступных конечных точек:

    

• Частная конечная точка

  • Доступ более безопасен, чем при использовании конечной точки службы.

  • Доступ к общей папке NFS через частный канал можно получить как в регионе Azure учетной записи хранения, так и за его пределами (межрегиональный или локальный доступ).

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

  • Частные конечные точки можно использовать вместе с ExpressRoute или VPN типа "точка — сеть" и "сеть — сеть".

    

Причина 2. Включен параметр "Требуется безопасное перемещение"

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

Решение

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

Причина 3: nfs-utils, nfs-client или nfs-common пакет не установлен

Перед выполнением mount команды установите пакет nfs-utils, nfs-client или nfs-common.

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

RHEL

Те же команды в этом разделе применяются к CentOS и Oracle Linux.

sudo rpm -qa | grep nfs-utils

SLES

sudo rpm -qa | grep nfs-client

Ubuntu

Те же команды в этом разделе применяются к Debian.

sudo dpkg -l | grep nfs-common

Решение

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

RHEL

Те же команды в этом разделе применяются к CentOS и Oracle Linux.

ОС версии 7.X

sudo yum install nfs-utils

ОС версии 8.X или 9.X

sudo dnf install nfs-utils

SLES

sudo zypper install nfs-client

Ubuntu

Те же команды в этом разделе применяются к Debian.

sudo apt update
sudo apt install nfs-common

Причина 4. Брандмауэр блокирует порт 2049

Протокол NFS взаимодействует с сервером через порт 2049. Убедитесь, что этот порт открыт для учетной записи хранения (сервер NFS).

Решение

Убедитесь, что в клиенте открыт порт 2049, выполнив следующую команду. Если порт не открыт, откройте его.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

Причина 5. Удаленная учетная запись хранения

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

Решение

Восстановление учетной записи хранения. Затем удалите и повторно создайте частную конечную точку, чтобы она связана с новым идентификатором ресурса учетной записи хранения.

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

Причина: ошибка появилась в ядре Linux версии 5.11 и исправлена в версии 5.12.5

В некоторых версиях ядра имеется ошибка, из-за которой при получении списка файлов в каталоге выполняется бесконечная последовательность READDIR. Небольшие каталоги, в которых все записи могут быть отправлены в одном вызове, не имеют этой проблемы. Эта ошибка появилась в ядре Linux версии 5.11 и была исправлена в версии 5.12.5. Таким образом, она есть во всех промежуточных версиях. RHEL 8.4 имеет эту версию ядра.

Обходное решение: понижение или обновление ядра

Понижение или обновление ядра до всех, что находится за пределами затронутого ядра, должно устранить проблему.

Системные команды завершаются ошибкой "Файл не найден"

Причина

32-разрядные приложения Linux, использующие номера инодеров, могут не работать должным образом с Файлы Azure из-за форматирования 64-разрядных номеров инодеров, созданных службой NFS.

Решение

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

• Сжать 64-разрядные номера инодера до 32 бит с помощью nfs.enable_ino64=0 параметра загрузки ядра.

• Задайте параметр модуля, добавив options nfs enable_ino64=0 в файл /etc/modprobe.d/nfs.conf и перезагрузив виртуальную машину.

Этот параметр загрузки ядра также можно сохранить в файле grub.conf . Дополнительные сведения см. в документации по дистрибутиву Linux.

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

Причина

Разрешения для общих папок NFS применяются клиентской ОС, а не службой Файлы Azure. Если параметр root Squash включен в общей папке NFS, корневой пользователь в клиентской системе рассматривается как анонимный (не привилегированный) пользователь для управления доступом. Это означает, что даже если вы вошли в систему в качестве корневого каталога в клиентской системе, вы не можете использовать chown команду для изменения владения файлами и каталогами, которыми вы не владеете.

Решение

В портал Azure перейдите к общей папке и выберите "Свойства". Измените параметр корневого Squash на No Root Squash. Дополнительные сведения см. в разделе "Настройка корневого сквоша для Файлы Azure".

Без включения корневого Squash корневой пользователь в клиентской системе имеет те же привилегии, что и корневой пользователь в серверной системе. Теперь вы можете chown изменить владение любым файлом или каталогом в общей папке независимо от текущего владельца. После внесения изменений можно повторно включить root Squash при необходимости.

Нужна помощь?

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

См. также

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

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

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