Montando o compartilhamento de arquivos do Azure

Question

Quando tento montar com o seguinte comando:

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

Funciona perfeitamente se eu o executar a partir de uma VM do Ubuntu Azure ou da minha máquina Windows com o comando equivalente.

Tentando executar o mesmo comando na minha caixa do Linux, recebo o seguinte erro:

mount error(13): Permission denied

E isso de dmesg :

[ 9421.865985] Status code returned 0xc0000022 STATUS_ACCESS_DENIED

[ 9421.865994] CIFS VFS: Send error in SessSetup = -13

[ 9421.866098] CIFS VFS: cifs_mount failed w/return code = -13

Eu tenho a mesma versão do CIFS que a VM: 6.4.

Eu habilitei o SMB2-SMB3-SMB3.1.1 (experimental) no meu kernel (4.4.21-gentoo).

Eu tenho samba instalado também (e também não funciona com o smbclient), mas é do meu entendimento que eles não estão relacionados.

    

Answer 1

Infelizmente, você ainda não pode. Atm apenas Windows 8, 10 e Windows Server 2012 (R2) são suportados se forem montados fora do Datacenter do Azure.

The Linux SMB client doesn’t yet support encryption, so mounting a file share from Linux still requires that the client be in the same Azure region as the file share. However, encryption support for Linux is on the roadmap of Linux developers responsible for SMB functionality. Linux distributions that support encryption in the future will be able to mount an Azure File share from anywhere as well.

Mais informações:

link

    

Answer 2

Eu definitivamente recomendo que você crie uma máquina virtual baseada em Windows para fazer o trabalho. Estou fazendo uma história diferente no Windows quando preciso de um servidor / cliente NFS confiável no Windows.

    

Answer 3

Isso funciona para você com o smbclient?

Isso funciona para mim, enquanto "mount -t cifs -overs = 3.0" ... não.

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

    

Answer 4

Aqui é o caso para mim ....

Quando tentei no Azure (minha VM está no Azure e minha conta de armazenamento também está na mesma região) com o SMB 3.0, tenho recebido erros de montagem. Mas quando eu mudei a versão SMB para 2.1, ele teve sucesso. Veja abaixo com exemplos

Por exemplo:

Comando com falha (com a versão SMB 3.0) no 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

Result:

mount error(11): Resource temporarily unavailable Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Comando de trabalho (com a versão SMB 2.1) no 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

Result:

It got mounted successfully

    

Answer 5

Recentemente eu estava enfrentando o mesmo problema. Eu estava tentando montar o serviço de arquivos do Azure na VM do Azure Linux. Depois de várias tentativas, montou.

Na última tentativa (RHEL 7.4), atualizei o Kernel e adicionei o Samba-client, samba-client-libs.

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

Eu acredito que o problema era com um dos dois, ele usava o cliente samba e não o cifs-util ou a versão do kernel não teve algum bug.

    

Answer 6

De acordo com sua descrição, eu testo novamente. Infelizmente, não podemos montar o compartilhamento de arquivos fora das VMs do Azure. Você pode usar comandos para verificar os pacotes instalados e o kernel do SO para suas VMs.

Embora os pacotes da VM e o kernel do SO sejam os mesmos, não é possível montar o Compartilhamento de arquivos do Azure em VMs locais. Na verdade, o servidor Linux hospedado na VM do Azure funcionará porque o Armazenamento de Arquivos do Azure aceita a conexão SMB2.1, se o cliente estiver na mesma região do Azure que o compartilhamento de arquivos.

No entanto, quando você tenta montar localmente, o Armazenamento de Arquivo do Azure solicita SMB 3.0 com Criptografia imposta pelo cliente, mas a Criptografia do SMB 3.0 é algo que o Linux ainda não suporta, portanto, não funcionará neste momento nem mesmo especificado SMB 3.0 em seus comandos.