J'ai eu quelques répertoires montés à distance depuis une Debian Jessie, dans un partage Windows, pendant quelques mois.
Au cours des dernières semaines, je n'arrêtais pas de me plaindre de déconnexions aléatoires du point de montage et j'ai dû faire un
sudo mount -a
pour retrouver la connectivité de la monture, plusieurs fois (le serveur est utilisé une ou deux fois par semaine).
par exemple. les montures ne récupèrent pas souvent après une certaine période sans être utilisées.
L'administrateur Windows m'a également dit que le serveur Windows n'avait pas été redémarré depuis un certain temps.
Aujourd'hui, par coïncidence lors de l'exécution de mount -a encore une fois, cela n'a fonctionné qu'au 2e essai, alors que le premier essai a donné l'erreur suivante :
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)
Les répertoires sont montés depuis /etc/fstab en tant que tel :
//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
Lorsque vous effectuez une commande de montage, vous pouvez également voir l'option echo_interval est activé par défaut à 60 minutes.
$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)
Que faire ?
Réponse acceptée :
J'ai trouvé un article connexe intéressant ici Le dossier monté cifs continue de se déconnecter (serveur Ubuntu), parlant d'un problème similaire (même erreur, partages Samba).
La friandise pertinente ici, pour suivre le reste de la réponse, est que les montages CIFS utilisent le protocole SMBv1.0 par défaut, comme cela peut être vérifié en émettant le mount commande, et en faisant attention à la vers=1.0 champ.
$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)
J'ai également trouvé dans Stack Overflow, l'hôte post-montage CIFS est en panne
Cela pourrait également être dû à une incompatibilité de protocole. En 2017, Microsoft
a corrigé les serveurs Windows et conseillé de désactiver le protocole SMB1.À partir de maintenant, mount.cifs pourrait avoir des problèmes avec la négociation de protocole.
L'erreur affichée est "L'hôte est en panne". mais quand vous déboguez avec :
smbclient -L <server_ip> -U <username> -d 256vous obtiendrez l'erreur :
protocol negotiation failed: NT_STATUS_CONNECTION_RESET
Le message mentionne que les correctifs Windows pour le protocole/Wannacry et d'autres, gâchent/ou plus exactement, certaines personnes ont désactivé la fonctionnalité de requêtes CIFS v1 ; des problèmes similaires se sont produits sur le front de Windows et, compte tenu du moment, cela me fait penser que le problème doit être lié.
Nous n'avons pas désactivé CIFS v1 sur ce serveur spécifique, AFAIK (et les tests le confirment), mais les bulletins MS suggèrent que le comportement SMBv1 par défaut a été (légèrement) modifié.
J'ai fini par suivre l'idée générale suggérée dans la question Samba mentionnée. De l'homme mounts.cifs :
vers=version du protocole SMB. Les valeurs autorisées sont :
1.0 – Le protocole classique CIFS/SMBv1. C'est la valeur par défaut.
2.0 – Le protocole SMBv2.002. Cela a été initialement introduit dans Windows Vista Service Pack 1 et Windows Server 2008. Notez que
la version initiale de Windows Vista parlait un dialecte légèrement différent (2.000) qui n'est pas pris en charge.2.1 - Le protocole SMBv2.1 qui a été introduit dans Microsoft Windows 7 et Windows Server 2008R2.
3.0 - Le protocole SMBv3.0 qui a été introduit dans Microsoft Windows 8 et Windows Server 2012.
Notez également que même si cette option régit la version du protocole utilisée, toutes les fonctionnalités de chaque version ne sont pas disponibles.
--verboseAffiche des informations de débogage supplémentaires pour le montage. Notez que ce paramètre doit être spécifié avant le
-o. Par exemple :mount -t cifs //server/share /mnt --verbose -o user=usernameComme le montre le manuel, dans les versions récentes de Windows après Windows 8
en utilisant au moinsvers=2.0peut avoir plus de sens; la syntaxe alternative dans la
ligne de commande avec le--verbosel'option mentionnée est également
utile pour déboguer davantage toute complication pouvant survenir.
En tant que tel, comme le serveur Windows sur lequel je monte des éléments sur cette question est un serveur Windows 2008 R2, j'ai mis /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
Ensuite, remontez-le pour que l'option prenne effet :
sudo mount -o remount /mnt/mount_point
Maintenant, nous vérifions, avec mount encore une fois, pour confirmer le protocole négocié :
$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)
Et nous pouvons en effet confirmer que nous avons modifié avec succès le protocole SMB utilisé.
Il convient également de noter que CIFS v1.0, en plus d'être obsolète, est extrêmement inefficace et peu sûr, par rapport aux versions plus récentes du protocole.
Depuis les blogs MS – Arrêtez d'utiliser SMB1
SMB1 n'est ni moderne ni efficace
Lorsque vous utilisez SMB1, vous perdez
les principales optimisations de performances et de productivité pour les utilisateurs finaux.
- Lectures et écritures plus importantes (2.02+) :utilisation plus efficace de réseaux plus rapides
ou de WAN à latence plus élevée. Prise en charge de grands MTU.- Mise en cache homologue des propriétés de dossier et
de fichier (2.02+) :les clients conservent des copies locales des dossiers et
fichiers via BranchCache- Des poignées durables (2.02, 2.1) – permettent à
la connexion de se reconnecter de manière transparente au serveur en cas de
déconnexion temporaire- Modèle de leasing oplock client (2.02+) :limite
les données transférées entre le client et le serveur, améliorant
les performances sur les réseaux à latence élevée et augmentant l'évolutivité du serveur SMB- Multicanal et SMB Direct (3.0+) :agrégation de la bande passante du réseau
et tolérance aux pannes si plusieurs chemins sont disponibles entre
le client et le serveur, ainsi que l'utilisation de l'ultra-haute modernité dans l'ensemble du RDMA
infrastructures- Directory Leasing (3.0+) – Améliore les temps de réponse
des applications dans les succursales grâce à la mise en cache
Chose intéressante, ce dernier article suggère que les problèmes de déconnexion sont moins susceptibles d'apparaître après une déconnexion (poignées durables) si vous utilisez un protocole>=2.01, donc je voudrais insister à nouveau pour ne pas continuer à utiliser CIFS v1.0. (par exemple, en 1.0, echo_interval=60 le maintient connecté, s'il y a un problème de réseau ou une autre interruption du serveur, le montage ne se récupèrera pas sans intervention manuelle, lors de l'utilisation de CIFS v1.0)
Comme dernier conseil, évitez de faire sudo mount -a , et commencez à faire :
sudo mount -o remount -a
Voir ma question aussi CIFS monter plusieurs copies du même partage sur le même point de montage