CIFS perdendo aleatoriamente a conexão com o compartilhamento do Windows

Question

Eu tive alguns diretórios montados remotamente de um Debian Jessie, em um compartilhamento do Windows, por alguns meses.

Nas últimas semanas, continuo tendo reclamações de desconexões aleatórias do ponto de montagem e tive que fazer uma

sudo mount -a

para recuperar a conectividade de montagem, algumas vezes (o servidor é usado uma ou duas vezes por semana).

por exemplo. os montes não estão se recuperando frequentemente após algum período sem serem usados.

O administrador do Windows também me disse que o servidor Windows não foi reinicializado por um tempo.

Hoje, coincidentemente, ao fazer mount -a novamente, ele só funcionou na segunda tentativa, enquanto a primeira tentativa deu o seguinte erro:

sudo mount -a
mount error(104): Connection reset by peer
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Os diretórios são montados a partir de /etc/fstab como tal:

//10.2.1.2/XX/ZZ/YY /mnt/mount_point cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0770,dir_mode=0770,uid=1001,gid=1001 0 0

Ao fazer um comando de montagem, você também pode ver a opção echo_interval é ativada por padrão em 60 minutos.

$mount //10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=1.0,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

O que fazer?

    

Answer 1

Encontrei um interessante post relacionado aqui pasta montada em cifs desconexão (servidor ubuntu) , falando de um problema similar (mesmo erro, compartilhamentos do Samba).

O conteúdo relevante aqui, para acompanhar o restante da resposta, é que as montagens CIFS usam o protocolo SMBv1.0 por padrão, conforme pode ser verificado emitindo o comando mount e prestando atenção ao campo vers=1.0 .

$mount //10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=1.0,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

Também encontrei no Stack Overflow, a postagem que o host do CIFS de montagem está desativado

This could be also because of protocol mismatch. In 2017 Microsoft patched Windows Servers and advised to disable the SMB1 protocol.

From now on, mount.cifs might have problems with protocol negotiation.

The error displayed is "Host is down." but when you do debug with:

smbclient -L <server_ip> -U <username> -d 256

you will get the error:

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

A postagem menciona que os patches do Windows para o protocolo / Wannacry e outros estão bagunçando / ou, mais exatamente, algumas pessoas desativaram a funcionalidade de solicitações v1 CIFS; problemas similares têm acontecido na frente do Windows e, dado o momento, isso me faz suspeitar que o problema deve estar relacionado.

Não desativamos o v1 CIFS neste servidor específico, AFAIK (e o teste confirma isso), no entanto, os boletins do MS sugerem que o comportamento padrão do SMBv1 foi (ligeiramente) alterado.

Acabei seguindo a ideia geral sugerida na mencionada questão do Samba. De homem mounts.cifs :

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.

Note too that while this option governs the protocol version used, not all features of each version are available.

--verbose

Print additional debugging information for the mount. Note that this parameter must be specified before the -o. For example:

 mount -t cifs //server/share /mnt --verbose -o user=username

As seen by the manual, in recent Windows versions after Windows 8 using at least vers=2.0 may make more sense; the alternative syntax in the command line with the --verbose option that is mentioned is also be useful to further debug any complication that may arise.

Como tal, como o servidor Windows que eu estou montando coisas sobre esta questão é um servidor Windows 2008 R2, eu coloquei em /etc/fstab :

//10.2.1.2/XX/ZZ/YY /mnt/mount_point cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0770,dir_mode=0770,uid=1001,gid=1001,vers=2.1 0 0

Em seguida, montou novamente para que a opção tivesse efeito:

sudo mount -o remount /mnt/mount_point

Agora, verificamos com mount novamente para confirmar o protocolo negociado:

$mount //10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=2.1,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

E podemos confirmar que modificamos com sucesso o protocolo SMB que está sendo usado.

Veja também MS Developer Network - [MS-SMB2]: Negociação de versão e capacidade - 1.7 Controle de versão e negociação de capacidade

Também deve ser notado que o CIFS v1.0, além de ser obsoleto, é extremamente ineficiente e inseguro, comparado às versões mais novas do protocolo.

De MS blogs - Pare de usar o SMB1

SMB1 isn’t modern or efficient
When you use SMB1, you lose key performance and productivity optimizations for end users.

• Larger reads and writes (2.02+) – more efficient use of faster networks or higher latency WANs. Large MTU support.
• Peer caching of folder and file properties (2.02+) – clients keep local copies of folders and files via BranchCache
• Durable handles (2.02, 2.1) – allow for connection to transparently reconnect to the server if there is a temporary disconnection
• Client oplock leasing model (2.02+) – limits the data transferred between the client and server, improving performance on high-latency networks and increasing SMB server scalability
• Multichannel & SMB Direct (3.0+) – aggregation of network bandwidth and fault tolerance if multiple paths are available between client and server, plus usage of modern ultra-high throughout RDMA infrastructure
• Directory Leasing (3.0+) – Improves application response times in branch offices through caching

Curiosamente, este último artigo sugere que os problemas de desconexão são menos prováveis de aparecer após uma desconexão (identificadores duráveis) se estiver usando um protocolo > = 2.01, então eu enfatizaria novamente, para não continuar usando o CIFS v1.0. (por exemplo, enquanto em 1.0, echo_interval=60 mantém conectado, se houver uma falha na rede ou alguma outra interrupção do servidor, a montagem não se recuperará sem intervenção manual, enquanto estiver usando o CIFS v1.0, eu suspeito)

Como último conselho, evite fazer sudo mount -a e comece a fazer:

sudo mount -o remount -a

Veja minha pergunta também CIFS montando várias cópias do mesmo compartilhamento no mesmo ponto de montagem