Publizieren mit dem Mac OS X-Server? Unbrauchbar!

MacMacken-Leser Wolfgang hat mich per E-Mail auf einen gravierenden Fehler in der Server-Version von Mac OS X 10.6 «Snow Leopard» hingewiesen:

Wenn eine große Menge Daten auf einen Snow Leopard-Server von einem anderen Mac kopiert werden, „verhaspelt“ sich der Server irgendwann. Die Folge ist, dass ab diesem Zeitpunkt das Änderungsdatum aller von nun an kopierter Daten auf das aktuelle Datum geändert wird. (Bsp. 40 GB Daten. Ab ca. 30 GB tritt der Fehler auf. Gigabit-Ethernet. Daten von einigen Kilobyte bis mehrere 100MByte.)

Wir haben den Fehler auf zwei MacMini Server und einem Intel MacPro mehrfach überprüft. Der Fehler tritt auch noch unter 10.6.4 Server auf. Der Fehler tritt nicht unter 10.5 Server auf. (MacPro. 10.5 Server haben wir nicht für die MacMin-Server getestet, da diese mit X.6 ausgeliefert werden.)

Die Folge ist, dass SL-Server für Publishing nicht zu gebrauchen ist.

Fehler dieser Art halten mich bislang davon ab, Mac OS X für Server zu verwenden.

7 Comments

  1. dr3do
    29. Juni 2010

    Diese Meldung ist mir ähh… etwas zu ungenau. Hast du mehr Input zur genauen Konstellation (d.h. den kopierte Daten, Ordner- und Dateirechte, Sharepoints, Kopierweise)?

    Reply
  2. Martin Thomas
    29. Juni 2010

    Ziemlich laue Beschreibung jenes angeblich vorhandenen Verhaltens in Mac OS X Server (10.6.4); lässt sich hier jedenfalls nicht reproduzieren/nachvollziehen.

    Reply
  3. Dirk Försterling
    30. Juni 2010

    Mit sind an Snow Leopard Server zwar auch einige Dinge negativ aufgefallen, doch beim Kopieren von ca. 200GB Daten mittels eines MacBook Pro auf den Server sind die Zeitstempel heile geblieben.

    Was haben eigentlich die Datei-Zeitstempel mit Publishing zu tun?

    Reply
  4. rk
    30. Juni 2010

    @Martin Thomas
    hast du eigentlich eine Lösung für das DNS/Gastnetz-Problem gefunden?

    Bei mir zeichnet sich Mac OS X Server dadurch aus, dass man das VPN nach ungefähr einem Tag neu starten muss, ansonsten kann man sich nicht mehr damit verbinden. Dabei ist es völlig egal, ob man innerhalb oder ausserhalb des Netzwerks ist oder welches Gerät man benutzt.
    Die Fehlersuche war bisher nicht besonders ergiebig.

    Reply
  5. Martin Thomas
    1. Juli 2010

    @rk

    Diese DNS-Gastnetzwerk-Geschichte ist so eine etwas leidige Sache; ich konnte in Erfahrung bringen, dass sich die Airport Firmware 7.5.1 nochmals etwas anders verhält als die Firmware 7.4.2, wobei jedoch die erstgenannte Version nur für die Late-2009er-Hardwarerevision von TCs/AEs verfügbar ist… aber, der langen Rede kurzer Sinn, das Problem ist bis dato immer noch nicht zufriedenstellend gelöst.

    Betr. VPN Server Dienst: Verzeih mir die vielleicht viel zu banale Frage, aber kann es sein dass, in deinem Falle nach ~1 Tag, die jeweils gerade verfügbaren IPs ausgehen die der VPN-Server-Dienst den anfragenden Clients vergeben könnte? Die Lease-Time jener einst an einen VPN-Client vermittelten IPs, ist, ich mag mich täuschen, relativ lange, sprich bei jedem (Re)Connect von jedem Gerät wird ’ne neue IP vergeben (es wird im definierten IP-Range hochgezählt) bis die, standardmässig meines Wissens nach 50 IPs alle ‚aufgebraucht‘ sind; wird spätestens dann zu jenem Zeitpunkt keine der im definierten IP-Range befindenden IPs freigegeben (leased), stehen keine weiteren IPs für die künftig sich verbindendenden Gerät zu Verfügung und die Clients werden bis auf weiteres keine Verbindung aufbauen können. Mit dem Neustart des VPN-Dienstes auf dem Server würden alle IPs freigegeben werden und das Spiel würde aufs neue beginnen… PS: Nur eine hochspekulative Vermutung, aber möglich wär’s ja 🙂

    Grüsse,
    Martin Thomas

    Reply
  6. rk
    1. Juli 2010

    @Martin Thomas

    Danke für Hinweis, daran hatte ich noch nicht gedacht.
    Die Lease-Time beträgt zwar einen Tag und beim Verbinden wird jedesmal (die haben tatsächlich „jedesmal“ abgeschafft, ich fasse es nicht – und ich habe 14 Jahre gebraucht bis ich’s gemerkt habe) eine neue Adresse vergeben, aber wenn alle aufgebraucht wurden, werden einfach wieder unbenutzte Adressen neu vergeben.

    Gruss
    rk

    Reply
  7. Ralf M.
    26. Januar 2012

    Hi folk,
    wir können den oben genannten Fehler bestätigen:
    Beim Kopieren größerer Datenmengen (z.B. mehrere Bilder mit insgesamt 2 GB) von Clients auf den Server wird ab einem unbestimmten Zeitpunkt des Kopiervorganges das Änderungsdatum der Dateien auf den Zeitpunkt des laufenden Kopiervorganges geändert. Das hat gravierende Folgen für den Publishing-Workflow, angefangen von der Archivierung, Datenbankpflege bis zu Verknüpfungsproblemen in Indesign.

    Weitere Informationen:
    – OSX Server 10.6.8, Xserve 2 x 2.26 GHz Quad-Core, 12 GB RAM
    – Gigabit-Netzwerk
    – bis zu 50 Clients im Netzwerk
    – Fehler tritt erst im Laufe des Tages auf, doch die CPU-Auslastung übersteigt niemals 10 %
    – Kopiervorgänge sind auf internen Serverplatten sowie auf xRaid fehlerhaft
    – Fehler tritt bei allen Sharepoints auf, selbst im Adminbenutzerbereich des Servers tritt der Fehler auf.
    – Fehler hat nichts mit den Rechten zu tun, da er häufig aber nicht immer, nur bei großen Datenmengen und bei allen Sharepoints mit unterschiedlichen Rechten auftritt
    – Fehler ist ebenso Switch-unabhängig, denn er tritt bei Netgear-Switches und Cisco-Switches auf
    – Kopieren innerhalb des Servers ist problemlos
    – Kopieren vom Server auf Clients ist problemlos

    Wir sind für Anregungen zur Fehlerbehebung dankbar, ebenso für weitere Bestätigungen des Fehlers.

    Reply

Leave a Reply