Hallo zusammen,

ich versorge im Haus mit unserem kleinen Mac mini mehrere Geräte via SMB-Freigabe (aktuelles 10.9.2). Da leider manche Geräte wie der Raspberry PI und auch ein Windows 7 Notebook Probleme mit der SMB-Dateifreigabe haben, musste ich auf SMBup wechseln.

Jetzt würde mich interessieren, ob vielleicht die Server-Erweiterung von Mavericks hier Verbesserungen bringt.

Hab Ihr Erfahrungen hierzu?

Frohes Schaffen!

Tom

Nein, es ist die selbe SMB-Version.

Schade und Danke!

Es wäre mal interessant zu wissen, was genau da schief läuft.

Einem meiner Kunden hat mal das hier geholfen:

Peter

Hier bei mir funktioniert der Mavericks SMB Server mittlerweile sehr gut. (Windows XP, 7,8)

Was für Probleme gibt es bei dir denn?

Das Problem liegt in der SMB-Version.
Wenn ich es richtig im Kopf habe nutzt Windows und alle älteren Geräte SMB2 und der Mac seit 10.8 SMB3. Die sind nicht 100% kompatibel, weshalb es mit Geräten wie z.b. Kopierern beim scannen auf eine Freigabe Probleme gibt.
Es gibt 2 Möglichkeiten:
1. smbUP verwenden
2. SMB2 auf dem Mac installieren. (Etwas komplizierter)

Bitte um Korrektur, sollte jemand inzwischen mehr und bessere Informationen darüber haben.

Entschuldigt die späte Rückmeldung, bin grade erst aus der Arbeit gekommen.

Zu meinen Problemen. Mein RaspberryPi mit raspbmc findet die normale SMB-Freigabe von Mavericks überhaupt nicht. Bei den Windows-Rechnern werden Kopiervorgänge immer wieder abgebrochen etc. Läuft einfach nicht stabil das Ganze.

Mit SMBup gibt es da wesentlich weniger Probleme, würde aber halt eigentlich lieber mit Bordmitteln arbeiten.

Hast Du mal cifs://IP-Adresse statt smb://IP-Adresse probiert?

Dann wird zwangsläufig SMB1 statt SMB2 benutzt, ist stabiler.

mmh, vielleicht hilft ein Neustart

Falsche Richtung Das bewirkt nur, dass OS X als Client (ab 10.9) die SMB-Protokoll-Version ändert (cifs:// alte Version, smb:// SMB2). Sein Setup ist aber genau andersrum, also OS X ist der SMB-Server.

BTW: Unter Linux ist es bzgl. des Protokoll-Präfix auch andersrum als bei OS X, da ist mount_smb die olle Variante und mount_cifs die frischere. D.h. wenn man sich mit modernen SMB-Servern verbinden will, sollte man cifs statt smb bemühen.

Äh, nö (bitte auch nie Samba, also das freie SMB-Server-Projekt, oder die OS X Server Version und die SMB-Protokollversion in einen Topf werfen). SMB/CIFS kennt verschiedene Protokollversionen, SMB war mal der Name für die uralten Implementierungen, CIFS galt dann ab 1996 als Erweiterung von SMB bzw. als die modernere Variante.

OS X konnte halbe Ewigkeiten bzw. bis einschl. 10.8 (OS X Server 2.0) nur SMB1 und erst ab 10.9 (OS X Server 3.0) SMB2. Bzgl. dieser Versionen: Microsoft kehrte irgendwann wieder zur Bezeichnung SMB zurück, definierte dann mit Vista SMB 2.0 (kann Samba seit Version 3.5 und OS X Server seit 3.0), mit Windows 7 SMB 2.1 und mit Windows 8 und WIndows Server 2012 SMB 3.0.

Nicht nur die Serverseite unterstützt verschiedene SMB-Protokollversionen sondern auch der jeweilige Client. D.h. Client und Server handeln bei der Verbindung die Version aus. Und auch noch den Dialekt (zumindest früher mal, guck bspw. mal ab Abschnitt "SMB variations" in . Das mit den Dialekten sollte heute eigentlich keine Rolle mehr spielen. Blöderweise haben aber so ziemlich alle SMB-Clients aufgrund der damaligen Problematik noch einen bunten Strauß an Rätselrate-Funktionen unter der Haube, um bei der Protokoll- bzw. Dialekt-Negotiation herauszubekommen, mit welcher "Gegenstelle" sie da reden (und davon abgeleitet dann noch Weiteres bzgl. Serverfeatures annehmen)

Und handel(te)n ggf. noch weitere Features aus (bspw. könnte es den Client interessieren, ob das Dateisystem des SMB-Servers sog. Alternate Data Streams beherrscht oder nicht). Auch noch in den initialen Verbindungsaufbau hineinspielen tun dann SMB-Features wie "SMB Signing" als auch Authentifizierung (Stichwort NTLMv2) als auch noch einiges andere. In einem Wort: Chaos (das man sich im Detail anschauen müsste. Aber bei der "Problembeschreibung" des Threaderstellers fehlen bislang jegliche Details)

Dann spielt's zumindest unter Windows gerne noch eine Rolle, ob man über UNC-Pfade oder per fix zugewiesenem Laufwerksbuchstaben zugreift. Und zu guter Letzt halte ich den OS X eigenen SMB-Server in Mavericks nach wie vor für buggy.

Für den Threadersteller alles wenig hilfreich und wohl nicht mal interessant, war nur kurz in Euer beider Richtung, weil Ihr Euch mit dem Mist ja beruflich rumschlagen müßt.

An disdophr: Bzgl. des RasPi: Was für Linux läuft da drauf, was meinst Du mit "nicht finden"? Beschreib den Vorgang mal bitte so, dass Dritte das Ganze verstehen können. Wie stellst Du unter Windows 7 die Verbindung her?

Es hieß schon immer SMB; seit es bei IBM erfunden wurde.

CIFS war ein Marketing Rebranding, es sollte ursprünglich ein Internet Protokoll werden.

Sicher?

Erst seit Mac OS X 10.7 kann OSX sich gut mit Windows 7 "unterhalten"

Nein, nein. Bzw. mir eigentlich egal, Wortklaubereien interessieren mich nicht. Fakt ist aber, dass mit CIFS als Ergänzung von NETBEUI als Protokoll NetBIOS over TCP/IP kam (daher das mit dem "Internet") und zusätzlich Erweiterungen der über SMB bislang definierten Dienste (File- und Printersharing) um Domänenkram und RPC. Der Name wurde auch außerhalb von Microsoft adaptiert, wie man ja unschwer an sowas wie cifs:// oder mount_cifs in Linux sehen kann.

10.7? Wo kommt das jetzt her?

Guck Dir das noch mal an, was ich bzgl. "Protokollaushandlung" geschrieben habe. Client und Server versuchen sich auf die höchste von beiden Seiten beherrschte Protokollversion zu einigen. Da OS X erst ab 10.9 bzw. OS X Server 3.0 SMB2 kann...

An der Stelle möchte ich auch Zweifel anmelden: Die Umstellung war von 10.6 (mit Samba 3.0.irgendwas samt SMB1) auf 10.7 (mit SMBX samt SMB2).

und wo hast du das mit OSX her?


Hannes

mein ich doch

Recht haste. Danke für die Korrektur. Als alter SMB-Hasser, der den Kram immer nur gegen Schmerzensgeld anfaßt, sollte ich in Zukunft lieber die Klappe halten

Wenigstens hat's bzgl. der SMB-Client-Komponente in OS X gestimmt

Ist mein täglich Brot, der Quatsch. Gab damals viel Streß, von wegen "Scan-Ordner für die alte Multifunktionsmühle", die natürlich nur SMB1 sprach als Client, auf einem 10.7-Server nutzen. Ging einfach nicht mehr (auf den alten Mac-Server hat es ja noch funktioniert), also entweder SMBup (was insbesondere bei 10.7 Server gar keine gute Idee war), oder FTP-enable (weil 10.7 Server auch keine GUI mehr für FTP hatte!), oder "Scan-to-Mail" einrichten, oder...

Ah, 10.8 samt Server.app v2 hatte wenigstens wieder eine GUI für FTP. Nutzen wir tatsächlich für so was. Und gerüchtehalber sollen neue Multifunktionskisten nun endlich auch SMB2 sprechen können...

Um zum OP zurückzukommen: Der SMBX von 10.7 war gruselig, der von 10.8 war so lala, der von 10.9.2 läuft eigentlich schon fast brauchbar.

Hihi, ich musste grad drüber nachdenken, dass wir beide, obwohl wir eigentlich das Gleiche machen, bzgl. SMB und Windows unterschiedlicher nicht sein könnten. Du Praktiker, grad was die Interaktion Windows/SMB mit Mac angeht (die Zeiten hab ich mit NT 4.0 hinter mir gelassen), ich inzwischen völlig praxisfremder Theoretiker. Wir haben ab und an völlig abstruse Debugging-Jobs, wo ich dann mit Sniffer und der ganzen Sysinternals-Suite im Anschlag irgendwelchen SMB-Problemen nachjage oder völlig hahnebüchene SMB-Probleme zwischen Linux als Client und bspw. Solaris SMB-Server... aber SMB angeknipst an einem Mac kenn ich eigentlich nicht.

Dito Windows. Ich glaub, ich hab einmal Vista unter den Fingern gehabt (Nachbarin in mein WLAN gebracht) und einmal Windows 7 (Cheffe von Kneipe gegenüber ins Internet geholfen), nix Windows 8. Bzw. viel wahrscheinlicher extrem verzerrte Wahrnehmung bzw. Maximalausblendung und ich verdräng inzwischen schneller als gesund ist

Bei Kunden haben die Clients, die ich anfassen musste, alle noch XP. Und bzgl. der Windows-Server schrei ich immer so lange, bis cygwin samt sshd drauf sind und schon ist mir der Rest wurscht.

Äh, hör ich da raus, dass Apples SMBX-Kram seit 10.7 nur SMB2 und keine vorherigen Protokollversionen kann? Das wär dann meine Erkenntnis des Tages heute

Es kann beides.

Getestet mit Windows XP und 10.7

Übrigens, OSX 10.6 kann mit Vista kommunizieren: SMB 2.0
OSX 10.6 kann zwar auch mit Win7 kommunizieren, ist aber nicht im Finder sichtbar: SMB 2.1

Ach, File Sharing ist mit Windows Vista und höher deutlich besser geworden.

Also, noch mal: Wichtig ist die Unterscheidung in "OS X als SMB-Client" und "OS X als SMB-Server".

Als Client (smbfs) können 10.6 bis 10.9 sowohl SMB 1 als auch SMB 2.

Als Server (samba 3.0.x) sprach 10.6 nur SMB 1, erst samba 3.6 brachte SMB 2 mit.

Als Server (SMBX) sprechen 10.7, 10.8 und 10.9 nur SMB 2, genauer SMB 2.1. Siehe dazu: http://msdn.microsoft.com/en-us/library/cc246488.aspx

Entsprechend war es an XP, Vista, 7 und Co. manchmal erforderlich, einige Einstellungen anzupassen, um mit dem jeweiligen Mac-Server erfolgreich Kontakt aufnehmen zu können, auch wegen Details wie "Paketsignierung" oder "Verschlüsselte Anmeldung". Stand heute (7 an 10.9.2 mit oder ohne Server.app) funktioniert das auf Anhieb, dank SMB 2.1 auf beiden Seiten.

Leider gibt es zu SMBX von Seitens Apple keinerlei sinnige Doku und bis heute (10.9.2, auch mit Server.app v3) im laufenden Betrieb auch kein Protokoll oder Log. Ein echtes ... nicht so schön, halt.

Anscheinend gab es für 10.7 eine inoffizielle Lösung, um das Logging einzuschalten, mal testen, ob das noch so funktioniert: http://www.stanford.edu/group/macosxsig/blog/2011/08/enable-logging-with-107-smbx-w.html

Ich meinte "OS X in der Serverrolle", siehe Hannes' dankenswerterweise sehr ausführliche Antwort. Wenn man nur zwei Kisten vernetzen will, ist es einem im Zweifel egal, wer dabei Client und wer Server spielt. Mich interessiert's aber immer nur aus der "großes Netzwerk"-Perspektive, d.h. die Unterscheidung ist essentiell.

Du Schuft, jetzt hast Du mich neugierig gemacht!

Blöderweise kann ich mir die Beschäftigung mit dem SMBX-Kram auch noch schönreden, weil wir grad ein Standort-übergreifendes Workflow-Projekt aufsetzen sollen, das ein paar Jahre halten soll (und damit auch einbeziehen muß, dass Apple in paar Jahren einfach den AFP-Server und -Client rausschmeißt).

Das ist übrigens das Verwirrende daran: Einerseits setzt Apple mit Mavericks klar das Signal, ab jetzt und in Zukunft auf SMB (2.1) zu setzen, und sich langsam aber sicher von AFP zu verabschieden. Und technisch machen Sie auch ständig was daran, 10.9.2 war wieder ein wichtiger Schritt.

Andererseits ist die Doku nicht existent (und ich habe bei internen Stellen mehrfach nachgefragt), es gibt immer noch kein (offizielles) Logging, und auch die Featureliste ist übersichtlich, insbesondere von OS X als SMB (2.1)-Client, siehe den Vergleich von smbfs mit z.B. DAVE: http://www.thursby.com/products/comparison

Ich tippe es mal so: Da gibt es noch viel...zu tun.

Hier kann man ansetzen:

Cool, Danke. Ich klöppel mir mal einen modifizierten LaunchDaemon zurecht (bzw. such vorab danach), und wenn ich was Sinniges am Start habe, mach ich 'nen neuen Thread auf, wo wir das ggf. vertiefen können.

Ich werd auch mal meine Quellen angehen, melde mich im positiven Fall per Mail. 1000 Dank einstweilen.

Irgendwie läuft das mit SMB bei Apple noch nicht so.

Server 10.9.2 / Client 10.9.2
Hier spinnt SMB total. Ordner werden teilweise nicht dargestellt. Teilweise tauchen Dateien die gerade gespeichert wurden nicht auf, sind aber vorhanden. Beim Kopieren über dem Finder kommt oft der Fehler -39. Log sagt dazu mal gar nichts.
Alle Mac Clients wieder über AFP eingebunden und keine Fehler.

Wie getippt: "Da gibt es noch viel...zu tun."

Zwischen Macs sollte man zur Zeit noch AFP nehmen.

was soll man davon halten, wenn Apple sein eigenes Protokoll aufgibt?

Völlig ok. Das "Problem" ist grad nur, dass sie jetzt Mavericks-Nutzer in so eine Art öffentlichen Betatest reingetrieben haben, weil Apples SMB2-Implementierung Stand jetzt einfach noch nicht rund läuft. Mit 10.10 oder wie auch immer das dann heißt, wird das sicherlich besser, evtl. sogar perfekt laufen.

Bzgl. Ablöse von AFP durch SMB. Das planen sie durchaus schon länger. Es ist auch nur stringent, Eigenes aufzugeben, wenn etwas weiter Verbreitetes besser funktioniert.

Apple nimmt ja nicht einfach nur SMB sondern pappt eigene Erweiterungen dran (bspw. für Spotlight). Ähnlich sind sie ja auch vorgegangen als das olle AppleTalk (also die ganze Protokollfamilie, die hoffnungslos überaltert war und für viel lahmere Netzwerke konzipiert war) durch TCP/IP-basierte Protokolle abgelöst wurde.

Die tollen Autokonfigurations- und Service-Location/-Propagation-Features von AppleTalk, für die es kein Äquivalent in TCP/IP gab (da wurde zu dem Zeitpunkt noch alles zu Fuß konfiguriert), musste Apple damals quasi nachrüsten. Und tat das auch, engagierte sich zuerst bzgl. SLP und dann globaler bzgl. des ganzen "ZeroConf"-Gedöns, das dann mit 10.2 in OS X Einzug nahm als "Rendezvous" und später in "Bonjour" umbenannt wurde.

Bei SMB ist es einfacher, man muß keine neuen Protokolle oder gar ganze Semantiken (Autokonfiguration) erfinden sondern nur bestehende Protokolle erweitern. In 10.9 ist das alles noch unrund Abwarten, Tee trinken, AFP nehmen.

Wenn die ganzen tiefgreifenden technischen Details interessieren sollten, was bei einem "gleichberechtigten" und parallelen Einsatz von sowohl AFP als auch SMB alles zu berücksichtigen ist: Da gab's im Usenet ein paar hochdetaillierte Diskussionen zu: . Um's kurz zu machen: Stand jetzt schafft es nur ein OS X 10.8 oder 10.9 als Server Clients "gleichberechtigt" bzw. parallel sowohl per AFP als auch SMB zugreifen zu lassen, alle anderen Lösungen (v.a. die ganzen NAS-Dinger) scheitern an der ein oder anderen Thematik. Details im vorherigen Link.

Ah, das bringt mich dazu, das hier http://www.helios.de/web/DE/news/AFP_vs_SMB-NFS.html mal zu lesen. In der Feature-Tabelle scheinen kleine Ungenauigkeiten zu sein: "Plattformübergreifendes Sperren von Daten und Datensätzen („File and record locking“)" listet ein "-" für 10.9 als SMB2-Server, aber das kann SMBX. Bzgl. "UNIX- und ACL-Dateizugriffsrechte" steht auch ein "-", aber das soll auch gehen, und mit 10.9.2 gar gefixt worden sein - muß ich bei Gelegenheit mal wieder testen.

Richtig spannend sind dann Gruppen und Vererbung der Rechte (POSIX, ACLs) auf neue Objekte, das funktioniert wohl nur mit Server.app.

Da stimmen leider paar Sachen nicht so ganz... bin das damals mit Ralph von NetAFP durchgegangen und der hat noch paar andere Sachen als unscharf bis falsch bemängelt.

Bringt so erstmal nix unter 10.9.2. Wir sollten damit aber besser nach umziehen?

Hallo Thomas,

es ist zwar nett und erfrischend von dir derartige Texte lesen zu dürfen, allerdings finde ich folgendes irgendwie nicht OK.


Also, auch wenn ich Apple hier und da hart kritisiert habe, finde ich das doch nicht OK, ich bin eher entsetzt. Größtmögliche Kompatibilität ist ja durchaus wünschenswert, aber das?!

Das wäre ungefähr so, als würde MS Windows einstampfen und auf Linux setzen.

Echt?

Wo hast du das her? Quelle?

Aber wegen technischer Seite, sagte Jens-Uwe Mager, das SMB eher ein elender Kompromiss sei.

Klinke mich dann nochmal kurz ein.

Von Eurer Diskussion verstehe ich leider sehr wenig bis nichts. Bin nur ein allerhöchstens etwas
versierterer Nutzer. Deshalb kann ich verm. auch mein Problem nicht in Eurem Sinn schildern.

Raspbmc ist ein Mediacenter-Linux und basiert auf Debian. Die SMB-Freigabe auf dem Mac findet der RaspberryPI nicht bei der Auto-Suche und auch nicht wenn ich mich manuell mit IP/Freigabe/ durchhangle. Für Gastnutzer müsste lesender Zugriff möglich sein.

Bei Windows 7 stelle ich ebenso per IP/Freigabe die Verbindung her. Hier gibt es immer wieder mal Verbindungsabbrüche beim Übertragen von Dateien etc.. Läuft einfach etwas unzuverlässig.

Also ich kann hier ohne Probleme von WindowsXP auf OSX10.9.2 zugreifen. Somit müsste ja der smbx Server von Mavericks auch SMB 1 können.

disdoph
Probier es mal nicht als Gast sondern mit einem Login vom Mac. (Und in der selben Arbeitsgruppe bist du hoffentlich auch)

Ganz kurz vom iPhone: Nein, das ist auch SMB 2.x, das hat XP als Client mit SP2 oder SP3 gelernt, mehr später vom Notebook.

Ja und? Die ganze AppleTalk-Protokollfamilie wurde auch in die Tonne getreten, weil sie objektiv betrachtet zu viele Nachteile hatte im Vergleich zu TCP/IP und... nur eine Nische besetzte (die "klassischen" Halbwissen-befeuerten Netzwerk-Admins schon immer ein Dorn im Auge war. So wie heute bzgl. AFP oder Bonjour alles Teufelszeug).

AFP haben sie relativ smart Richtung TCP/IP geschubst aber das kann bspw. gegen SMB2 u.v.a. SMB3 nicht so wirklich anstinken, wenn man alle SMB-Protokollfeatures auch ausnutzt. Wozu was Proprietäres weiterpflegen, wenn's 'ne sinnigere Alternative gibt?

Ich sehe da zwar in 10.9 noch kleine Nachteile (bzw. Implementierungsschwächen) im Vergleich zu AFP aber mit 10.10 wird das sicherlich passen.

Ich hab's von Helios. Erzählen Sie einem seit Jahren auf der WWDC, siehe bspw. auch den Wurstbrot-Kommentar hier:

Und wann war das? Mir scheint, dass sich sowohl bzgl. Microsoft als auhc der SMB-Situation seit 2007/2008 'ne Menge getan hat.

Neben den interessanten Kommentaren von Hannes und Thomas gibt es noch ein Themenfeld, das auch erwähnt werden muss, wenn es um die Kompatibilität bei SMB gehen soll: Ciphers.

Selbst wenn beide Client und Server beide die gleiche Protokoll-Version sprechen (und sich darauf einigen), heisst das noch lange nicht, dass der login auch funktioniert. Der Client bietet für die Authentifizierung eine Liste von verschiedenen Verschlüsselungsvarianten, den sog. Ciphers an, damit die Anmeldung verschlüsselt werden kann. Der Server schaut, mit welchen Ciphers er umgehen kann - letzendlich muss das Kennwort des sich anmeldenden Users in dieser Verschlüsselung gehasht vorliegen. Gibt es bei der Liste der möglichen Ciphers keine Überschneidung, schlägt die Anmeldung fehl, obwohl beide Seiten das gleiche Protokoll sprechen. Für den User ist das Endergebnis entscheident: Die Anmeldung schlägt fehl.
Diese Thematik wird oft unterschlagen.

Ich meine auch, dass Hannes in einem Punkt falsch liegt:

AFAIK spricht SMBX als Server auch SMB1 (neben SMB2). Allerdings werden keine alten (z.b. Lan Manager) Ciphers mehr unterstützt und mindestens NTLMv2 mit modernen Hashes verlangt. Die alten (pre-Vista oder div. Drucker) Clients können das nicht und failen. Und es gibt keinen Weg, dem SMBX Server beizubringen, alte (aka schwache, unsichere) hashes zu erzeugen und zu speichern.

Die Thematik mit den Ciphers ist im Mountain Lion - Mavericks Unterschied auch an anderer Stelle sichtbar:
In ML ist im Sharing in den Systemeinstellungen die Unterscheidung zwischen "Dateien und Ordner über AFP freigeben" und "Dateien und Ordner über SMB (Windows) freigeben". Wenn man SMB aktiviert, muss man die Kennwörter der User neu eingeben, da dann ein SMB-NT Hash generiert wird.
In Mav ist es so, dass ja beim aktivieren von File-Sharing schon AFP und SMB parallel gestartet werden. Daher ist hier nicht die Rede von SMB (Windows) File-Sharing, sondern nur "Dateien und Ordner über SMB freigeben". Damit wird SMB aktiviert, aber IMHO wird jede Verbindung von Win (irgendwas) zum 10.9er Mac scheitern. Damit das geht, müssen immer noch die schwachen SMB-NT Hashes erzeugt werden. Deswegen heisst es jetzt im 10.9er Sharing Bereich auch "Windows-Dateifreigabe:" im Optionen-Fenster.

Das kann man sehr schön nachvollziehen im Directory-Utility. Das zeigt für User in Mavericks erstmal für das AuthenticationAuthority Attribut nur ein:
;ShadowHash;HASHLIST:<SALTED-SHA512-PBKDF2>
Schaltet man für den User die Windows-Freigabe an (Kennwort erneut eingeben dabei), so sagt er:
;ShadowHash;HASHLIST:<SMB-NT,SALTED-SHA512-PBKDF2>

Und dann gehts auch mit dem Anmelden vom Windows aus.
Das steht ein bissl ausführlicher auch in meinem Buch zu Mavericks:
(Achtung: Shameless Self-Promotion).

Also wie gesagt, zu der von Thomas und Hannes ausführlich besprochenen Thematik kommt die Sache mit den Hashes noch hinzu.
Und ich glaube, dass SMBX auch als Server SMB1 kann, aber Serverseitig keine alten Hashes vorliegen und es deswegen bei alten Win-Clients scheitert, nicht weil es SMB1 ist. Aber da kann ich evtl. auch falsch liegen, da möchte ich nicht meinen Hintern drauf verwetten.

Und noch hierzu:

Ich glaube, wenn das Wurstbrot mitlesen würde, würde es sich freuen, von Thomas zitiert zu werden. Aber das Wurstbrot ist auch ein bischen untergetaucht in letzter Zeit.

Ah, ich erinnere mich dunkel. In diese Ecke gehört, daß "alte" OS X-Server wie 10.5 und 10.6 bevorzugt alte Ciphers sprachen (obwohl sie die neuen konnten, Stichwort NTLM v2), während die serienmäßigen Sicherheitsrichtlinien in Windows nur neue Ciphers erlaubten (NTLM v2 only). Also entweder Windows die alten Ciphers erlauben:

http://www.techsuperpowers.com/smb-authentication-mac-os-x-server

oder OS X nur neue Ciphers erlauben:

http://support.apple.com/kb/PH8595?viewlocale=de_DE&locale=de_DE

Den Verdacht hatte ich heute auch, als ich bisserl im Binary von smbd rumgestöbert habe ("strings /usr/sbin/smbd | grep -i smb1")

Da wäre ich mir nicht sicher. Ich hab heute mittels "dtruss -n smbd" dem Ding mal bisserl auf die Finger geschaut. Vergleich mal 10.8 und 10.9 hinsichtlich "/var/db/dslocal/nodes/Default/config/shadowhash.plist" und schau auch mal per dtruss zu. Ebenfalls hilfreich fand ich (zumindest beim Erstkontakt, danach kamen zumindest bei mir Kerberos-Tickets zum Tragen)

Ansonsten langweilt das ja extrem, dass der smbd nichts logged und es keine Doku gibt.

Hab mir in einer Linux-Installation mal Samba4 installiert und geprüft, ob man mittels smbclient wenigstens noch Aushandlungsparameter halbwegs bequem mitschneiden kann ("smbclient -d 6 -L mavericks-mini -U admin"). Scheint zu passen:

Ihr könntet Recht haben. Egal, Ihr ollen Theoretiker, es ging dann halt nicht mehr...

Ja, ok, das könnte gehen.
Ich war unpräzise - mit "Und es gibt keinen Weg" meinte ich keinen direkten Weg, d.h. über GUI / offiziell Dokumentiert und supported. Mit plist-schubs könnte es durchaus gehen, was gut wäre.

Im Endeffekt zwingt Apple damit die Clients zu sichereren Ciphers. Was IMHO durchaus richtig ist. Würde smb1 mit schwachen Ciphers immer noch funktionieren, würden die Druckerhersteller wohl nie ihre Firmwares updaten. So müssen Sie wohl oder übel - und das ist gut.

Wobei ich ja der Meinung bin, dass alle, die drucken, sofort zur Hölle fahren sollen (rückwärts, nackt, mit dem Kopf nach unten und mit brennendem Helm).

Aber:

als Theoretiker darf ich das auch sagen.

Um nochmal auf mein ursprüngliches Thema zurückzukommen.

Die Lösung fand sich in der Benutzerverwaltung von OS X. Beim Gastbenutzer das `Häkchen` - Gästen den Zugriff auf freigegebene Ordner erlauben - setzen.

Damit konnte auch der Raspberry PI mit raspbmc verbinden.

Irgendwann mal habe ich angefangen, für die elenden alten (und z.T. auch neuen) Kopierer. die sich partout nicht mit einem freigegebenen Ordner auf dem OSX Server verbinden lassen wollten, ein billiges NAS ins Netz zu stellen als Scan-Server und dieses dann per afp von den Clients aus anzusprechen...

Es ist doch immer wieder schön: Da stellt jemand eine einfache Frage wie hier z. B. "disdoph" und es entbrennt eine heftige Diskussion über die Eingeweide unseres Rechnerzusammenlebens. Kaum einer versteht was, am allerwenigsten der Fragesteller, der sich dann letztendlich mit einem banalen "Trick" (eigentlich nur dem Nachholen eines Versäumnisses) selber hilft. Wunderbar!
Ich knie nieder vor so viel geballtem Fachwissen, ähnlich wie der Gast eines Chirurgenkongresses, kapiere immer mehr was mein Ältester so treibt, und warum er mir nichts mehr über Computer erzählen will. (Warum hat der nur einen Hass auf den Mac??? -bei dem macaffinen Papa!?)

Aber: Könntet Ihr, liebe Fachleute Thomas Kaiser, Hannes Gnad, Andi Schenk etc. das mal so zusammenstricken, daß ein Mensch, der sich über 50 Jahre meist mit Literatur, klassischer Musik, Jazz und professionellem Theater beschäftigte, seinen Kenntnisstand erweitern und in sein tägliches Rechnerleben überführen kann? - oder ist das alles für den einfachen alt gewordenen User viel zu speziell? (Es gibt ja Dinge, die sind so kompliziert, daß man über sie wirklich nicht einfach reden kann!)

Ist nicht böse gemeint, aber "Literatur, professionelles Theater" etc. ... und dann Sisyphos falsch schreiben?

Ein Schelm, wer Böses dabei denkt.

Nun, es ist deutlich als Zitat markiert...

Was also tun?

Tja, das ändert aber nichts daran, dass dann offensichtlich sogar die Süddeutsche bzw. die Jetzt-Redaktion nicht weiß, wie Sisyphos korrekt geschrieben wird … Aber egal.

Hast recht! Ich werde das korrigieren! Merci beaucoup!

Das Originalzitat aus Albert Camus' "Der Mythos des* / von Sisyphos" (*neue Übersetzung) lautet: »Il faut imaginer Sisyphe heureux.« nach anderer Quelle: »Il faut s'imaginer Sisyphe heureux.«

Also: Versucht Euch Sisyphos als einen glücklichen Menschen vorzustellen, wenn Ihr könnt.

Das Problem dieser Debatte ist aber mit dem Ausflug zu Camus nicht gelöst.