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

Устранение неполадок Файлы Azure в Linux (SMB)

  • Статья

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

С помощью AzFileDiagnostics можно автоматизировать обнаружение симптомов и убедиться, что клиент Linux имеет правильные предварительные требования. Это средство помогает настроить среду для оптимальной производительности. Эти сведения также можно найти в статье Средство устранения неполадок с общими папками в Azure.

Внимание

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

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

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

Метки времени были потеряны при копировании файлов

На платформах Linux и Unix команда завершается ошибкой cp -p , если разные пользователи имеют файл 1 и файл 2.

Причина

Флаг принудительной силы f в COPYFILE приводит к выполнению cp -p -f в Unix. Этой команде также не удается сохранить метку времени файла, который вам не принадлежит.

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

Используйте пользователя учетной записи хранения для копирования файлов:

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls: не удается получить доступ к "<path>": ошибка ввода-вывода

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

ls: не удается получить доступ к "<path>": ошибка ввода-вывода

Решение

Обновите ядро Linux до одной следующих версий, в которых эта проблема уже решена:

  • 4.4.87+;
  • 4.9.48+;
  • 4.12.11+;
  • любая версия не ниже 4.13.

Не удается создать символьные ссылки — ln: не удалось создать символьную ссылку 't': операция не поддерживается

Причина

По умолчанию подключение общих папок Azure в Linux с помощью SMB не обеспечивает поддержку символьных ссылок (symlinks). Может появиться сообщение об ошибке:

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

Решение

Клиент SMB Linux не поддерживает создание символьных ссылок в стиле Windows по протоколу SMB 2 или 3. Сейчас клиент Linux поддерживает для операций создания и отслеживания символьные ссылки в другом стиле (Minshall/French). Если клиенту требуются символьные ссылки, он может использовать параметр подключения mfsymlinks. Мы рекомендуем использовать mfsymlinks, так как этот формат используется компьютерами Mac.

Чтобы использовать символы, добавьте следующее в конец команды подключения SMB:

,mfsymlinks

Поэтому команда выглядит следующим образом:

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

Теперь вы сможете создавать символьные ссылки, как описано на вики-сайте.

Не удается получить доступ к папкам или файлам, в именах которых есть пробел или точка в конце

Невозможно получить доступ к папкам или файлам из общей папки Azure во время подключения к Linux. Команды, такие как du и ls и/или сторонние приложения, могут завершиться ошибкой "Нет такого файла или каталога" при доступе к общей папке; однако вы можете отправлять файлы в эти папки с помощью портал Azure.

Причина

Папки или файлы были отправлены из системы, которая кодирует символы в конце имени в другой символ. Файлы, отправленные с компьютера Macintosh, могут иметь символ "0xF028" или "0xF029", а не 0x20 (пробел) или 0X2E (точка).

Решение

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

Вместо:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

Используйте:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Проблемы DNS с динамической миграцией учетных записей хранения Azure

Операции ввода-вывода файлов в подключенной файловой системе выдают ошибки "Узел не работает" или "Отказано в доступе". Журналы Dmesg Linux на клиенте показывают повторяющиеся ошибки, такие как:

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

Вы также увидите, что полное доменное имя сервера теперь разрешается в другой IP-адрес, чем тот, к которому он подключен. Эта проблема может возникнуть в любом случае, когда IP-адрес сервера может измениться, например миграция учетной записи. Другой известный сценарий — отработка отказа учетной записи хранения, так как сопоставление DNS может измениться.

Причина

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

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

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

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

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

  1. Отображение состояния модуля ядра dns_resolver , выполнив следующую команду:

    grep '.dns_resolver' /proc/keys

    Вы должны увидеть выходные данные команды, как показано в следующем примере:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. Снимите кэш сопоставителя DNS ядра, выполнив следующую команду:

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. Снова отобразите состояние модуля ядра dns_resolver :

    grep '.dns_resolver' /proc/keys

    Вы должны увидеть выходные данные команды, как в следующем примере, указывая, что кэш теперь пуст:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

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

Примечание.

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

Решение

Для окончательного исправления обновите клиентскую ОС до версии дистрибутива Linux с поддержкой переноса учетных записей. Несколько исправлений для клиента ядра SMB Linux были отправлены в основное ядро Linux. Следующие дистрибутивы содержат исправления:

  • Ubuntu: 20.04, 22.04, 24.04 и AKS 22.04 (исправления развертываются в ядре версии 5.15.0-1068)
  • RHEL: 8.6+
  • SLES: 15SP2, 15SP3, 15SP4 и 15SP5
  • Azure Linux: 2.0 (исправления развертываются в ядрах версии 5.15.159.1) и 3.0

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

Не удается подключить общую папку SMB при включении FIPS

Если в виртуальной машине Linux включена стандартная федеральная обработка информации (FIPS), общая папка SMB не может быть подключена. Журналы dmesg Linux на клиенте отображают такие ошибки, как:

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

Внимание

FIPS — это набор стандартов, которые правительство США использует для обеспечения безопасности и целостности компьютерных систем. Если система находится в режиме FIPS, она соответствует определенным требованиям шифрования, описанным в этих стандартах.

Причина

Клиент общей папки SMB использует проверку подлинности NTLMSSP, которая требует алгоритма хэширования MD5. Однако в режиме FIPS алгоритм MD5 ограничен, так как он не соответствует FIPS. MD5 — это широко используемая хэш-функция, которая создает 128-разрядное хэш-значение. Однако MD5 считается небезопасным для криптографических целей.

Как проверить, включен ли режим FIPS

Чтобы проверить, включен ли режим FIPS на клиенте, выполните следующую команду. Если для значения задано значение 1, то fiPS включен.

sudo cat /proc/sys/crypto/fips_enabled

Решение

Чтобы устранить эту проблему, включите проверку подлинности Kerberos для общей папки SMB. Если FIPS включен непреднамеренно, обратитесь к параметру 2 , чтобы отключить его.

Вариант 1. Включение проверки подлинности Kerberos для общей папки SMB

Чтобы подключить общую папку SMB на виртуальной машине Linux, где включен FIPS, используйте проверку подлинности Kerberos/Azure AD. Дополнительные сведения см. в статье "Включение проверки подлинности Active Directory через SMB для клиентов Linux, обращаюющихся к Файлы Azure".

Вариант 2. Отключение FIPS для подключения общей папки Samba

  1. Измените значение crypto.fips_enabled sysctl на 0 в /etc/sysctl.conf.

  2. Измените GRUB_CMDLINE_LINUX_DEFAULT файл /etc/default/grub и удалите параметр fips=1.

  3. Перестроили файл конфигурации grub2 с помощью следующей команды:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. Перестройте образ initramfs с помощью следующей команды:

    sudo dracut -fv

  5. Перезагрузите виртуальную машину.

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

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

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

См. также

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

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