He tenido un par de directorios montados de forma remota desde Debian Jessie, en un recurso compartido de Windows, durante unos meses.
En las últimas semanas, sigo recibiendo quejas de desconexiones aleatorias del punto de montaje y tuve que hacer un
sudo mount -a
para recuperar la conectividad de la montura, un par de veces (el servidor se usa una o dos veces por semana).
p.ej. las monturas no se recuperan a menudo después de un período sin usarse.
El administrador de Windows también me dijo que el servidor de Windows no se ha reiniciado durante un tiempo.
Hoy, casualmente al hacer mount -a nuevamente, solo funcionó en el segundo intento, mientras que el primer intento dio el siguiente error:
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)
Los directorios se montan desde /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
Al realizar un comando de montaje, también puede ver la opción echo_interval se activa por defecto a los 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)
¿Qué hacer?
Respuesta aceptada:
Encontré una publicación relacionada interesante aquí La carpeta montada cifs sigue desconectándose (servidor ubuntu), hablando de un problema similar (mismo error, recursos compartidos de Samba).
El dato relevante aquí, para seguir el resto de la respuesta, es que los montajes CIFS usan el protocolo SMBv1.0 de forma predeterminada, como se puede verificar emitiendo el mount y prestando atención a vers=1.0 campo.
$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)
También encontré en Stack Overflow, la publicación Mount CIFS Host está inactiva
Esto también podría deberse a una falta de coincidencia del protocolo. En 2017, Microsoft
parcheó los servidores de Windows y recomendó desactivar el protocolo SMB1.
De ahora en adelante, mount.cifs podría tener problemas con la negociación del protocolo.
El error que se muestra es "El host está inactivo". pero cuando depuras con:
smbclient -L <server_ip> -U <username> -d 256
obtendrá el error:
protocol negotiation failed: NT_STATUS_CONNECTION_RESET
La publicación menciona que los parches de Windows para el protocolo/Wannacry y otros, están estropeando/o más exactamente, algunas personas deshabilitaron la funcionalidad de solicitudes de CIFS v1; han estado ocurriendo problemas similares en el frente de Windows y, dado el momento, me hace sospechar que el problema debe estar relacionado.
No hemos deshabilitado v1 CIFS en este servidor específico, AFAIK (y las pruebas lo confirman), sin embargo, los boletines de MS sugieren que el comportamiento predeterminado de SMBv1 se modificó (ligeramente).
Terminé siguiendo la idea general sugerida en la pregunta de Samba mencionada. Del hombre mounts.cifs :
vers=
- Versión del protocolo SMB. Los valores permitidos son:
-
1.0:el clásico protocolo CIFS/SMBv1. Este es el valor predeterminado.
-
2.0:el protocolo SMBv2.002. Esto se introdujo inicialmente en Windows Vista Service Pack 1 y Windows Server 2008. Tenga en cuenta que
la versión de lanzamiento inicial de Windows Vista hablaba un dialecto ligeramente diferente (2.000) que no es compatible. -
2.1:el protocolo SMBv2.1 que se introdujo en Microsoft Windows 7 y Windows Server 2008R2.
-
3.0:el protocolo SMBv3.0 que se introdujo en Microsoft Windows 8 y Windows Server 2012.
Tenga en cuenta también que si bien esta opción rige la versión del protocolo utilizada, no todas las funciones de cada versión están disponibles.
--verbose
- Imprime información de depuración adicional para el montaje. Tenga en cuenta que este parámetro debe especificarse antes de
-o . Por ejemplo: mount -t cifs //server/share /mnt --verbose -o user=username
Como se ve en el manual, en versiones recientes de Windows posteriores a Windows 8
usando al menos vers=2.0 puede tener más sentido; la sintaxis alternativa en la línea de comando
con --verbose La opción que se menciona también es
útil para depurar aún más cualquier complicación que pueda surgir.
Como tal, como el servidor de Windows del que estoy montando cosas en esta pregunta es un servidor de Windows 2008 R2, puse /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
Luego lo volví a montar para que la opción surtiera efecto:
sudo mount -o remount /mnt/mount_point
Ahora verificamos, con mount de nuevo, para confirmar el 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)
Y, de hecho, podemos confirmar que modificamos con éxito el protocolo SMB que se está utilizando.
También se debe tener en cuenta que CIFS v1.0, además de ser obsoleto, es extremadamente ineficiente e inseguro, en comparación con las versiones más nuevas del protocolo.
Desde blogs de MS:deja de usar SMB1
SMB1 no es moderno ni eficiente
Cuando utiliza SMB1, pierde las optimizaciones clave
de rendimiento y productividad para los usuarios finales.
- Lecturas y escrituras más grandes (2.02+):uso más eficiente de redes más rápidas
o WAN de mayor latencia. Gran soporte de MTU. - Almacenamiento en caché del mismo nivel de propiedades de carpetas y
archivos (2.02+):los clientes conservan copias locales de carpetas y
archivos a través de BranchCache - Controles duraderos (2.02, 2.1):permiten que
la conexión se vuelva a conectar de forma transparente al servidor si hay una
desconexión temporal - Client oplock leasing model (2.02+):limita
los datos transferidos entre el cliente y el servidor, mejorando
el rendimiento en redes de alta latencia y aumentando la escalabilidad del servidor SMB - Multicanal y SMB Direct (3.0+):agregación del ancho de banda de la red
y tolerancia a fallas si hay varias rutas disponibles entre
el cliente y el servidor, además del uso de ultra alta tecnología moderna en RDMA
infraestructura - Arrendamiento de directorios (3.0+):mejora los tiempos de respuesta de las aplicaciones
en las sucursales a través del almacenamiento en caché
Curiosamente, este último artículo sugiere que es menos probable que los problemas de desconexiones aparezcan después de una desconexión (controles duraderos) si se usa un protocolo>=2.01, por lo que insisto nuevamente en no continuar usando CIFS v1.0. (por ejemplo, mientras está en 1.0, echo_interval=60 lo mantiene conectado, si hay una falla en la red o alguna otra interrupción del servidor, el montaje no se recuperará sin intervención manual, mientras se usa CIFS v1.0)
Como último consejo, evita hacer sudo mount -a y empieza a hacer:
sudo mount -o remount -a
Vea mi pregunta también CIFS montando varias copias del mismo recurso compartido en el mismo punto de montaje