Ich habe seit ein paar Monaten ein paar Verzeichnisse von einem Debian Jessie entfernt in einer Windows-Freigabe gemountet.
In den letzten Wochen hatte ich immer wieder Beschwerden über zufällige Verbindungsabbrüche vom Einhängepunkt und musste eine
sudo mount -a
um die Mount-Konnektivität wiederherzustellen, ein paar Mal (der Server wird ein- oder zweimal pro Woche verwendet).
z.B. Die Reittiere erholen sich nicht oft nach einer gewissen Zeit ohne Verwendung.
Der Windows-Administrator hat mir auch mitgeteilt, dass der Windows-Server seit einiger Zeit nicht mehr neu gestartet wurde.
Heute zufällig beim Ausführen von mount -a Auch hier funktionierte es nur im 2. Versuch, während der erste Versuch den folgenden Fehler ergab:
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)
Die Verzeichnisse werden aus /etc/fstab gemountet als solches:
//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
Wenn Sie einen Mount-Befehl ausführen, können Sie auch die Option echo_interval sehen ist standardmäßig bei 60 Minuten aktiviert.
$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)
Was tun?
Akzeptierte Antwort:
Ich habe hier einen interessanten verwandten Beitrag gefunden, in dem cifs eingehängter Ordner die Verbindung ständig trennt (Ubuntu-Server), und von einem ähnlichen Problem spricht (gleicher Fehler, Samba-Freigaben).
Der relevante Leckerbissen hier, um dem Rest der Antwort zu folgen, ist, dass CIFS-Mounts standardmäßig das SMBv1.0-Protokoll verwenden, wie durch die Ausgabe des mount verifiziert werden kann Befehl und achten Sie auf vers=1.0 Feld.
$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)
Ich habe auch in Stack Overflow festgestellt, dass der CIFS-Host nach dem Mounten ausgefallen ist
Dies könnte auch an einer Protokollunstimmigkeit liegen. Im Jahr 2017 hat Microsoft
Windows-Server gepatcht und empfohlen, das SMB1-Protokoll zu deaktivieren.
Von nun an könnte mount.cifs Probleme mit der Protokollaushandlung haben.
Der angezeigte Fehler lautet „Host ist ausgefallen“. aber wenn Sie debuggen mit:
smbclient -L <server_ip> -U <username> -d 256
Sie erhalten den Fehler:
protocol negotiation failed: NT_STATUS_CONNECTION_RESET
Der Beitrag erwähnt, dass Windows-Patches für das Protokoll/Wannacry und andere mit/oder genauer gesagt, einige Leute haben die v1-CIFS-Anforderungsfunktionalität deaktiviert; Ähnliche Probleme sind an der Windows-Front aufgetreten, und angesichts des zeitlichen Ablaufs vermute ich, dass das Problem damit zusammenhängt.
Wir haben v1 CIFS auf diesem speziellen Server nicht deaktiviert, AFAIK (und Tests bestätigen dies), aber die MS-Bulletins deuten darauf hin, dass das standardmäßige SMBv1-Verhalten (leicht) geändert wurde.
Am Ende folgte ich der allgemeinen Idee, die in der erwähnten Samba-Frage vorgeschlagen wurde. Von man mounts.cifs :
vers=
- SMB-Protokollversion. Zulässige Werte sind:
-
1.0 – Das klassische CIFS/SMBv1-Protokoll. Dies ist die Standardeinstellung.
-
2.0 – Das SMBv2.002-Protokoll. Dies wurde ursprünglich in Windows Vista Service Pack 1 und Windows Server 2008 eingeführt. Beachten Sie, dass
die ursprüngliche Release-Version von Windows Vista einen etwas anderen Dialekt (2.000) sprach, der nicht unterstützt wird. -
2.1 – Das SMBv2.1-Protokoll, das in Microsoft Windows 7 und Windows Server 2008R2 eingeführt wurde.
-
3.0 – Das SMBv3.0-Protokoll, das in Microsoft Windows 8 und Windows Server 2012 eingeführt wurde.
Beachten Sie auch, dass diese Option zwar die verwendete Protokollversion regelt, jedoch nicht alle Funktionen jeder Version verfügbar sind.
--verbose
- Gibt zusätzliche Debugging-Informationen für den Mount aus. Beachten Sie, dass dieser Parameter vor dem
-o angegeben werden muss . Zum Beispiel: mount -t cifs //server/share /mnt --verbose -o user=username
Wie aus dem Handbuch hervorgeht, in neueren Windows-Versionen nach Windows 8
mit mindestens vers=2.0 kann sinnvoller sein; die alternative Syntax in der
Kommandozeile mit dem --verbose Die erwähnte Option ist auch
nützlich, um eventuell auftretende Komplikationen weiter zu debuggen.
Da es sich bei dem Windows-Server, von dem ich bei dieser Frage mounte, um einen Windows-Server 2008 R2 handelt, füge ich /etc/fstab ein :
//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
Hängen Sie es dann erneut ein, damit die Option wirksam wird:
sudo mount -o remount /mnt/mount_point
Jetzt verifizieren wir mit mount erneut, um das ausgehandelte Protokoll zu bestätigen:
$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)
Und wir können tatsächlich bestätigen, dass wir das verwendete SMB-Protokoll erfolgreich modifiziert haben.
Es sollte auch beachtet werden, dass CIFS v1.0 im Vergleich zu neueren Versionen des Protokolls nicht nur veraltet, sondern auch äußerst ineffizient und unsicher ist.
Von MS-Blogs – Hören Sie auf, SMB1 zu verwenden
SMB1 ist weder modern noch effizient
Wenn Sie SMB1 verwenden, verlieren Sie wichtige
Leistungs- und Produktivitätsoptimierungen für Endbenutzer.
- Größere Lese- und Schreibvorgänge (2.02+) – effizientere Nutzung schnellerer Netzwerke
oder WANs mit höherer Latenz. Große MTU-Unterstützung. - Peer-Caching von Ordner- und
Dateieigenschaften (2.02+) – Clients speichern lokale Kopien von Ordnern und
Dateien über BranchCache - Dauerhafte Handles (2.02, 2.1) – ermöglichen
der Verbindung, sich transparent wieder mit dem Server zu verbinden, falls es zu einer
vorübergehenden Trennung
kommt - Client-Oplock-Leasingmodell (2.02+) – begrenzt
die zwischen Client und Server übertragenen Daten, verbessert
die Leistung in Netzwerken mit hoher Latenz und erhöht die SMB-Server
Skalierbarkeit - Multichannel &SMB Direct (3.0+) – Aggregation von Netzwerkbandbreite
und Fehlertoleranz, wenn mehrere Pfade zwischen
Client und Server verfügbar sind, plus Nutzung von modernem Ultra-High-Through-RDMA
Infrastruktur - Directory Leasing (3.0+) – Verbessert die Antwortzeiten von Anwendungen
in Zweigstellen durch Caching
Interessanterweise weist dieser letzte Artikel darauf hin, dass die Verbindungsprobleme nach einer Verbindungsunterbrechung (Durable Handles) mit geringerer Wahrscheinlichkeit auftreten, wenn ein Protokoll>=2.01 verwendet wird, daher möchte ich noch einmal betonen, CIFS v1.0 nicht weiter zu verwenden. (z. B. während in 1.0 echo_interval=60 hält die Verbindung aufrecht, wenn ein Netzwerkfehler oder eine andere Serverunterbrechung auftritt, wird sich der Mount nicht ohne manuellen Eingriff wiederherstellen, während CIFS v1.0 verwendet wird)
Als letzten Ratschlag vermeiden Sie sudo mount -a , und beginnen Sie mit:
sudo mount -o remount -a
Siehe meine Frage auch CIFS-Mounting mehrerer Kopien derselben Freigabe auf demselben Mount-Punkt