macOS und SMB

Dass die Welt immer komplexer wird, stellt man oft zu Zeitpunkten und an Orten fest, an denen man es nicht erleben möchte. Zum Beispiel, wenn man einen Mac mini Server gegen ein neueres Modell ersetzt.

Der alte Mac mini lief mit System X.8.5 – schon deshalb schien ein Tausch angeraten. Da das Gerät als Fileserver dient, musste die Ausfallzeit so gering wie möglich gehalten werden. Also kauft man einen neuen Mac mini und bereitet alles dafür vor, dass bis auf eine kurze Unterbrechung für die Anwender keine Unannehmlichkeiten entstehen.

Soweit der Plan.

Nachdem wir in den vorangegangenen Monaten sämtliche Clients im Netz auf macOS „El Capitan“ umgestellt hatten, war meine kindliche Hoffnung, dass ein frisch ins Netz geklemmter Mac mini, der ebenfalls „El Capitan“ nutzt, reibungslos mit den gleich versionierten Anwendern reden sollte.

Wie furchtbar man sich täuschen kann.

Innerhalb weniger Stunden begannen die Klagen; die Netzwerkperformance sei völlig eingebrochen. Anwender sähen Ordner auf dem Server nicht. Dateien würden verschwinden. Der Zugriff auf Dateien wäre gesperrt. Lauter Dinge, die man im Produktivbetrieb haben möchte wie Zahnschmerzen, Stromausfall und ähnliches.

Ich will nicht damit langweilen, was ich alles gelesen habe, um zu verstehen, was da passiert. Eine wichtige Information, die erstmal die meisten Probleme augenscheinlich (aber nicht wirklich) löst, ist: Am Server das SMB-Protokoll abschalten und die Anwender wieder per AFP zugreifen lassen. Damit können Windows-User zwar nicht mehr zugreifen; davon haben wir aber nicht viele.

SMB? AFP?

Apple hat jahrzehntelang sein eigenes Netzwerkprotokoll für die Kommunikation zwischen Rechnern und Servern eingesetzt. Die älteren unter uns werden sich daran erinnern, dass man zwei Macs per ADB-Kabel verbinden und vernetzen konnte. Das ist im Prinzip AFP.

Wie man sich vorstellen kann, sind eine Reihe von technischen Konzepten nicht mehr mit einem derartig alten Protokoll einzufangen. Daraufhin hat man bei Apple sicher sehr lange nachgedacht, was man tut und hat eine – eigentlich gar nicht so doofe – Entscheidung getroffen: man beschloss, künftig das von Microsoft entwickelte SMB in Version 2 zu nutzen.

Gleichzeitig beschloss man leider auch, dafür keine Lizenz von Microsoft zu beziehen – und wollte auch nicht auf das bereits etablierte SAMBA-Projekt zurückzugreifen. Nein, Apple begann, seine eigene Implementierung des SMB-Protokolls zu schreiben. Die Frucht all dieser Arbeit wurde ab System macOS X.9 Mavericks ausgerollt. SMB wurde „Standard“ – AFP wurde abgekündigt.

Wir erinnern uns: unser Server lief mit X.8 – er sprach also per Default mit seinen Clients AFP. Nun, da das Gerät getauscht und das System nunmehr X.11 war, flog uns die Welt um die Ohren. Warum das so unfassbar problematisch ist, habe ich – in Ermangelung tiefergehenden Wissens – bis heute nicht wirklich verstanden. Was ich dazu finde, ist:

  1. SAMBA taugt auch nix; die Entscheidung, selbst zu entwickeln sei nachvollziehbar
  2. Es gibt verschiedene Modelle der Vergabe und Überwachung von Zugriffsrechten auf einem Mac. Idealerweise weiß man das, kennt die Unterschiede, entscheidet sich bewusst für einen Weg und kann das sinnvoll administrieren. macOS stellt dafür offenbar keine Bordmittel bereit, die mit Gehirnen von Apple-Anwendern kompatibel sind. Was … hm … spannend ist.
  3. Der Fallback auf AFP ist keine tragfähige Option. Apple wird und muss dieses Protokoll künftig deaktivieren und eine modernere, besser abgesicherte Kommunikation durchsetzen. Und das wird SMB sein.

An welchem Punkt entsteht das Problem?

Das besonders Unangenehme ist aus Sicht des Apple-Kunden, dass die einfache Gleichung „Kauf’ an beiden Enden Apple und alles funktioniert“ hier nicht mehr gilt. Denn das hatten wir getan. An beiden Enden spricht offiziell unterstützte Apple-Hardware auf gleichem Systemlevel miteinander. Und trotzdem ist die Netzwerkperformance so schlecht, dass effektives Arbeiten ausgeschlossen ist.

Steigt man tiefer ein, erfährt man, dass Apple – wie man das korrekterweise wohl tut – die einzelnen Datenpakete signiert. Das ist ein Sicherheitsfeature, das man als Benutzer haben will. Wir erinnern uns an die Scheunentor-Sicherheitslücke von Windows-Freigaben, die die halbe Welt lahmlegte. Um solche Dinge geht es.

Nur führt dieses Feature in den meisten Fällen dazu, dass die Gesamtperformance auf etwa 30% des eigentlich möglichen Durchsatzes absackt. Das möchte man nicht erleben, insbesondere nicht, wenn man eigentlich frische Hardware zur Beschleunigung der Arbeitsumgebung einkauft …

Ein bisschen verschärft wird dieses grundsätzliche Problem dadurch, dass Apple offenbar Einstellungen für die SMB-Kommunikation am Client trifft, die für den Hausgebrauch von Tante Erna gut passen; aber nicht, wenn der Client mit vielen und tief gestaffelten Servern in einem Firmennetzwerk reden muss.

Was man tun kann

Schön ist, dass Apple nach vielen, vielen Jahren der Klagen in seinen Support-Foren endlich anerkannt hat, dass die Anwender hier unangenehme Probleme haben. Ende 2016 wurde ein offizieller Supportbeitrag veröffentlicht, der erklärt, wie man die Paketsignierung ausschaltet. Heureka!

Man darf dazu keine Angst vor der Benutzung des Terminal haben – und man muss über Administratorrechte am System verfügen. Um den Client zu heilen, genügen folgende Eingaben im Terminal:

sudo -s [RETURN]
echo "[default]" >> /etc/nsmb.conf [RETURN]
echo "signing_required=no" >> /etc/nsmb.conf [RETURN]

Danach verlässt man das Terminal mit dem Befehl „exit“ und schließt das Fenster.

Was diese Befehlsabfolge tut: Man weist sich als Administrator aus und gibt das Kennwort ein. Angezeigt wird es nicht. Eine Zeilenschaltung schließt diesen Vorgang ab. Die beiden Echo-Befehle legen eine neue Konfigurationsdatei für den Rechner an und schreiben zwei Zeilen hinein. Standardmäßig gibt es diese .conf nicht – man macht also nichts kaputt. Wer etwas mehr wissen möchte, sollte den oben zitierten Apple-Beitrag und ggfs. seinen mutmaßlichen Auslöser von Dan Rocadin lesen.

Wenn man sich mit seinem Rechner auf Serversystemen bewegt, die sehr komplexe Ordnerstrukturen besitzen, empfiehlt sich noch eine Anpassung von weiteren Werten in der nsmb.conf – wobei ich auf einen konkreten Beitrag in den Apple-Foren verweise:

https://discussions.apple.com/message/32051639#message32051639

Bei diesen Einträgen sollte das besondere Augenmerk der ersten „Nutzzeile“ gelten. Die Zahl 6 steht (wenn man sich durch dazugehörigen die MAN-Pages des Betriebssystems quält) für die Einschränkung der Netzwerkkommunikation via SMB am Client auf die SMB-Versionen 2 und 3. Die unsichere Version 1 wird hier also abgeklemmt – und das funktioniert auch.

Das merkt man spätestens, wenn man mit einer alten Gurke auf der Gegenseite kommunizieren muss, die nur SMB1 kann … dann muss hier eine 7 hinterlegt werden. Die MAN-Pages gibt es für verschiedene macOS-Versionen. Oben verlinkt ist die „Sierra“-Variante. Dort gibt es mehr Möglichkeiten. Und weil die Welt sich weiterdreht, wird bei uns gerade alles auf Sierra umgestellt. Wir sind zuversichtlich, dass wir mit diesen Eingriffen künftig weniger Probleme haben. Trotz Umstellung auf SMB und Sierra.

Die Haupterkenntnis aus diesen Erlebnissen ist, dass Apple sich offenkundig – auch nicht auf einer empathischen Anwenderebene – als Anbieter von professionell vernetzten Rechnersystemen versteht. Hilfestellung gibt es wenig bis keine. Man steht nackt am Strand. Im Winter.

Hat man ein Netzwerk zu administrieren, bei dem die Clients Macs sind und auch perspektivisch sein sollen, muss man sich mit dem SMB-Thema beschäftigen. Ohne manuelle Eingriffe ins Betriebssystem scheint ein stabiler und performanter Netzwerkbetrieb nicht mehr sicherzustellen zu sein. Das ist man als Mac-Anwender nicht gewohnt. Und es hinterlässt kein gutes Gefühl – weil man ständig am Ball bleiben muss, ob Apple wieder – undokumentiert – irgendwelche Details geändert hat. Möglicherweise hat man Zugriff auf bessere Informationen, wenn man zahlender Entwickler ist.

Schlussanekdote

Bei meinen umfangreichen vorbereitenden Tests kristallisierte sich heraus, dass die wenigsten Probleme bei der Kommunikation der Clients mit einem Fileserver unter Windows2016 mit Acronis Files Connect auftraten. Dann wird aber wieder AFP gesprochen …

Share

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.