Eu tive alguns diretórios montados remotamente a partir de um Debian Jessie, em um compartilhamento do Windows, por alguns meses.
Nas últimas semanas, tenho recebido 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, as montagens não se recuperam frequentemente após algum período sem serem usadas.
O administrador do Windows também me disse que o servidor Windows não foi reinicializado há algum tempo.
Hoje, coincidentemente ao fazer mount -anovamente, só funcionou na 2ª tentativa, enquanto na 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 da /etc/fstabseguinte forma:
//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 executar um comando de montagem, você também pode ver que a opção echo_intervalé ativada por padrão em 60 segundos.
$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?
Responder1
Encontrei um post relacionado interessante aquipasta montada cifs continua desconectando (servidor Ubuntu), falando de um problema semelhante (mesmo erro, o Samba compartilha).
O detalhe relevante aqui, para acompanhar o restante da resposta, é que as montagens CIFS usam o protocolo SMBv1.0 por padrão, como pode ser verificado emitindo o mountcomando e prestando atenção ao vers=1.0campo.
$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, o postO host CIFS de montagem está inativo
Isso também pode ocorrer devido à incompatibilidade de protocolo. Em 2017, a Microsoft corrigiu os servidores Windows e aconselhou a desabilitar o protocolo SMB1.
De agora em diante, mount.cifs poderá ter problemas com a negociação de protocolo.
O erro exibido é "Host inativo". mas quando você depura com:
smbclient -L <server_ip> -U <username> -d 256você receberá o erro:
protocol negotiation failed: NT_STATUS_CONNECTION_RESET
A postagem menciona que os patches do Windows para o protocolo/Wannacry e outros estão atrapalhando/ou, mais exatamente, algumas pessoas desabilitaram a funcionalidade de solicitações CIFS v1; problemas semelhantes têm acontecido no Windows e, dado o momento, me faz suspeitar que o problema esteja relacionado.
Não desabilitamos o CIFS v1 neste servidor específico, AFAIK (e os testes confirmam 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 citada pergunta do Samba. Dehomemmounts.cifs:
vers=Versão do protocolo SMB. Os valores permitidos são:
1.0 - O protocolo CIFS/SMBv1 clássico. Este é o padrão.
2.0 - O protocolo SMBv2.002. Isso foi introduzido inicialmente no Windows Vista Service Pack 1 e no Windows Server 2008. Observe que a versão inicial do Windows Vista falava um dialeto ligeiramente diferente (2.000) que não é compatível.
2.1 - O protocolo SMBv2.1 introduzido no Microsoft Windows 7 e no Windows Server 2008R2.
3.0 – O protocolo SMBv3.0 introduzido no Microsoft Windows 8 e no Windows Server 2012.
Observe também que embora esta opção regule a versão do protocolo utilizada, nem todos os recursos de cada versão estão disponíveis.
--verboseImprima informações adicionais de depuração para a montagem. Observe que esse parâmetro deve ser especificado antes do
-o. Por exemplo:mount -t cifs //server/share /mnt --verbose -o user=usernameConforme visto no manual, nas versões recentes do Windows após o Windows 8, usar pelo menos
vers=2.0pode fazer mais sentido; a sintaxe alternativa na linha de comando com a--verboseopção mencionada também é útil para depurar ainda mais qualquer complicação que possa surgir.
Assim, como o servidor Windows do qual estou montando as coisas nesta questão é um servidor Windows 2008 R2, coloquei /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, remontei-o para que a opção tenha efeito:
sudo mount -o remount /mnt/mount_point
Agora verificamos, novamente mount, 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 de fato confirmar que modificamos com sucesso o protocolo SMB usado.
Deve-se notar também que o CIFS v1.0, além de obsoleto, é extremamente ineficiente e inseguro, comparado às versões mais recentes do protocolo.
DeBlogs MS - Pare de usar SMB1
SMB1 não é moderno ou eficiente
Ao usar o SMB1, você perde otimizações importantes de desempenho e produtividade para os usuários finais.
- Leituras e gravações maiores (2.02+) – uso mais eficiente de redes mais rápidas ou WANs de maior latência. Grande suporte a MTU.
- Cache peer de propriedades de pastas e arquivos (2.02+) – os clientes mantêm cópias locais de pastas e arquivos via BranchCache
- Alças duráveis (2.02, 2.1) – permitem que a conexão se reconecte de forma transparente ao servidor se houver uma desconexão temporária
- Modelo de leasing de oplock de cliente (2.02+) – limita os dados transferidos entre o cliente e o servidor, melhorando o desempenho em redes de alta latência e aumentando a escalabilidade do servidor SMB
- Multicanal e SMB Direct (3.0+) – agregação de largura de banda de rede e tolerância a falhas se vários caminhos estiverem disponíveis entre cliente e servidor, além de uso de tecnologia ultra-alta moderna em toda a infraestrutura RDMA
- Directory Leasing (3.0+) – Melhora os tempos de resposta de aplicativos em filiais por meio de cache
Curiosamente, este último artigo sugere que os problemas de desconexão são menos prováveis de aparecer após uma desconexão (alças 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 estiver na versão 1.0, echo_interval=60ele o mantém conectado, se houver uma falha na rede ou alguma outra interrupção no servidor, a montagem não se recuperará sem intervenção manual, ao usar o CIFS v1.0)
Como último conselho, evite fazer sudo mount -ae comece a fazer:
sudo mount -o remount -a
Veja minha pergunta tambémCIFS montando múltiplas cópias do mesmo compartilhamento no mesmo ponto de montagem