cifs pasta montada continua desconectando (servidor ubuntu)

2

Eu tenho essa entrada fstab para permitir que um aplicativo tomcat leia / grave em uma pasta compartilhada do Windows Samba:

//dc/docs    /media/docs      cifs       credentials=...,rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,sec=ntlm,uid=tomcat7,gid=tomcat7,dir_mode=0770,file_mode=0770 0 0

O problema é que ele fica desmontando após um determinado período de tempo - não uma falha do Windows, eu posso acessar o compartilhamento em outro lugar

$ sudo ls /media/docs
finance  postsale  repository

#after e.g. 10 minutes...
$ sudo ls /media/docs
[sudo] password for user:
ls: cannot access '/media/docs': Connection reset by peer

#this takes ages to complete
$ sudo umount /media/docs

#this fails immediately after, succedes after about 5/10 seconds
$ sudo mount /media/docs
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
$ sudo mount /media/docs
mount error(104): Connection reset by peer
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
$ sudo mount /media/docs
$ sudo ls /media/docs
finance  postsale  repository

Como depuro isso ou evito a queda?

Os usuários do aplicativo Tomcat não têm direito a remontar, toda vez que precisarem fazer um ticket para a TI.

Por favor, note que esta montagem no mesmo compartilhamento não cai (apenas a diferença que vejo é user é um sudoer, enquanto tomcat7 acima não é):

//dc/share       /media/share     cifs       credentials=....credentials,rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,sec=ntlm,uid=user,gid=user,dir_mode=0770,file_mode=0770 0 0

ATUALIZAÇÃO:

A pasta /var/log/samba está vazia - como defino o registro para o samba?

Se eu continuar listando a pasta, ela não será descartada:

while true; do date; ls /media/docs; sleep 5; done

UPDATE 2:

Aqui, a mount output:

//fs-mxp/ZZZshare on /media/share type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=XXX,domain=YYY-it,uid=1000,forceuid,gid=1000,forcegid,addr=10.39.52.6,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)
//fs-mxp/ftp on /media/ftp type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=XXX,domain=YYY-it,uid=1000,forceuid,gid=1000,forcegid,addr=10.39.52.6,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)
//sql-mxp/C$ on /media/sql type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=administrator,domain=YYY-it,uid=1000,forceuid,gid=1000,forcegid,addr=10.39.52.11,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)
//fs-mxp/ZZZdocs on /media/docs type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=YYYdoc,domain=YYY-it,uid=113,forceuid,gid=123,forcegid,addr=10.39.52.6,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)
//fs-mxp/ZZZshare/ASTE on /home/esales/aste type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=XXX,domain=YYY-it,uid=1001,forceuid,gid=1002,forcegid,addr=10.39.52.6,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)
//fs-mxp/ftp/YYYvendor on /home/esales/YYYvendor type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=XXX,domain=YYY-it,uid=1001,forceuid,gid=1002,forcegid,addr=10.39.52.6,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)
    
por neurino 23.05.2017 / 11:24

4 respostas

4

Eu acho que isso tem algo relacionado a patches entregues por atualizações do Windows para evitar ataques de ransomware. Ele faz com que o servidor que contém a pasta compartilhada rejeite as solicitações do CIFS V1. Por padrão, a montagem usa o CIFS V1. experimente, adicionando vers=2.0 ao final do seu comando de montagem. Eu tive o mesmo problema e desta forma eu consegui consertá-lo. PS / FYI: meu comando se parece com o seguinte

//192.168.1.10/public/mount /media/windowsshare cifs credentials=/home/MY_USERNAME/.smbcredentials,iocharset=utf8,sec=ntlm,vers=2.0 0 0

    
por 25.05.2017 / 05:46
4

Da sua saída de montagem adicionada à sua pergunta, podemos ver que você ainda está usando o CIFS 1.0.

Eu aconselharia a montagem da montagem como CIFS 2.1, se os servidores suportarem, como o CIFS v2.0 ou 2.1, o protocolo suporta uma melhor recuperação de sono / cortes de conexão. Para fazer isso, a opção é vers=2.1 .

Durable handles (2.02, 2.1) – allow for connection to transparently reconnect to the server if there is a temporary disconnection

Eu também aconselho a adicionar a opção echo_interval=60 em vez de adicionar um loop while, pois dessa forma, o código do cliente SMB envia a si mesmo um beacon keepalive a cada minuto para o servidor.

Cuidado, que como eu avisei e corrigi na resposta @Thillina, as opções estão todas no 3º campo separadas por uma vírgula.

Para mais detalhes, consulte CIFS perdendo aleatoriamente a conexão com o compartilhamento do Windows

Lendo os artigos que estou citando no meu post:

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

Então, ter o Windows server 2012 significa que pelo menos o lado do Windows suporta CIFSv3.0 e inferior.

Para verificar se foi renegociado e com qual versão, altere as opções no seu arquivo fstab e faça:

#mount -o remount /media/docs

e, em seguida, execute um comando mount para verificar com qual versão a montagem foi feita / negociada.

    
por 05.06.2017 / 14:22
0

Acabei com uma tarefa do cron que a cada 3 minutos toca um arquivo em cada cifs de compartilhamento em mount para manter a conexão ativa.

Até agora, as ações estão de volta à disponibilidade normal:

cifs_keepalive:

#!/bin/bash

while read spot; do
   touch --no-create "${spot}/.cifs_keepalive"
done <<< "$(mount | awk '/cifs/{ print $3; }')"

/etc/cron.d/cifs_keepalive:

*/3 *   *   *   *   root    /home/bcait/bca_util/bin/cifs_keepalive >/dev/null 2>&1

Créditos: Eu tive a idéia de esta postagem no blog .

    
por 26.05.2017 / 14:34
0

No meu caso, eu tinha outras interfaces de rede que estavam desconectadas. As expirações de concessão DHCP nessas interfaces causaram a queda das montagens De acordo com o link , o Samba é recarregado.

Para mim, desativei essas interfaces. Outra solução possível pode ser autofs com 0 timeout.

    
por 24.08.2017 / 15:11