Kommentare zu: Mac OSX 10.6 Snow Leopard und Samba

Von: Robert

Robert — Tue, 30 Mar 2010 14:33:09 +0000

Unter anderem zählt Apple gewohnt kryptisch ja auch folgende Verbesserung auf:

- resolve an issue that prevented files from copying to Windows file servers

@Jentz: Für Samba sollte es einen Befehl geben, der analog zu diesem hier ist:

defaults write com.apple.AppleShareClient afp_cleartext_allow -bool true

Von: Andi

Andi — Tue, 30 Mar 2010 14:20:33 +0000

In 10.6.3 wurde der Fehler augenscheinlich behoben. Der Zugriff auf den Samba-Server mit aktivierten JumboFrames funktioniert wieder.

Von: Jentz

Jentz — Wed, 24 Mar 2010 08:56:46 +0000

Hossa,

ich ärger mich auch gerade mit SL rum. Gibt es denn keine Möglichkeit, Passwörter unverschlüsselt zu übertragen?? Ich möchte mit dem MAC auf einen Samba-Server zugreifen. Dieser akzeptiert leider nur unverschlüsselte Passwörter.

Viele Grüße

Von: Andi

Andi — Thu, 03 Dec 2009 22:31:57 +0000

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

Von: Robert

Robert — Thu, 03 Dec 2009 22:01:33 +0000

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.

Von: Andi

Andi — Thu, 03 Dec 2009 21:46:15 +0000

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!

Von: Andi

Andi — Tue, 01 Dec 2009 19:22:24 +0000

Alles klar. Danke. Kam hier noch nicht vor.

Von: Robert

Robert — Tue, 01 Dec 2009 17:07:42 +0000

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

Von: Andi

Andi — Tue, 01 Dec 2009 16:43:19 +0000

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?

Von: Robert

Robert — Tue, 01 Dec 2009 15:20:32 +0000

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