Habe gerade "Nach der Abkündigung des eigenen Protokolls »AFP« ist nun »SMB« das von Apple bevorzugte Netzwerk-Protokoll für den Austausch von Daten." auf gelesen.

War mir neu, dass Apple von AFP auf SMB umzieht...

Kam schon mal vor einiger Zeit, das Afp nicht mehr weiter gepflegt wird.

Nun, aktuell (auch unter Mavericks) gibt es einen automatischen afp Fallback sobald im Netzwerk Filesharing zu älteren OSX versionen betrieben wird, sowie bei der Verwendung von TimeMachine übers Netzwerk. Ansonsten wird seit Mavericks standardmäßig smb2 verwendet, sobald zwei Mavericks Rechner miteinander oder mit Windows Vista, 7 und 8 kommunizieren.

Für FileSharing mit älteren OS X Versionen sowie TimeMachine wird afp allerdings weiterhin unterstützt.

Von der sache her ist smb2 bei Dateifreigaben im heterogenen Netzwerk auch einfach die bessere, schnellere und sichere Variante.

AFP ist noch nicht abgekündigt, sondern wird weiterhin unterstützt, wenn auch nicht mehr mit Neuerungen. Das ist eine langsame Umstellung, und die wird viele Jahre bzw. OS X-Versionen dauern.

Ist Windows dabei ist es bequemer. Ansonsten wäre NFS die bessere, schnellere und sichere Variante.

Was ich so aufgeschnappt habe, soll die SMB2-Implementation in Mavericks aber noch fehlerhaft oder zumindest nicht ganz ausgereift sein.
Mein Bruder klagt bei seinem Mac ständig über irgendwelche Probleme mit seiner iTunes-Library und der Musik auf dem Synology NAS. Andauernd soll der Mac die Verbindung verlieren, so dass dann die Titel zwar angezeigt werden, beim Doppelklick auf einen Titel dann aber eine Fehlermeldung erscheint, dass er nicht gefunden werden konnte.

Allerdings soll es nach der Umstellung auf SMB immerhin zu einer etwas schnelleren Anzeige von prall gefüllten Ordnerinhalten auf dem NAS kommen.

PS: Habe mir erlaubt, den Titel zu korrigieren: APF @@ AFP

@Sonormann,
leider habe ich genau das bei meinem QNAP-NAS auch nach einer kurzen testweisen Umstellung auf das SMB-Protokoll festgestellt.. bin deswegen erst einmal zurück auf AFP...

Dem ist auch so, in Apples SMB2-Implementierung in 10.9 haperts aktuell rund um Permissions/Ownerships/ACLs (bzw. kriegt man quasi-zufällige Ergebnisse in Abhängigkeit davon, ob die Macs in einem Verzeichnisdienst hängen -- wurscht, ob AD oder OD -- oder nicht, wie der SMB-Server mit ACLs umgeht, wenn überhaupt und wie das bzgl. Kompatibilität zu Microsofts "Services for Unix" aussieht).

Das nächste Problem fällt in die Bereiche Encoding (also wie geht SMB-Server und -Client mit Zeichen, speziell Sonderzeichen und aus Windows-Sicht "bösen" Zeichen wie /|\:, etc. um), Speicherung von Extended Attributes, BSD Flags (bspw. "locked"/uchg) bzw. klassischem Finder-Kram wie Ressource Forks. Hier sollte man tunlichst drauf achten, zwischen AFP und SMB nur zu wechseln, wenn die Gegenstelle ein OS X (wurscht ob "Server" oder Normalversion) 10.8 oder 10.9 ist. Anderfalls Ärger vorprogrammiert.

Das nächste Problem ist, dass "SMB2 an sich" zwar ein paar Nettigkeiten von Haus aus mitbringt (bspw. die von AFP seit Ewigkeiten bekannte Reconnect-Geschichte, d.h. dass Verbindungen zwischen Client und Server, die kurz unterbrochen wurden, automagisch wieder aufgebaut werden, oder dass mehrere Requests, die bei AFP oder NFS beim Zugriff auf eine Datei entstehen würden, in einem SMB-Call zusammengefaßt werden können) dass das Ganze aber erst in dem Moment rund wird, in dem auch die von AFP bekannten Komfort-Features in Form von Apple-proprietären Anbauten ans SMB-Protokoll wie bspw. Spotlight-Suche per SMB (bzw. viel Wichtiger: Spotlight-Indizierung auf dem SMB-Server) serverseitig unterstützt werden. Welche SMB-Server außer dem in 10.9 eingebauten tun das zur Zeit? Genau: Weit und breit kein einziger (Samba und Helios werden aber wohl die ersten sein, die's abseits Apple bieten werden).

Und dann gibt es noch ein paar Sachen, die man beachten sollte. Aber um's kurz zu machen: Stand heute ohne jede Not auf SMB zu setzen, grad gegenüber Servern auf die man seit jeher problemlos per AFP zugreifen kann ist... doof (selbst wenn man damit bisserl schneller werkeln könnte). Punkt.

Die Stand jetzt einzige Kombination, halbwegs unfallfrei AFP durch SMB zwischen Macs (bzw. Mac-like-Servern wie irgendwelchen NAS-Eimern oder "echten Servern") auszutauschen, geht zwischen 10.8/10.9 (egal ob über SMB1 oder SMB2). Sonst nicht.

Muß man nicht glauben, kann man auch im Detail nachlesen: .

Nö. Und warum das so ist, kriegst Du ganz simpel selbst raus, wenn Du Dich im Detail mit all den Punkten rund um "vollwertige Übertragung von Mac-Dateien übers Netz von A nach B" bzw. den Problematiken aus meinem Beitrag eben auseinandersetzt

Thomas

Im speziellen Fall meines Bruders ist das Problem, dass es unter AFP leider auch nicht wirklich gut funktioniert hat. Bei Ordnern mit vielen Unterordnern und Dateien, wie es in einer gut sortierten Musiksammlung nun mal der Fall ist, dauert es mit AFP z.T. 30 Sekunden bis eine Minute, bis endlich die Unterordner angezeigt werden. Und auch da hat er schon das Problem erlebt, dass die Titel-Verknüpfungen wegen irgend einer nicht vorhandenen Verbindung zum NAS plötzlich futsch waren.

Zum Teil sind das sicher auch Probleme von iTunes selbst, oder auch von NAS in Verbindung mit OS X. Ich bin leider kein Netzwerk-Experte, um das Problem wirklich einkreisen zu können. Mein Bruder noch weniger. Und er als erst vor zwei Jahren vom PC zum Mac geswitchter User ist davon (verständlicherweise) tierisch angepisst, weil das mit iTunes unter Windows immer einwandfrei (mit dem selben NAS) funktioniert hat.

Interessant. Ich hab mit dem Umstieg auf Mavericks erst einmal einen enormen Geschwindigkeitsschub bei der Verbindung zu meinem Synology NAS feststellen können. Irgendwie ist das aber wieder ziemlich eingeschlafen. Auf dem NAS ist sowohl AFP als auch SMB aktiv. Was wird nun verwendet? SMB besser wieder abschalten?

Synology, richtig? Tja...

Das wird mir vermutlich als Bashing ausgelegt aber die Sache ist eigentlich ganz simpel: All die NAS-Hersteller da draußen (bis auf LaCie mal bei ein paar ihrer Modelle und IIRC auch Seagate?) setzen bzgl. Mac-Kompatibilität auf Netatalk: http://netatalk.sourceforge.net. Und um das richtig zu machen, muß man ein paar Sachen beachten, denn ein AFP-Server ist immer eine Mischung aus Dateiserver und... Datenbank (für die sog. CNIDs)

Netatalk ist ein OpenSource-AFP-Server, der mal zwischendrin ziemlich im Eimer war (weil fast nur irgendwelche Admins quer über den Planeten sich da das reingehackt hatten an Code, was sie grad zur Bändigung ihrer User brauchten). Als OS X aufkam, gab's zudem das Problem, dass Apple die neuen AFP-Spezifikationen sehr spät allgemein veröffentlichte, weshalb OS X und Netatalk nicht wirklich gut miteinander konnten. Ein paar Leute haben sich damals gedacht: Das können wir auch besser und so haben wir uns dann dran gemacht, einen spezifikationskonformen Neuansatz in Form von Netatalk 2.0 zu entwickeln. Ich hab damals zwar so gut wie keinen Code beigesteuert aber Doku geschrieben, Support gemacht, Tests gefahren, den produktiven Entwicklern den Rücken freigehalten gegenüber den unproduktiven "Spinnern" und vor allem... endlose Diskussionen drüber geführt, es doch bitte "richtig zu machen".

Vor knapp 10 Jahren haben wir dann Netatalk 2.0 rausgebracht, und irgendwie alle zeitgleich (war witzigerweise fast ausschließlich eine europäische Nummer) das Interesse verloren. Dann war Netatalk kraft aktiver Entwickler wieder am Abnippeln und irgendwann war's soweit, dass fast nur noch die Jungs von NetAFP die aktive Netatalk-Entwicklung getragen haben.

Und das ganze Projekt daran zu scheitern drohte, dass Firmen davon profitierten (was sie natürlich dürfen -- OpenSource) ohne in irgendeiner Form dazu beizutragen. NetAFP bot Supportverträge an, um die Weiterentwicklung von Netatalk zu gewährleisten, und manche Firmen nutzten das und manche nicht (und zu denen gehört eben auch Synology, die teils elend alte Netatalk-Versionen einsetzten, hardcore-beratungsresistent dagegen waren, "wie man's richtig macht" bzw. ein sehr eigenes Verständnis davon hatten und wohl immer noch haben, wie das mit cross-platform bzw. heterogenem Netzwerken aussieht. Und genau darum geht's, wenn man vom identischen Client aus den identischen Server über zwei grundverschiedene Protokolle erreichen will)

Mit anderen Worten: Mir ist aus dem Grund die Firma unsympathisch und ich traue ihr daher vermutlich mehr Schlechtes zu als gerechtfertigt wäre. Voreingenommen/befangen nennt man das wohl

Aber halbwegs objektive Prophezeiung: Diejenigen NAS-Hersteller, die bislang schon NetAFP durch Supportverträge unterstützt haben, haben auch zwangsläufig mehr Sensibilisierung für die Mac-Thematiken, werden hoffentlich so schlau sein, mit ihren Supportverträgen jetzt mit zu SerNet zu wechseln und werden dann die sein, die als erste vollwertigen SMB2-Support in ihre NAS-Eimer einbauen (und für Synology wird wie in der Vergangenheit gelten: "Bei uns dauert's länger, bis es überhaupt kommt und dann auch mal richtig funktioniert")

Der Witz ist der, dass "iTunes-Library auf NAS" schon sehr früh auch vollständig mit SMB funktioniert hat (Apple hat in ITunes ja sogar eingebaut, dass iTunes immer, wenn es selbst die Mediathek verwaltet, sogar Ordnernamen kompatibel zu Windows anlegt weil Windows bspw. über einen Punkt am Ordnernamenende stolpert, wirst Du für die Band R.E.M. immer nur das Verzeichnis "R.E.M_" finden). Und das wird auf Synology auch so sein. Aber halt vermutlich nicht, wenn man "mittendrin" das Protokoll wechselt.

Ich würde in so einem Fall die Daten einmal komplett vom NAS ziehen, dann auf dem NAS eine eigene Share SMB-only freigeben, iTunes da hinzeigen lassen und die ganzen Tracks von iTunes selbst dorthin kopieren lassen. Das muß anschl. problemfrei laufen.

Ich hab hier seit Jahren mein "Musik-NAS" in Form einer Notebook-Platte per USB an 'ner Fritzbox, die das per SMB rausreicht. Ist zwar saulahm... aber völlig irrelevant weil Datenraten der Tracks eh viel niedriger und iTunes eh noch cached. Das Ganze war in den allerersten Versionen von iTunes mal ein Problem, weil iTunes da noch auf HFS+-Semantiken übers Netz gebaut hat. Aber das ist schon lange Geschichte.

Wenn es zufriedenstellend funktioniert - warum eins davon abschalten?
Im Infofenster eines auf dem NAS befindlichen und im Finder gemounteten Volumes kann man übrigens sehen (anhand der Pfadangabe) ob eine afp oder smb Verbindung besteht.
Auf meiner Buffallo KLinkstation habe ich auch smb *und* afp aktiviert. Die MacBooks im haushalt verbinden sich via afp, aber auf diversen IOS Geräten greifen Apps über smb auf Inhalte des NAS zu.
In die quere gekommen ist sich da noch nichts, es läuft quasi wie geschmiert

Thomas

Danke für die Hintergrund-Info. Ich muss das mal mit meinem Bruder besprechen. Allerdings hat er auf dem NAS auch andere Daten, die er sich in der Familie teilt (mit Win und Mac-Rechnern). Die FritzBox-Option kommt daher wohl nicht in Frage, wobei er sich das für seine Musik ja durchaus mal überlegen kann.

Die vorgeschlagene Prozedur mit der Neuorganisation der Musik auf dem NAS ist auch einen Versuch wert – sofern ich alles verstanden habe. Da muss ich vielleicht noch mal nachhaken. Wichtig ist dabei vor allem, dass ihm seine Titelbewertungen nicht verloren gehen.

Eine Frage, die in dem Zusammenhang immer wieder auftaucht: Sollte die iTunes Library-Datei besser auf dem Mac oder auf dem Speichermedium liegen, wo auch die Musik liegt?

Es funktioniert ja eben nicht mehr zufriedenstellend. Zumindest habe ich den Eindruck, dass die anfängliche Geschwindigkeit durch den Umstieg auf Mavericks jetzt nicht mehr da ist. Meine Vermutung nach dem lesen dieser Beiträge war, ob eventuell jetzt ein anderes Protokoll verwendet wird.
Das mit dem Infofenster war mir bekannt. Ich schaue da nur nicht regelmäßig hin.

Also bei mir wird bei gleichzeitig aktivem smb und afp auch unter mavericks immer über afp verbunden. was sagt denn der Pfad im Infofenster des volumes?

Das dürfte bei dem Ansatz schwierig werden, weil das ja einem Neuimport aller Tracks entspricht. Aber seitdem Apple vor ca. 100 Jahren iTunes ein halbwegs vollständiges Scripting Dictionary verpaßt hat, gibt's ja eigentlich auch für die exotischten Vorhaben was in fertig: Einfach mal gucken: http://dougscripts.com/itunes/

Hier liegen nur die Tracks auf dem NAS und die Library ist lokal (und ich habe einen Import-Workflow aufgebaut, der in dem Zusammenhang mir alles automatisiert -- ich verdien aber auch unter anderem mit Skripting meine Brötchen). Hintergrund war der vor einigen Jahren noch etwas zweifelhafte Musikgeschmack der Tochter. Inzwischen hat sich das gedreht.

Weitere Ansätze wären ja, das NAS nicht nur als Dateiserver zu nutzen sondern gleich als DAAP-Server (das unterstützen ja die meisten NAS inzwischen von Haus aus?). Wird hier jetzt darauf hinauslaufen, dass auf dem Virtualisierungs-Mini (läuft 1a unter VMWare ESXi und beherbergt zig Testsysteme) ein virtueller OS X Server die zentrale DAAP-Instanz spielt (ganz simpel als iTunes mit freigegebener Mediathek)

Das ist, wie andere schon geschrieben haben, Quark.

Nicht ganz - SMB ist das bevorzugte Protokoll für Mavericks - Mavericks. Für Mav-ML oder Mav-Lion etc. ist nach wie vor AFP das bevorzugte Protokoll.

Und auch Mav-Mav ist nicht immer SMB, es kommt auch darauf an, wie die Verbindung aufgebaut wird. Da gibts mehrere Möglichkeiten.
Ack.

Deine zweifelhafte Tochter schmeckt nach Musik? Oder wie muss man gedreht hier verstehen?
Ansonsten sehr sehr gute Info von Thomas Kaiser.
Selbst das dunkle Wurstbrot muss überpenibel die Tochter anzweifeln, um auch nur ein kleinstes Haar in der Suppe zu finden. Kudos!

Leider wissen halt zu wenige, dass es verschiedene SMB Versionen in unterschiedlichen Varianten gibt... Hier klärt Thomas gut auf.

Fun fact: Auf der für mich letzten WWDC auf der ich war (vor 4 Jahren) wurde dieser Weg schon angedeutet: "We want to be a first class SMB citizen" und "SMB will be the protocol for the future".

Und der Feature-Vergleich von AFP und Apples SMB damals, Apples SMB plänen damals zeigte, wo es hin geht. NFS war auch drauf. Vernichtend ....

Auch AFP. Beim Umstieg auf Mavericks meine ich gelesen zu haben, dass Apple einige Verbesserungen am AFP Protokoll unternommen habe. Deswegen habe ich den Geschwindigkeitszuwachs darauf geschoben und bin einfach davon ausgegangen, dass sich der Mac mit dem "verbesserten" AFP mit dem NAS verbindet. Ich hab aber nie nachgeschaut und natürlich nicht darüber nachgedacht, was das NAS für ein AFP spricht.

Nein, am Protokoll selbst ist seit halben Ewigkeiten nichts wirklich Neues mehr passiert: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/AFP/AFPVersionDifferences/AFPVersionDifferences.html

Was sich hingegen ab und an ändert ist, dass der AFP-Client in OS X "strenger" wird und Sachen, die er vormals laxer gehandhabt hat, auf einmal als zwingend ansieht (siehe bspw. ab 10.7 stärkere Login-Verschlüsselung für das Etablieren von AFP-Sessions oder vollumfängliche Implementierung der für TimeMachine notwendigen AFP-Calls, was vorher viele Leute, die auf Billig-NAS gesetzt hatten, ihre Backups gekostet hat. Oder ab 10.9, dass OS X wählerischer ist, was die Publizierung der richtigen Bonjour-Records für TimeMachine-enabled AFP-Shares angeht). Aber am Protokoll selbst... da war schon lang nix mehr und da wird auch nichts mehr kommen.

Das "Lustige" daran (bzw. das, was man als Supporter oder Admin oder Systembetreuer bzw. als irgendwer, der im Spannungsfeld zwischen Mensch und Technik andauernd zerrieben wird, sich jeden Tag erneut aufs Brot schmieren sollte) ist ja, dass kaum etwas so unzuverlässig ist wie die eigene Erinnerung (dem Hippocampus sei Dank) und dass Erwartungshaltungen gerne mal "Fakten schaffen".

Soll heißen: Erinnerungen trügen und Erwartungen sensibilisieren. Weshalb retrospektive Betrachtungen grad nach bewußten Veränderungen meist komplette Einbildung sind.

Bestes Beispiel: Man kündigt beim Kunden an, dass übers Wochenende paar Server umgestellt werden, volles Programm, klingt kompliziert und Scheitern möglich. Und nach der Umstellung jagst Du ein paar realen Problemen und ganz vielen Falschmeldungen hinterher, die nichts mit der Umstellung an sich zu tun haben.

So richtig hab ich das auch erst kapiert als wir so 'ne Umstellung mal kurzfristig abgeblasen aber verpeilt hatten, bescheidzusagen. Beim IT-Support klingelten völlig unbeeindruckt davon am Montag morgen die Telefonate, weil "nichts mehr geht" (alles Sachen, die schon länger nicht funktionierten aber teils durch die eingetretene Sensibilisierung auf einmal überhaupt oder wieder bemerkt wurden bzw. durch die Aufforderung, Probleme zu melden, endlich dann auch mal bei den "blöden ITlern, die nie zuhören" abgekippt wurden)

Doch, Apple hat Carbon ohnehin zu Grabe getragen, und Cocoa hat mit NFS und UFS ohnehin kein Problem, hier sei der historische Hinweis auf NEXTSTEP erlaubt. Leider hat Apple bei Wechsel von MacOS auf OSX so ziemlich alles in Bezug auf das Dateisystem versaut was zu versauen war. UNIX liegt eine ganz eigenen Philosophie des Dateihandlings zu Grunde. Diese Philosophie hat sich als extrem flexibel und zukunftssicher erwiesen, was man von MacOS Philosophie nicht behaupten kann.

Also anstatt in Carbon und Cocoa die Resourceforks schon innerhalb des FrameWorks zu serialisieren, muß dies auch weiterhin das FS machen. Das Resultat sind Inkompatibilitäten mit zentralen UNIX APIs, was wiederholt zu Ärger führt. Hätte sich damals Apple anders entschieden, hätte man direkt in der ersten OSX Version NFS als zentrales Filesharing Protokoll nutzen können, und all die bekannten Problemen wären Geschichte gewesen.

Was Du jetzt so schön beschreibst, sind die Folgen von Designfehlern beim Wechseln von MacOS zu OSX.