NBlog

10 Antworten zu “Mac OSX 10.6 Snow Leopard und Samba”

1. Andi sagt:
   01. Dezember 2009 um 14:41

   Ein im Zusammenhang mit obiger “Lösung” leider nicht zu behebender Bug läßt sich wie folgt reproduzieren:

   [1] Man binde mindestens eine SMB-Resource ein.

   [2] Man versetze den Rechner in den Standby-Modus.

   [3] Man reaktiviere den Rechner(, dessen netmounts danach auch noch alle verfügbar sind).

   [4] Man unmounte die SMB-Resource.

   Danach läßt sich vom demselben Server via Finder keine Resorce mehr mounten.

2. Robert sagt:
   01. Dezember 2009 um 15:08

   Kann ich mit 10.6.2 als Client und Samba 3.0.37 nicht reproduzieren. Eventuell tritt der Fehler nur bei SMB-Shares unter Windows auf?

3. Andi sagt:
   01. Dezember 2009 um 15:55

   Besten Dank für die Antwort. Ist hier leider auch beim Zugriff auf Samba so. Allerdings handelt es sich um 3.0.24 unter Solaris10. (Seit 2007 läuft diese Kombination ohne Mucken.)

   Immerhin hat das Update auf SL 10.6.2 bewirkt, daß die über bonjour/avahi publizierten File-Services nach dem WakeUp aus dem Mac-Client-Standby sichtbar bleiben. tcpdump/wireshark zeigt keine verdächtigen Meldungen. Die shares auf dem Server werden wöchentlich via cron-job von “dot”-Files bereinigt, deren Erstellung aber prinzipiell erlaubt ist.

   ### smb.conf : [global] ###

   [ global ]
   interfaces = eth0
   unix charset = UTF8
   workgroup = $workgroup
   netbios name = $servername
   server string = $aboutserver
   hosts allow = $somehosts
   hosts deny = $somehosts
   security = USER
   encrypt passwords = yes
   socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
   max xmit = 65535
   large readwrite = no
   create mask = 0777
   directory mask = 0777
   force create mode = 0777
   force directory mode = 0777

   ###

   Das Drucken auf über eben diesen Server eingebundenen Druckern funktioniert unter allen Umständen hervorragend. Das Problem zeigt sich im übrigen bei allen Macs der Firma hier. Die Rechner sind teils aus der Schachtel. Einzige Maßnahme: Leopard im Auslieferungszustand aktualisiert, anschließend Update auf Snow Leopard. Eine zerschossene Lokal-Konfiguration infolge intensiver Bastelwut ist (leider) auszuschließen.

   Aber schonmal schön zu hören, daß es kein generelles Problem ist.

4. Robert sagt:
   01. Dezember 2009 um 16:20

   Meine Konfiguration ist fast identisch (wenn auch etwas einfacher – hier greifen nur 3 Rechner auf die Shares zu)

   [global]
   workgroup = WORKGROUP
   netbios name = Firma Server
   server string = Gentoo Samba %v

   security = USER
   encrypt passwords = true
   hosts deny = 0.0.0.0/0
   hosts allow = 127.0.0.1 xxx.20.126.140
   unix extensions = no

   #veto files = /.AppleDB/.AppleDouble/.AppleDesktop/.DS_Store/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/
   delete veto files = yes

   load printers = no
   show add printer wizard = no
   printing = none
   printcap name = /dev/null
   disable spoolss = yes

   ###

   (Es ist kein Drucker vorhanden und mit den letzten Zeilen spare ich mir CUPS-Fehlermeldungen in den Logs)

   Im privaten Bereich betreibe ich exakt die gleiche Konfiguration und habe auch mit Standby-Problemen zu kämpfen. Allerdings unter umgekehrten Vorzeichen: Nach einigen Tagen Standby kann man auf die Shares nicht mehr zugreifen und sie auch nicht auswerfen. Dann hilft nur ein Neustart.

   Das Skript zum Entfernen der “Dot”-Dateien würde mich interessieren

5. Andi sagt:
   01. Dezember 2009 um 17:43

   Wenn ich das lese, daß es daheim wieder aus magischen Gründen nicht geht, könnt ich – mit Verlaub – … weinen.

   ##########################
   #!/bin/sh
   # Meta-Muell vom RAID loeschen v0.1

   # Zu saeubernde Verzeichnisse
   DIRECTORIES=

   for DIR in $DIRECTORIES
   do
   find ${DIR} -name .DS_Store | xargs rm -f ;
   find ${DIR} -name Thumbs.db | xargs rm -f ;
   done
   ##########################

   Warum wurden die unix extensions deaktiviert?

6. Robert sagt:
   01. Dezember 2009 um 18:07

   Naja, es passiert ja nur alle Paar Tage. Ich habe es auf Arbeit noch nicht erlebt, weil ich den Rechner abends immer runterfahre.

   Vielen Dank für das Script. Wird gleich verbaut

   Was die unix extensions angeht: Ist hatte bei der Konfiguration ein hartnäckiges Rechteproblem. Ich weiß nicht mehr, ob unix extensions = no Teil der Lösung oder ein Überbleibsel ist.
   Ungefähr so muß es sich zugetragen haben: http://bugs.contribs.org/show_bug.cgi?id=4164

7. Andi sagt:
   01. Dezember 2009 um 20:22

   Alles klar. Danke. Kam hier noch nicht vor.

8. Andi sagt:
   03. Dezember 2009 um 22:46

   So. Problem gelöst. Wollte das hier noch reingeschrieben haben, um sicherzugehen, daß es nicht noch jemandem so geht und man unnötig am nun schon Jahre gut laufenden Samba-Server rummacht:

   Obwohl wie beschrieben alle Mac-Clients diesen Fehler zeigten und weil ich nach den Meldungen, daß es hier und da mit SL auch fehlerfrei funktioniert, nicht davon ausgehen wollten, daß die Mädels & Jungs in der Apfel-Entwicklungsabteilung etwas so tolles wie SL gleich in elementarsten Funktionen an den Grund reißen, ging ein umfangreicheres Netzwerk-Testen los.

   - Ich tauschte Kabel wo der Tester auch nur einen Moment beim Einstecken auf einem Pin minimal flackerte.
   - Ich ging auch nochmal alle Dosen/Unterputzleitungen durch. Alles bestens.
   - Zuletzt ging es an die Switches.

   Und siehe da: Auf einem jede Menge RuntsRX. Der Switch, auf den die Grafiker geschaltet waren, empfing also “Paketsplitter” bzw. Pakete kleiner 64Bytes, dem Minimum. Ich tauschte aus Paranoia zunächst den Switch. Selbe Statistik. Die Kontrolle der Ausgabe von ifconfig auf den Macs mit SL ergab: Allesamt hatten die Ethernet-Schnittstelle automatisch konfiguriert – 1000MBit, FullDuplex mit FlowControl und JumboFrames (also MTU 9000).
   Eine Apfelkiste, die ich testweise platt gemacht hatte, um mit Leopard gegenzutesten funktionierte übrigens hervorragend am Fileserver. Fast volle Auslastung der Netz-Bandbreite. Gleiche Einstellungen (mit 9000er MTU). Das vorübergehende Deaktivieren der JumboFrames auf einem der SL-Rechner bzw. besser gesagt die manuelle Konfiguration auf 1000MBit, FullDuplex mit FlowControl und MTU 1500 ließ den betreffenden Rechner sofort wieder aus seinem “Finder klemmt im Ballonmodus”-Schlaf aufwachen. Keine Störungen. Mounten, unmounten, Standby, wieder mounten, nochmal Standby – alles bene.

   Fazit: Grand Central Dispatch ist womöglich so großartig und so zentral, daß der Netstack nach kurzem Powernapping im Standby schlicht die Daten hexelt, ehe sie ins Kabel wandern. Ist es das, was Apples Marketingabteilung als Kernel-”Multithreading” beschrieb? tcpdump sieht davon offenbar (noch) nichts. Vermutlich weil es dank GCD mit dieser Hexelei etwas anfangen kann.

   Ich würde die [b]volle[/b] Rechnung am liebsten Apple schicken. Vielen Dank nochmal für das Feedback!

9. Robert sagt:
   03. Dezember 2009 um 23:01

   Nein, ich hab zu danken. Falls ich jemals mit Jumbo Frames zu tun habe, werde ich mich sicher an diesen Eintrag erinnern.

   Jedoch finde ich eine MTU von 9000 auch sehr abenteuerlich. Ich werde mal die Tage testen, unter welchen Umständen OSX diesen Werte vorgibt.

10. Andi sagt:
    03. Dezember 2009 um 23:31

    Beim Filetransfer kann das – wenn alle Teilnehmer im Netz entsprechend konfiguriert sind und die Router mitmachen – schon ordentliche Übertragungsratensprünge bringen.
    Zugegeben: Wenn nicht alle NICs so konfiguriert sind bzw. die Router/Gateways vor lauter fragmentieren nicht nachkommen, kann es auch das Gegenteil bewirken.
    Aber hier machte es den Unterschied von knapp 55MB/s (mit JFs) zu knapp 30MB/s (ohne JFs). Zusätzlich reduizieren sie die Prozessorlast um fast 35%. Wo es ging. Jetzt dauern Bilder (bis zum hoffentlich baldigen Fix) halt etwas länger

Hinterlasse eine Antwort

Name (erforderlich)

Email (wird nicht veröffentlicht) (erforderlich)

Website