CIFS verliert zufällig die Verbindung zur Windows-Freigabe

Question

Ich habe seit einigen Monaten einige Verzeichnisse remote von einem Debian Jessie in einer Windows-Freigabe gemountet.

In den letzten Wochen habe ich immer wieder Beschwerden über zufällige Verbindungsabbrüche vom Mountpoint erhalten und musste

sudo mount -a

um die Mount-Konnektivität einige Male wiederherzustellen (der Server wird ein- oder zweimal pro Woche verwendet).

Beispielsweise erholen sich die Halterungen nach einer gewissen Zeit der Nichtbenutzung oft nicht mehr.

Der Windows-Administrator teilte mir außerdem mit, dass der Windows-Server seit einiger Zeit nicht neu gestartet wurde.

Heute mount -ahabe ich es zufälligerweise beim erneuten Versuch erst beim 2. Versuch geklappt, während der 1. Versuch 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/fstabwie folgt gemountet:

//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 Sekunden 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 zu tun?

Answer 1

Ich habe hier einen interessanten Beitrag zum Thema gefundenDie Verbindung zum gemounteten CIFS-Ordner wird ständig getrennt (Ubuntu-Server), spricht von einem ähnlichen Problem (derselbe Fehler, Samba-Freigaben).

Der relevante Hinweis hier, um dem Rest der Antwort folgen zu können, ist, dass CIFS-Mounts standardmäßig das SMBv1.0-Protokoll verwenden, was durch Eingeben des mountBefehls und Beachten des vers=1.0Felds überprüft werden kann.

$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 den Beitrag gefundenMount CIFS-Host ist ausgefallen

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

Von nun an könnte mount.cifs Probleme mit der Protokollverhandlung haben.

Der angezeigte Fehler ist „Host ist ausgefallen“, aber beim Debuggen mit:

smbclient -L <server_ip> -U <username> -d 256

Sie erhalten den folgenden Fehler:

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

Der Beitrag erwähnt, dass Windows-Patches für das Protokoll/Wannacry und andere die Funktionalität der CIFS-Anforderungen v1 durcheinanderbringen oder, genauer gesagt, einige Leute diese deaktiviert haben. Unter Windows sind ähnliche Probleme aufgetreten und angesichts des Zeitpunkts vermute ich, dass das Problem damit zusammenhängen muss.

Soweit ich weiß, haben wir CIFS v1 auf diesem speziellen Server nicht deaktiviert (und Tests bestätigen dies), die MS-Bulletins deuten jedoch darauf hin, dass das Standardverhalten von SMBv1 (leicht) geändert wurde.

Ich bin letztendlich der allgemeinen Idee gefolgt, die in der erwähnten Samba-Frage vorgeschlagen wurde. VonMannmounts.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 erstmals in Windows Vista Service Pack 1 und Windows Server 2008 eingeführt. Beachten Sie, dass die erste Version von Windows Vista einen leicht 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 bestimmt, aber nicht alle Funktionen jeder Version verfügbar sind.

--verbose

Drucken Sie zusätzliche Debuginformationen für die Einbindung. Beachten Sie, dass dieser Parameter vor dem angegeben werden muss -o. Beispiel:

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

Wie aus dem Handbuch hervorgeht, ist in neueren Windows-Versionen nach Windows 8 die Verwendung von „at least“ vers=2.0möglicherweise sinnvoller; die alternative Syntax in der Befehlszeile mit der --verbosegenannten Option kann ebenfalls hilfreich sein, um eventuell auftretende Komplikationen weiter zu debuggen.

Da es sich bei dem Windows-Server, von dem ich für diese Frage Sachen mounte, um einen Windows Server 2008 R2 handelt, gebe ich Folgendes ein /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 mounten Sie es erneut, damit die Option wirksam wird:

sudo mount -o remount /mnt/mount_point

Nun ü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 auchMS 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, sondern im Vergleich zu neueren Versionen des Protokolls auch äußerst ineffizient und unsicher ist.

AusMS-Blogs – Beenden Sie die Verwendung von SMB1

SMB1 ist weder modern noch effizient
Wenn Sie SMB1 verwenden, gehen wichtige Leistungs- und Produktivitätsoptimierungen für Endbenutzer verloren.

• 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 behalten lokale Kopien von Ordnern und Dateien über BranchCache
• Dauerhafte Handles (2.02, 2.1) – ermöglichen eine transparente Wiederherstellung der Verbindung zum Server, wenn eine vorübergehende Unterbrechung vorliegt
• 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 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 Ultra-High-RDMA-Infrastruktur
• Directory Leasing (3.0+) – Verbessert die Anwendungsreaktionszeiten in Zweigstellen durch Caching

Interessanterweise legt dieser letzte Artikel nahe, dass Verbindungsprobleme nach einer Trennung weniger wahrscheinlich auftreten (Durable Handles), wenn ein Protokoll >= 2.01 verwendet wird. Ich möchte daher noch einmal betonen, dass Sie CIFS v1.0 nicht weiter verwenden sollten. (Wenn Sie beispielsweise bei 1.0 die echo_interval=60Verbindung aufrechterhalten, kann sich die Bereitstellung bei einer Netzwerkstörung oder einer anderen Serverunterbrechung ohne manuelles Eingreifen nicht wiederherstellen, wenn Sie CIFS v1.0 verwenden.)

Als letzter Ratschlag: Vermeiden Sie Folgendes sudo mount -aund beginnen Sie damit:

sudo mount -o remount -a

Siehe auch meine FrageCIFS-Mounten mehrerer Kopien derselben Freigabe am gleichen Mount-Punkt