Подключение общего ресурса Azure Files

Когда я пытаюсь смонтировать с помощью следующей команды:

mount -v -t cifs //<storageaccount>.file.core.windows.net/<sharename> <localfolder> -o username=<myuser>,password=<storageaccountkey>,dir_mode=0777,file_mode=0777,vers=3.0

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

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

ошибка монтирования (13): в доступе отказано

И это от dmesg:

[9421.865985] Код состояния возвращен 0xc0000022 STATUS_ACCESS_DENIED

[9421.865994] CIFS VFS: ошибка отправки в SessSetup = -13

[9421.866098] CIFS VFS: сбой cifs_mount с кодом возврата = -13

У меня такая же версия CIFS как ВМ: 6.4.

Я включил SMB2-SMB3-SMB3.1.1 (экспериментальный) в своем ядре (4.4.21-gentoo).

у меня есть самба также установлен (и он также не работает с smbclient), но, насколько я понимаю, они не связаны.

К сожалению, пока нет. Поддерживаются только Atm Windows 8, 10 и Window Server 2012 (R2) при подключении за пределами Azure Datacenter.

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

Больше информации:

https://azure.microsoft.com/en-us/documentation/articles/storage-how-to-use-files-linux/#overview

Я определенно рекомендую вам создать виртуальную машину на базе Windows для выполнения этой работы. Я делаю другую историю в Windows, когда мне нужен надежный сервер / клиент NFS в Windows.

У вас работает с smbclient?

У меня это работает, а "mount -t cifs -overs = 3.0" ... нет.

smbclient //foo.file.core.windows.net/test -mSMB3 -e -Ufoo%longkeyhere==

Вот случай для меня ....

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

Например:

Ошибка команды (с версией SMB 3.0) в Azure

sudo mount -t cifs //storageaccountname.file.core.windows.net/shared /mnt/mount -o vers=3.0,username=xxxxxxx,password=xxxxxxxx,dir_mode=0777,file_mode=0777

Результат:

ошибка монтирования (11): ресурс временно недоступен См. страницу руководства по mount.cifs (8) (например, man mount.cifs)

Рабочая команда (с версией SMB 2.1) в Azure

sudo mount -t cifs //storageaccountname.file.core.windows.net/shared /mnt/mount -o vers=2.1,username=xxxxxxx,password=xxxxxxxx,dir_mode=0777,file_mode=0777

Результат:

Он успешно смонтирован

Недавно я столкнулся с такой же проблемой. Я пытался подключить файловую службу Azure к виртуальной машине Azure Linux. После нескольких попыток он установился.

В последней попытке (RHEL 7.4) я обновил ядро и добавил Samba-client, samba-client-libs.

yum install kernel-3.10.0-862.el7.x86_64 yum install samba-client samba-client-libs

Я считаю, что проблема была в любом из них, он использовал клиент samba, а не cifs-util, или версия ядра не имела какой-либо ошибки.

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

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

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