- 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

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

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

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!

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

##########################
#!/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?