Es ist ein lästiges und bis dato andauerndes Problem mit der SMB-Implementierung in Apple’s Mac-Betriebssystem seit 10.9 Mavericks (Link). Von schlechter Performance, überhaupt keinem Zugriff und unvollständiger Anzeige ist alles dabei.

Die Abhilfe statt SMB2 wieder SMB1 zu verwendet stellt dabei i.d.R. nur einen eher ungenügenden Lösungsweg dar. Das liegt daran, das es dort ebenfalls “nicht mehr so wie früher” ist.

Persönliches Vorwort

Wir setzen neben Windows, Linux und ein wenig BSD ebenfalls Macs ein, so das wir von diesem Problem direkt betroffen sind. Das so kein Arbeiten oder im privaten Bereich Zugreifen auf Medien-Dateien wie z.B. Musik oder Filme keinen wirklichen Spass macht, dürfte klar sein.

Vor einer Weile habe ich mich dieser Sache erneut angenommen. Die (letzte) Hoffnung das es mit OS X 10.10 Yosemite möglicherweise endlich besser wird zuschlug sich nach dem ersten Upgrade eines Macs und anschließendem Test.

Eine andere Lösung muss her!

Was macht man nun?! Unsere Dateiserver, geschäftlich wie privat, sind alles Windows-Maschinen, also mal eben ein weiteres Protokoll hinzuzufügen ist da nicht drin. Mal schnell Server umstellen ebenfalls nicht.

Um zu testen, ob die Problematik nur mit echten Windows auftritt, wurde ein Test mit der NAS-Distribution OpenMediaVault durchgeführt. Mit dem dortigen Samba-Server traten alle bekannten Unzulänglichkeiten ebenfalls auf. Also dann mal mit NFS und AFP getestet.

Und siehe da, mit AFP rennt die Datenübertragung, selbst das Ansehen eines Films, der auf dem NAS gespeichert wurde und via WLAN abgerufen wird läuft störungsfrei. Damit war der grundsätzliche Weg klar. Irgendwie muss SMB/CIFS und AFP miteinander verheiratet werden.

Der erste Gedanke war, neue Dateiserver statt mit Windows mit Linux aufzusetzen, Samba und Netatalk einzurichten und damit den Datenbestand freigeben. Aber da ist man wieder bei der Thematik, das man eben mal nicht schnell Dateiserver austauschen kann. Mal abgesehen davon, das teils noch Drittanbieter-Anwendungen laufen, die zwingend Windows als Datei-/Aplikationsserver voraussetzen.

AFP für Windows?

Der zweite Gedanke war eher eine Frage, ob es eine AFP-Implementierung für Windows gibt. Nach ein wenig Recherche wurden folgende Möglichkeiten gefunden:

Acronis ExtremeZ-IP

Cyan Soft MacServerIP

Helios Universal File Server UB64

Getestet haben wir keine dieser Lösungen, mal ganz abgesehen davon, das allesamt für kleine Umgebungen schlicht zu kostspielig sind. Je nach Anforderung und/oder Budget sollte man sie dennoch im Hinterkopf behalten!

Zurück zum Titel: Via AFP auf CIFS zugreifen

Ein anderer Gedanke der mir kam, war ein Linux-System als eine Art Gateway zu verwenden. Die Idee ist relativ nahe liegend, da Dateisysteme ganz gleich ob lokal oder remote immer auf ein Verzeichnis eingehängt werden.

Hinweis: Vorab sei zu dieser Idee erwähnt, das es bislang nur ein Teilerfolg ist! Lesend funktioniert es, nur schreiben funktioniert nicht. Falls jemand eine Idee oder Lösung hat, bitte melden! Noch während ich diese Zeilen schrieb, kam die Lösung.

Anbei im Groben mein Vorgehen soweit:

• Debian 7 Wheezy ohne GUI, aber mit SSH-Daemon installiert.
• Als root angemeldet und feste IP-Adresse konfiguriert.
• Nachfolgend die Befehle und Änderungen im Schnelldurchlauf:

mkdir /media/media
apt-get install cifs-utils
nano /etc/fstab
Folgende Zeile hinzufügen (und anpassen):
//192.168.2.2/media /media/media cifs vers=2.0,user=afp,passwd=geheim,uid=1000,gid=1000 0 0

mount -a
apt-get install netatalk
nano /etc/netatalk/afpd.conf
Die Zeile "# - -tcp -noddp -uamlist uams_dhx.so,uams_dhx2.so -nosavepassword" einkommentieren.

nano /etc/netatalk/AppleVolumes.default
Folgende Zeile hinzufügen:
/media/media "media"

/etc/init.d/netatalk restart

Von den Macs aus kann man nun über Linux transparent auf die Windows-Freigabe zugreifen. Lesend läuft das wie bereits schon, nur Schreiben (Dateien, Ordner) klappt nicht, es erscheint ein Anmeldedialog. Ganz gleich welche Daten man einträgt, es wird nichts erstellt bzw. man gelangt wieder zum Dialog.

Unter Linux selbst funktioniert der schreibende Zugriff auf Windows. Zum Test wurde ein lokales Verzeichnis angelegt und via Netatalk freigegeben, dort klappte das Schreiben ebenfalls.

Als Schnellschuss wurde kurzerhand Vollzugriff (0755, Vollzugriff-Jeder) eingestellt, aber auch dies änderte nichts.

Abschließende Worte

Kurios ist die Sache schon, da Apple sowohl AFP als auch NFS in Mac OS X nicht mehr pflegen möchte. SMB ist damit sozusagen die einzige weiterhin supportede Lösung, die wiederum nicht richtig läuft. Das ist soweit keine gute Mischung, mal sehen was die Zukunft bringt.

Der hier vorgestellte workaround ist nur ein Schnellschuss. Ein differenziertes Handling mit verschiedenen Benutzern und deren Rechten ist so nicht möglich. Am Rande sei erwähnt, dass das “Fileserver-Gateway” unter Hyper-V (Windows Server 2012 R2) mit einer vCPU und 512 MB RAM läuft. Die virtuelle Festplatte ist nur 10 GB groß, es geht sogar noch weniger, da gerade mal 10% verwendet werden. Auch CPU-mässig ist nichts los (zumindest im Augenblick, während eine Aufzeichnung von Tron in SD-Qualität [Aufgenommen bei zdf_neo via DFB-S] läuft).

Etwas unschön ist der Umstand, das Netatalk 2 Verzeichnisse die mit “.Apple…” in der Windows-Freigabe bzw. jeden (Unter-)Ordner anlegt. Soweit ich gelesen habe, scheint das bei Netatalk 3 nicht mehr der Fall zu sein. Leider stehen dafür noch keine fertigen Pakete zur Verfügung, so das man die neuere Version selbst kompilieren muss.

Verbesserungsvorschläge sind natürlich willkommen!

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.