☰

mount.cifs se bloquea y deja de responder

tag-icon • tag-icon mount samba cifs
mount.cifs se bloquea y deja de responder

Estoy conectado a una VPN de CISCO para acceder a un servidor Windows remoto. Estoy usando mount.cifspara montar una carpeta compartida en este servidor.

Aquí está mi mountguión:

#!/bin/bash    
stweb="/mnt/stweb"
if ! mount|grep $stweb; then
    sudo mkdir -p $stweb
    sudo mount.cifs //<server IP>/folder $stweb -o uid=1000,gid=1000,user=<myuser>,password=<mypassword>,domain=<mydomain>
fi

Aquí está mi umountguión:

#!/bin/bash
sudo umount -a -t cifs -l

¡Trabajan!

Pero el problema es: a veces, por malas condiciones de la red, la conexión VPN se interrumpe; por lo tanto la acción deja de funcionar. Después de volver a conectarme, normalmente ejecuto mi umountscript y luego el mountscript. Pero a veces el mountscript se bloquea durante MUY GRANDE cantidad de tiempo al recibir el mount.cifscomando. Ni siquiera puedo enviar CTRL+C para finalizar el proceso. La operación de montaje vuelve a funcionar después de reiniciar el sistema.

Reiniciar en esta situación lleva mucho tiempo y es improductivo. ¿Alguna idea de lo que está pasando? ¿Qué registros puedo comprobar?

Por cierto, estoy en Wily, pero el problema ya estaba ahí cuando usaba Ubuntu 14.10.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 15.10
Release:    15.10
Codename:   wily

¡Gracias!

Respuesta1

Este problema existe desde hace al menos 10 años y todavía parece no haber forma de solucionarlo. Lo intenté umount -l xxx, que no se bloquea, pero luego se bloquea al intentar montar el recurso compartido. Un problema parece ser que es necesario volver a montar el recurso compartido antes de que cualquier proceso intente abrir un archivo en él. Esto puede resultar muy complicado si tiene enlaces suaves que apuntan al sistema de archivos compartido.

Aún más loco: si el sistema está atascado, smbmountsigue funcionando sin problemas, incluso si el mountmismo volumen permanece colgado durante más de 10 minutos.

Respuesta2

Esta publicación en los foros de UbuntuMe lo contestó.

Tuve que agregar vers=3.0una opción /etc/fstabpara ese punto de montaje.

Respuesta3

En una Mac que aloja los recursos compartidos, a veces es necesario reiniciar el intercambio de archivos en la Mac (es bastante simple reiniciar la Mac) antes de que los recursos compartidos se puedan montar nuevamente, el culpable seránoser el cliente Linux en tal escenario (aunque parecerá serlo a medida que los procesos clave entren en funcionamiento).suspensión del discoestado). Esto también es cierto si algo sale mal en la Mac mientras los recursos compartidos están montados y umountdeja de responder. En tal escenario, ninguno umount -lde los dos fuser -kmfuncionará, ambos se colgarán indefinidamente.

información relacionada