A montagem do CIFS falha no Ubuntu 13.10 tentada com sec = ntlm e sec = ntlmv2

Question

Eu li praticamente todas as questões de montagem do cifs e infelizmente não consigo obter um compartilhamento cifs para montar.

O comando que estou usando funciona de uma máquina redhat mas não do Ubuntu 13.10 (kernel 3.11.0-15-generic)

O comando que eu uso é

sudo mount -t cifs //server01.mycompany.com/archive$/StructuralBiology/RAW-Data /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000

Eu tentei isso com sec=ntlm , sec=ntlmv2 e ainda não funciona.

O comando cifs falha com:

mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

E o dmesg tem uma mensagem:

[169895.357046] CIFS VFS: cifs_mount failed w/return code = -13
[170370.733123] CIFS VFS: cifs_read_super: get root inode failed

Passei dias tentando encontrar uma resposta e não consigo: qualquer ajuda ou ponteiros serão muito apreciados.

    

Answer 1

Portanto, parece que os kernels Linux no Ubuntu 13.10 podem ter padrões diferentes para o programa mount.cifs.

Eu estava lendo a documentação do cifs e tinha o texto:

vers=
           SMB protocol version. Allowed values are:

           ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

           ·   2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and
               Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different
               dialect (2.000) that is not supported.

           ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

           ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.

Assumi, portanto, que o arquivo $ era um servidor baseado no Microsoft Windows 7 e Windows Server 2008R2.

Então finalmente recebi este comando (antigo comando com o vers = 2.1 adicionado) para montar o compartilhamento

alias mountr2='sudo mount -t cifs //server01.mycompany.com/archive$/StructuralBiology/RAW-Data /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000,vers=2.1

O compartilhamento é montado como antes com permissões completas de leitura e gravação. Infelizmente isso me levou muito tempo (mais dois meses) para descobrir.

Esperando que o módulo cifs e o programa mount.cifs possam enviar mensagens de erro mais úteis e significativas para não tornar esse processo uma caixa-preta.

    

Answer 2

Eu tive esse problema em várias redes que precisavam de serviços de compartilhamento de arquivos samba de um servidor de arquivos baseado em Ubuntu ou LinuxMint.

Em todos casos, enquanto a conta samba do usuário tinha uma senha e permissão para navegar (e manipular arquivos) de um compartilhamento através de um gerenciador de arquivos, as montagens fstab não funcionavam .

Isso ocorre independentemente de ter definido sec = ntlm ou sec = ntlmv2 ou sec = ntlmssp ou qualquer uma das várias outras opções normalmente oferecidas como uma "solução" (por exemplo, configurando o file_mode ou user ou gid)

Em todos casos a solução para nossas instalações acabou sendo a mesma: redefinir a senha do usuário samba e a montagem funciona, independentemente das opções de configuração!

Não sei ao certo o que acontece quando a senha é "herdada / convertida" da conta Linux do usuário, mas parece haver um problema significativo, não obstante a capacidade de navegar (não montar) um compartilhamento de samba.

Agora vou postar esta resposta em um par de postagens semelhantes do AskUbuntu que promovem as mesmas "respostas" que muitas vezes não parecem ajudar as pessoas com problemas.

Talvez essa abordagem ajude você com seu desafio de montagem de samba fstab. Espero que sim e boa sorte.

    

Answer 3

Recentemente encontrei este problema. Seu problema é que você não pode montar uma subpasta de um compartilhamento smb / cifs - você só pode montar o compartilhamento em si (ou seja, não tente montar '// servidor / share / dir-1 / dir-2 / dir -3 ', em vez disso monte' // server / share '). Experimente ...

  

sudo mount -t cifs // servidor01.mycompany.com/archive$ / home / rawdata2 -o   user = hari.lastname, rw, suave, nosuid, uid = 1000, gid = 1000

... e depois acessar o diretório desejado via '/ home / rawdata2 / StructuralBiology / RAW-Data'

Se você realmente quer que o diretório 'RAW-Data' esteja disponível como '/ home / rawdata2', então você pode montar o compartilhamento em um local fora do caminho e usar um symlink como este ...

  

sudo mount -t cifs //server01.mycompany.com/archive$   /home/.hidden-mount -o   user = hari.lastname, rw, suave, nosuid, uid = 1000, gid = 1000

     

ln -s   /home/.hidden-mount/StructuralBiology/RAW-Data / home / rawdata2

    

Answer 4

mount -t cifs -o ro,iocharset=utf8,sec=ntlm,username=everyone,password=null,vers=3.0 //file.biliops.com/Public-Share /mnt/cifs 

Sucesso.

    

Answer 5

Eu sei que não se trata exatamente do seu problema, mas eu só quero adicionar uma nota para as pessoas que usam o método de montagem KRB5 e ver:

mount error(13): Permission denied

Eu estava me deparando com um problema no kernel 8.10 do Debian 8.10, onde o KRB5 + SMB1.0 era a única combinação que funcionava.

A montagem usando vers = {2.0, 2.1, 3.0} resultou em Permission Denied, mas isso estava funcionando em outros hosts Linux (mais recentes).

A atualização para o kernel 4.10 corrigiu esse problema. Espero que isso ajude alguém lá fora!