☰

La carpeta montada cifs sigue desconectándose (servidor ubuntu)

tag-icon • tag-icon debian mount cifs
La carpeta montada cifs sigue desconectándose (servidor ubuntu)

Tengo esta entrada fstab para permitir que una aplicación Tomcat lea/escriba en una carpeta compartida de 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

El problema es que sigue desmontándose después de un cierto período de tiempo; no es una falla de Windows, puedo acceder al recurso compartido en otro 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

¿Cómo puedo depurar esto o evitar que se caiga?

Los usuarios de la aplicación Tomcat no tienen derecho a volver a montar, por lo que cada vez que necesitan presentar un ticket a TI.

Tenga en cuenta que este montaje en el mismo recurso compartido no cae (la única diferencia que veo es userun sudoer, mientras que tomcat7el anterior no lo es):

//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

ACTUALIZAR:

La carpeta /var/log/sambaestá vacía. ¿Cómo configuro el registro para samba?

Si sigo enumerando la carpeta, no desaparece:

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

ACTUALIZACIÓN 2:

Aquí el mountresultado:

//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)

Respuesta1

Supongo que esto tiene algo que ver con los parches entregados por las actualizaciones de Windows para evitar ataques de ransomware. Parece que el servidor que contiene la carpeta compartida rechaza las solicitudes CIFS V1. De forma predeterminada, el montaje utiliza CIFS V1. Pruébelo agregando vers=2.0al final de su comando de montaje. Tuve el mismo problema y de esta manera logré solucionarlo. PD/FYI: mi comando tiene el siguiente aspecto

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

Respuesta2

Desde el resultado de montaje agregado a su pregunta, podemos ver que todavía está usando CIFS 1.0.

Recomendaría montar el montaje como CIFS 2.1 si los servidores lo admiten, ya que desde CIFS v2.0 o 2.1 el protocolo admite una mejor recuperación en caso de suspensión/cortes de conexión. Para hacer eso la opción es vers=2.1.

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

También recomiendo agregar la opción echo_interval=60en lugar de agregar un bucle while, ya que de esa manera, el código del cliente SMB se envía una baliza de actividad cada minuto al servidor.

Tenga en cuenta que, como advertí y corregí en la respuesta de @Thillina, todas las opciones están en el tercer campo separadas por una coma.

Para obtener más detalles, consulteCIFS pierde aleatoriamente la conexión con el recurso compartido de Windows

Leyendo los artículos que cito en mi publicación:

3.0: el protocolo SMBv3.0 que se introdujo en Microsoft Windows 8 y Windows Server 2012.

Entonces, tener Windows Server 2012 significa que al menos el lado de Windows es compatible con CIFSv3.0 e inferior.

Para verificar si fue renegociado y con qué versión, cambie las opciones en su fstabarchivo y haga:

#mount -o remount /media/docs

y luego ejecute un mountcomando para verificar con qué versión se realizó/negoció el montaje.

Respuesta3

Terminé con un trabajo cron que cada 3 minutos toca un archivo en cada cifsrecurso compartido mountpara mantener viva la conexión.

Hasta ahora, las acciones han vuelto a estar disponibles con normalidad:

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: Saqué la idea deesta publicación de blog.

Respuesta4

En mi caso, tenía otras interfaces de red que estaban desconectadas. Los vencimientos de concesión de DHCP en esas interfaces provocaron la caída de los montajes. Segúnhttp://ubuntuforums.org/showthread.php?t=1140094Samba se recarga.

Para mí desactivé esas interfaces. Otra posible solución podría ser autofs con 0 tiempo de espera.

información relacionada