CIFS verliert zufällig die Verbindung zur Windows-Freigabe


7

Ich habe einige Monate lang einige Verzeichnisse von einer Debian Jessie in einer Windows-Freigabe remote gemountet.

In den letzten Wochen hatte ich immer wieder Beschwerden über zufällige Verbindungsabbrüche vom Mountpoint und musste eine durchführen

sudo mount -a

Um die Mount-Konnektivität ein paar Mal wiederherzustellen (der Server wird ein- oder zweimal pro Woche verwendet).

zB erholen sich die Halterungen nach einiger Zeit nicht oft, ohne benutzt zu werden.

Der Windows-Administrator teilte mir außerdem mit, dass der Windows-Server eine Weile nicht neu gestartet wurde.

Heute mount -afunktionierte es zufällig nur beim zweiten 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 /etc/fstabals solche bereitgestellt:

//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 sehen, dass die Option echo_intervalstandardmäßig nach 60 Minuten aktiviert ist.

$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 ist zu tun?

Antworten:


13

Ich habe hier einen interessanten verwandten Beitrag gefunden. Der von cifs gemountete Ordner wird immer wieder getrennt (Ubuntu-Server) und spricht von einem ähnlichen Problem (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 überprüft werden kann, indem der mountBefehl ausgegeben wird und das vers=1.0Feld beachtet wird.

$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 Post- Mount-CIFS-Host nicht verfügbar ist

Dies könnte auch an einer Nichtübereinstimmung des Protokolls liegen. 2017 hat Microsoft Windows Server gepatcht und empfohlen, das SMB1-Protokoll zu deaktivieren.

Von nun an kann 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

In dem Beitrag wird erwähnt, dass Windows-Patches für das Protokoll / Wannacry und andere die Funktionalität von v1 CIFS-Anforderungen deaktivieren. Ähnliche Probleme sind an der Windows-Front aufgetreten, und angesichts des Zeitpunkts habe ich den Verdacht, dass das Problem damit zusammenhängen muss.

Wir haben v1 CIFS auf diesem bestimmten Server nicht deaktiviert, AFAIK (und Tests bestätigen dies). Die MS-Bulletins legen jedoch nahe, dass das Standardverhalten von SMBv1 (geringfügig) geändert wurde.

Am Ende folgte ich der allgemeinen Idee, die in der erwähnten Samba-Frage vorgeschlagen wurde. Vom Menschenmounts.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 Erstversion 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

    Drucken Sie zusätzliche Debugging-Informationen für den Mount. Beachten Sie, dass dieser Parameter vor dem angegeben werden muss -o. Zum Beispiel:

 mount -t cifs //server/share /mnt --verbose -o user=username

Wie aus dem Handbuch hervorgeht, ist die Verwendung von Windows in neueren Windows-Versionen nach Windows 8 vers=2.0möglicherweise sinnvoller. Die alternative Syntax in der Befehlszeile mit der genannten --verboseOption ist auch nützlich, um eventuell auftretende Komplikationen weiter zu debuggen.

Da es sich bei dem Windows-Server, von dem aus ich in dieser Frage Informationen bereitstelle, um einen Windows-Server 2008 R2 handelt, habe ich Folgendes eingegeben /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

Dann wurde es erneut montiert, damit die Option wirksam wird:

sudo mount -o remount /mnt/mount_point

Jetzt überprüfen wir mounterneut, 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 geändert haben.

Siehe auch MS Developer Network - [MS-SMB2]: Versionierung und Fähigkeitsverhandlung - 1.7 Versionierung und Fähigkeitsverhandlung

Es sollte auch beachtet werden, dass CIFS v1.0 nicht nur veraltet ist, sondern im Vergleich zu neueren Versionen des Protokolls äußerst ineffizient und unsicher ist.

Aus MS-Blogs - Verwenden Sie SMB1 nicht mehr

SMB1 ist nicht modern oder 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
  • Langlebige Handles (2.02, 2.1) - Ermöglichen eine transparente Wiederverbindung der Verbindung zum Server, wenn eine vorübergehende Trennung vorliegt
  • Client-Oplock-Leasing-Modell (2.02+) - Begrenzt die zwischen Client und Server übertragenen Daten, verbessert die Leistung in Netzwerken mit hoher Latenz und erhöht die Skalierbarkeit von SMB-Servern
  • Multichannel & SMB Direct (3.0+) - Aggregation von Netzwerkbandbreite und Fehlertoleranz, wenn mehrere Pfade zwischen Client und Server verfügbar sind, sowie Nutzung moderner Ultrahoch-Werte in der gesamten RDMA-Infrastruktur
  • Directory Leasing (3.0+) - Verbessert die Antwortzeiten von Anwendungen in Zweigstellen durch Caching

Interessanterweise schlägt dieser letzte Artikel vor, dass die Probleme mit der Trennung nach einer Trennung weniger wahrscheinlich auftreten (dauerhafte Handles), wenn ein Protokoll> = 2.01 verwendet wird. Daher möchte ich noch einmal betonen, dass CIFS v1.0 nicht weiter verwendet wird. ( echo_interval=60Wenn z. B. in 1.0 die Verbindung hergestellt bleibt, wenn ein Netzwerkfehler oder eine andere Serverunterbrechung auftritt, kann sich der Mount bei Verwendung von CIFS v1.0 ohne manuelles Eingreifen nicht selbst wiederherstellen.)

Vermeiden Sie als letzten Ratschlag Folgendes sudo mount -aund beginnen Sie:

sudo mount -o remount -a

Siehe meine Frage auch CIFS, das mehrere Kopien derselben Freigabe auf demselben Bereitstellungspunkt bereitstellt

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.