He tenido un par de directorios montados de forma remota desde Debian Jessie, en un recurso compartido de Windows, durante algunos meses.
En las últimas semanas, sigo teniendo quejas de desconexiones aleatorias del punto de montaje y tuve que hacer una
sudo mount -a
para recuperar la conectividad del soporte, un par de veces (el servidor se usa una o dos veces por semana).
por ejemplo, las monturas no se recuperan con frecuencia después de un período sin usarse.
El administrador de Windows también me dijo que el servidor de Windows no se había reiniciado por un tiempo.
Hoy, casualmente al mount -avolver a hacerlo, 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 /etc/fstabcomo tales:
//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 que la opción echo_intervalse activa de forma predeterminada a los 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)
¿Qué hacer?
Respuesta1
Encontré una publicación interesante relacionada aquí.La carpeta montada cifs sigue desconectándose (servidor ubuntu), hablando de un problema similar (mismo error, comparte Samba).
El dato relevante aquí, para seguir el resto de la respuesta, es que los montajes CIFS utilizan el protocolo SMBv1.0 de forma predeterminada, como se puede verificar emitiendo el mountcomando y prestando atención al 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)
También encontré en Stack Overflow, la publicaciónEl montaje del host CIFS no funciona
Esto también podría deberse a una discrepancia en el protocolo. En 2017, Microsoft parchó los servidores 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 no funciona". pero cuando depuras con:
smbclient -L <server_ip> -U <username> -d 256obtendrás 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 arruinando/o más exactamente, algunas personas deshabilitaron la funcionalidad de solicitudes 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 desactivado CIFS v1 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 cambió (ligeramente).
Terminé siguiendo la idea general sugerida en la pregunta de Samba mencionada. Dehombremounts.cifs:
vers=Versión del protocolo SMB. Los valores permitidos son:
1.0: el protocolo CIFS/SMBv1 clásico. 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 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.
--verboseImprima información de depuración adicional para el montaje. Tenga en cuenta que este parámetro debe especificarse antes del archivo
-o. Por ejemplo:mount -t cifs //server/share /mnt --verbose -o user=usernameComo se ve en el manual, en versiones recientes de Windows posteriores a Windows 8 usar al menos
vers=2.0puede tener más sentido; la sintaxis alternativa en la línea de comando con la--verboseopción que se menciona también será útil para depurar aún más cualquier complicación que pueda surgir.
Como tal, como el servidor de Windows desde el 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 volvimos a montar para que la opción surta efecto:
sudo mount -o remount /mnt/mount_point
Ahora verificamos, nuevamente mount, 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 utiliza.
También cabe señalar 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.
DeBlogs de MS: deje de usar SMB1
SMB1 no es moderno ni eficiente
Cuando utiliza SMB1, pierde 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. Soporte para MTU grandes.
- Almacenamiento en caché de pares de propiedades de carpetas y archivos (2.02+): los clientes mantienen copias locales de carpetas y archivos a través de BranchCache
- Mangos 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
- Modelo de arrendamiento de bloqueo de cliente (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 de ancho de banda de red y tolerancia a fallas si hay múltiples rutas disponibles entre el cliente y el servidor, además del uso de tecnología ultraalta moderna en toda la infraestructura RDMA.
- Directory Leasing (3.0+): mejora los tiempos de respuesta de las aplicaciones en las sucursales mediante el almacenamiento en caché
Curiosamente, este último artículo sugiere que es menos probable que aparezcan problemas de desconexión después de una desconexión (controles duraderos) si se usa un protocolo >= 2.01, por lo que insistiría nuevamente en no continuar usando CIFS v1.0. (por ejemplo, mientras está en 1.0, echo_interval=60lo mantiene conectado, si hay un problema de 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 -ay empieza a hacer:
sudo mount -o remount -a
Ver mi pregunta tambiénCIFS monta múltiples copias del mismo recurso compartido en el mismo punto de montaje