SMB aus der Hölle

SMB aus der Hölle

SMB am Mac ist einfach Mist. Jedenfalls vom Mac-Client zum Mac-Server mit OS X 10.11 oder macOS 10.12 out of the box. Die meisten Probleme können durch AFP als Netzwerkprotokoll behoben werden.

Viele Anwender und Admins bauen darauf, dass AFP seit OS X 10.9 Mavericks nicht mehr weiterentwickelt wird und Apple stattdessen SMB als neues Standard Netzwerkprotokoll einsetzt. Seit Mavericks Finder baut der Finder über die Seitenleiste beim Kontakt mit Bonjour-Computern SMB-Verbindungen auf … wenn man den Verbindungstyp nicht am Client explizit vorgibt oder SMB am OS X-Server gleich abstellt. Mit den Netzwerkverbindungen über SMB fangen eine Menge Probleme an: SMB ist deutlich langsamer als AFP, zeigt Probleme beim Speichern mit vielen Programmen und zeigt spontane Netzwerk-Freezes: extreme Verlangsamung des Netzwerks und Spinnging Ball of Death im Finder.

Viele Programme hadern noch mit SMB. Geradezu berühmt sind die Probleme von Microsoft Office 2011 oder Adobe CS4 und CS5 beim Speichern von Dokumenten. Über SMB-Verbindungen können diese Programme die Datei nur einmal speichern – danach knirscht es aufgrund fehlender ACL-Berechtigungen oder nicht perfekt passender SMB-Varianten. Die Folge sind blumige Fehlermeldungen à la „Kein Speicherplatz“, „fehlende Berechtigung“ und „unerwartetes Ende der Datei (EOF)“. Durch Umstellung der Netzwerkverbindung auf AFP können 99% dieser Probleme umgangen werden. OK – die erwähnten Programme sind relativ alt und nicht an SMB angepasst. So könnte man schon argumentieren. Aber …

Netzwerk-Verlangsamung

Besonders fies sind die Freezes von Netzwerkverbindungen über SMB. Es hat aber nichts mit Programmen zu tun und zeigt sich schon im Finder. Spontan auftretende, unerklärliche Verlangsamung des ganzen Netzwerks, Semmel des Todes im Finder, extrem verlangsamtes Anzeigen von Netzwerkordnern und deren Unterordnern im Finder, grausam langsames Öffnen und Speichern von Dokumenten übers Netzwerk. Und natürlich: nicht reproduzierbar.

Nun könnte man sich vertiefen in die Varianten von SMB, ältere Protokollversionen erzwingen oder client- und serverseitig die Verschlüsselung abstellen. Aber das ist Bastelei mit ungewissem Ausgang. Wer will schon ausgiebig testen, welche Programme in welcher Kombination mit welcher SMB-Variante am wenigsten Probleme haben? Halten wir mal kurz fest: Mit OS X 10.9 Mavericks hat Apple auf das Protokoll SMB 20 umgestellt, mit OS X 10.10 Yosemite auf SMB 3.0, was aber eigentlich SMBX ist, das Apple aufgrund von Patentstreitigkeiten selbst entwickelte.

Praktische Probleme

Zurück zur gelebten Praxis mit SMB-Verbindungen vom Mac Client zum Mac Server. Das typische SMB-Problem zeigte sich exemplarisch bei einem Kunden, dessen Admin am systematisch alle Fehlerquellen ausgeschlossen hatte, ohne das Problem der Netzwerkverlangsamung in den Griff zu bekommen. Wir wurden als externe Berater hinzugezogen und sahen dort:

  • Server: 10.11.6
  • Clients: 10.11.6 und 10.12.3

An den Macs wird mit Adobe CC gearbeitet, die Verbindung zu, Mac Server wird über die Seitenleiste des Finders hergestellt. Die SMB-Verbindung zum Server hat Phasen mit totaler Verlangsamung. Zufällig, nicht reproduzierbar: Öffnen und Speichern dauert sehr lange, das Navigieren in Ordner-Strukturen ist mit extremen Wartezeiten verbunden: dauernd Beachball.

Der Mac Server zeigt kaum Last, hat genügend RAM, verrät keine Probleme im Log.

Vergebliche Fehlersuche

Die in Frage kommenden Lösungsversuche wurden bereits systematisch durchgeführt. Unter Anderem: Adobe CC neu installiert – Clients geupdatet – Macs neu installiert – Switche getauscht – Ethernetkabel geprüft und getauscht – Ersatz-Server in Betrieb genommen (selbes System, grundlegend neu aufgebaut) – RAID neu aufgesetzt
… leider alles erfolglos. Im Endeffekt wurden alle Komponenten vollständig ausgetauscht, das Problem blieb. Die gelegentliche Verlangsamung trat immer noch auf. Sporadisch, spontan, nicht reproduzierbar. Am Server zeigte sich, dass alle Mac-Clients mit SMB zum Mac-Server verbunden waren. Interessant.

Erster Ansatz: AFP statt SMB

Unser erster Ansatz brachte schon den gewünschten Erfolg: AFP statt SMB. Nachdem die Verbindungen der Macs zum Mac Server sauber auf AFP umgestellt wurden, hörten die Probleme schlagartig auf und die Geschwindigkeit des internen Netzwerks erreichte wieder um 100 MB/s. Damit das auch so bleibt, wurden folgende einfache Änderungen vorgenommen:

  • Server-Volumes getrennt
  • Schlüsselbund bereinigt
  • Verbindung zum Server per AFP hergestellt (über Finder > Gehe zu > Mit Server verbinden > afp://server.local), Anmeldeinformationen im Schlüsselbund gespeichert
  • Finder-Einstellungen > Allgemein > Verbundene Server auf dem Schreibtisch anzeigen
  • Server-Volumes vom Schreibtisch per Drag + Drop als Anmeldeobjekt hinzugefügt in Systemeinstellungen > Benutzer
  • Server-Volumes zusätzlich in der Finder-Seitenleiste als Favorit hinzugefügt
  • zusätzlich in Dokumente einen Ordner angelegt, der alle Verknüpfungen zum Server als Alias enthält, diese dann auch als Favorit in die Seitenleiste eingebaut (damit die Mitarbeiter bei evtl. getrenntem Server die Verbindung wieder sauber aufbauen können)

Das Ergebnis: das Netzwerk läuft schneller als zuvor, die Ordner und Unterordner des Servers zeigen sich im Finder flotter an – und es gibt seitdem keine Netzwerk-Verlangsamung mehr. Nach weiteren Tests und Umstellung aller Macs auf AFP wurde am Mac Server schließlich bei allen Freigaben SMB als Protokoll deaktiviert.

Zweiter Ansatz

Unser zweiter Ansatz wäre gewesen, am Mac Client SMB 1.0 zu erzwingen oder das client signing abzuschalten. Das könnte eine angemessene Lösung für Umgebungen, in denen auf SMB nicht verzichtet werden kann, wie z.B. bei Clients, die mit Windows, Linux und OS X laufen.

Im oben beschriebenen Fall konnte durch einfachen Verzicht auf SMB die übliche Netzwerkgeschwindigkeit von 100 MB/s wieder hergestellt werden – anstelle der mit SMB gemessenen 50-65 MB/s. Und bisher dauerhaft ohne Netzwerkaussetzer.

 

 

 

5 Comments
  • André
    Posted at 11:16h, 25 Januar

    Vielen Dank für die ordentliche Analyse! Wir haben seit Jahren MacOSX Server im Einsatz, aktuell auf MacOSX 10.12.6 und Server 5.3.1 im Einsatz (aktuell nur noch virtualisiert aufgrund fehlender passender Hardware). Inbesondere setzen wir seit Jahren auch auf die sogenannten Server Netzwerk-Accounts. Im vergangen Jahr sind wir dann auch in die SMB versus AFP „Falle“ getappt. Bisher hatten wir nur AFP im Einsatz. Plötzlich konnten Netzwerk-Account-User ihre iOS Devices in iTunes nicht mehr backupen. Nach fast abgeschlossenem Backup-Vorgang, kam immer die Meldung, dass das Backup nicht gespeichert werden konnte. Bei der Überprüfung des Netzwerk-Accounts hat sich dann aber gezeigt, dass die Daten sehrwohl da waren, nur iTunes konnte aus einem unerfindlichen Grund den Backup-Vorgang nicht abschliessen. Die Fehlersuche mit zahlreichen Tests hat uns mehrere Tage gekostet, auch mit wenig hilfreichen Apple Support-Anfragen.
    Schliesslich haben wir für die User-Folder Freigabe von AFP auf SMB umgeschaltet und dann hatten wir keine Probleme mehr in dieser Hinsicht (musste allerdings für alle Netzwerk-User die OpenDirectory Pfad angaben von AFP zu SMB anpassen). Dann wollten wir auch für die Arbeitsvolumen von AFP auf SMB umschalten und hatte genau die oben beschrieben Probleme.

    Wir fahren nun deshalb zweigleisig; SMB für die User-Volumen Freigaben und AFP für die Arbeitsvolumen. VectorWorks 2016, 2017, 2018 arbeiten unter AFP stabil, auch die Adobe CC 2018 Applikationen.

    Hingegen haben wir Probleme mit PDF- und JPG-Dateien, wenn diese in einer grösseren Anzahl von einem lokalen MacOSX Client auf ein AFP Arbeitsvolumen übertragen werden. Obwohl die Permissions (ACL und Posix) korrekt sind, haben wir dann in zufälliger Weise keinen Zugriff mehr bzw. die Dateien scheinen „besetzt“ zu sein und dann bei einem Versuch die betroffenen Dateien lokal oder remote zu kopieren als beschädigt angegeben werden. Wir haben bisher keinen plausiblen Grund dafür gefunden. Einzig was uns am plausiblisten erscheint, ist das nach dem fertigen Rüberkopieren auf dem MacOSX Server ein Prozess mit grosser Last zur Erstellung der PDF- und JPG Vorschau läuft und das dieser nicht mehr so stabil läuft wie früher.

    Ja und schliesslich scheint uns MacOSX Server 5.3 und als Basis MacOSX 10.12 selbst mit AFP als Fileserver nicht mehr so performant als unter früheren MacOSX Versionen, selbst wenn wir SSD für den MacOSX Server im Einsatz haben. Mit konkreten Zahlen können wir das nicht belegen, aber es fühlt sich so an, inbesondere auch trotz schnellem Netzwerk. So sind wir dabei uns umzuschauen, ob eine NAS-Lösung für die Arbeitsvolumen eventuell mehr Performance bringen könnte.

  • Peter
    Posted at 20:41h, 04 Juli

    Danke für eueren Input. Wir haben das selbe Problem und ihr habt uns sehr geholfen!!!

  • Cajus Pruin
    Posted at 09:06h, 03 April

    Moin ! Aus unserer Erfahrung kann ich dazu beisteuern, das zumindest im Einsatz von VectorWorks – egal, welche Version – das Erzwingen von SMB1 keine Verbesserung gebracht hat. Dies haben wir für 1 Woche alternativ zu dem von Ihnen beschriebenen Szenario „Zwangs-AFP“ getestet.

    Derzeit erscheint AFP als gesetztes Protokoll die einzig sinnvolle Möglichkeit, Mac-Clients mit einem Mac-Server zu verbinden.

    Wir werden jetzt kurzfristig testen, den OSX-Server als virtuelle Maschine aufzusetzen, da es ja keine professionelle Hardware mehr von Apple gibt, die man als Server verwenden könnte.

    • Thomas Kemmer
      Posted at 09:02h, 04 April

      Moin. Im direkten Kontakt mit Vectorworks Support wurde ich auch schon dazu gedrängt, SMB statt AFP zu verwenden, weil AFP angeblich veraltet sei und mit dem brandneuen „Safe Save“ von Vectorworks nicht zurechtkäme. In der Praxis macht SMB zwar die Vectorworks-Version 2016 beim Speichern stabiler, aber dafür werde Word/Excel/PowerPoint und Adobe Creative Suite mit SMB unbenutzbar.
      Pikant sind dabei drei Aspekte:
      1) die Fehlermeldungen beim Speichern mit Vectorworks 2016 auf einem AFP-Server sind kunterbunt und vielfältig: „Unerwartetes Ende der Datei“, „Nicht genügend Speicherplatz“, „Keine Berechtigung“, „Fehlende Netzwerkverbindung“, etc. – aber kein klarer Hinweis auf das Problem. Mit SMB wird das tatsächlich stabiler … aber man erkauft sich das durch nicht mehr benutzbares MS Office und Adobe CS – denn diese Programme haben nun Probleme mit dem Speichern. Betroffenen Benutzern können wir aktuell nur anbieten: entweder problemloses Speichern für Vectorworks (via SMB) oder für MS Office + Adobe CS (via AFP).
      2) Mit stabilem Vectorworks 2016 via SMB treten die oben erwähnten Netzwerk-Freezes auf. Abhilfe: SMB ausschalten, nur noch AFP, was effektiv deutlich schneller läuft.
      3) wenn man bei Vectorworks genau nachfragt, wird dann doch wieder AFP als einzig sinnvolles Protokoll empfohlen. So war es auch bis vor einigen Wochen im Vectorworks-Forum nachzulesen. Aktuell ist im Forum dazu aber keine offizielle Aussage mehr zu finden.

  • Thomas
    Posted at 08:43h, 03 April

    Danke für diesen Tipp!!!
    Ich verzweifle seit Ewigkeiten an genau diesem Problem