Wir haben seit kurzem einen Mac Pro Server unter 10.6.5 laufen.
Als Clients haben wir iMacs mit der Systemversion 10.6.6 im Einsatz.
Davor hatten wir einen Windows 2003 Server der eigentlich ohne Probleme lief jedoch „altersschwach“ wurde.. seit dieser Umstellung sind alle neuen Indesign-Dokumente (Indesign CS4 V. 6.0.6) die ein Client auf dem Server speichert schreibgeschützt. Auch sind ID-Dateien die von extern per FTP auf den Server geladen werden schreibgeschützt.
Die Rechte stehen für diese Platte komplett auf lesen & schreiben für everyone und auch die Gruppe steht auf lesen & schreiben.
Vielleicht weiß jemand Abhilfe. Schon mal vielen dank im Voraus.

Ins Blaue: Google mal nach umask

Antwort auf [ Thomas Richard ]

Ins Blaue: Google mal nach umask

Bei einer falschen umask sollten dann aber die Rechte entsprechend falsch gesetzt werden. Die umask hat nur Einfluss (subtraktiv) auf das Rechtesystem read, write, execute über die oktale Schreibweise. Laut den Aussagen des OP aber scheinen die zu stimmen.

Wenn ich den Schreibschutz wörtlich nehme, hätte ich die Dateiflags uchg bzw schg in Verdacht:

http://wiki.prontosystems.org/mac:deletefailure

@OP: Kannst du bitte mal den Output eines ls -lO /pfad/zu/einem/verzeichnis/mit/fehlerhaften/dateien (kleines L und grosses O und ausgeführt auf dem Xserv) posten?

Bye Tom

Ja, kann ich machen. Komme leider aber erst am Montag mittag dazu. Vielleicht finden wir eine Lösung. Danke für Deine Hilfe.

Gruß
Karl

Ich mach' mal weiter. :-)

Antwort auf [ pronto ]

@OP: Kannst du bitte mal den Output eines ls -lO /pfad/zu/einem/verzeichnis/mit/fehlerhaften/dateien (kleines L und grosses O und ausgeführt auf dem Xserv) posten?

-rw-r--r--@ 1 admin staff ...

Dank und Gruß
Bernhard

in dem Fall wäre umask eine Option, die dürfte, so wie es bei dir aussieht z.Z. auf

0644

stehen.

Was du bräuchtest wäre mindestens

0664


Zur Erklärung:

1. Stelle ist in umask obsolet
2. Stelle: Owner
3. Stelle: Group
4. Stelle: All

Werte:
0: kein garnichts ist erlaubt
1: executable
2: writeable
3: = 1+2 also executable + writeable
4: readable
5: = 4+1 also readable + executable
6: = 4+2 also readable + writeable
7: = 4+2+1 also readable + writeable + executable

Siehe auch: http://en.wikipedia.org/wiki/Chmod

Wenn ich es richtig verstanden habe, geht es bei umask um POSIX. Wir regeln die Zugriffe jedoch mittels ACLs.

Chmodden fällt raus, weil sich der Server ja darum kümmern soll. Da liegen unterschiedliche Gruppenrechte auf den Ordner/Volumens.

Dank und Gruß
Bernhard

Wollte nur kurz sagen, daß sich der Fehler nicht reproduzieren lässt. Die Sache muss also erstmal weiter beobachtet werden.

Dank und Gruß
Bernhard

Antwort auf [ Thomas Richard ]

in dem Fall wäre umask eine Option, die dürfte, so wie es bei dir aussieht z.Z. auf

0644

stehen.

Was du bräuchtest wäre mindestens

0664

Bei 644 als Berechtigung steht die umask auf 022, wenn er die Rechte auf 664 stehen haben möchte, müsste er die umask auf 002 stellen. Empfehlenswert ist das aber erst mal nicht.

http://linuxseiten.kg-it.de/...ash_Der_Befehl_umask

Bye Tom

Zwischenstand:

Es liegt wohl doch an den POSIX-Rechten. Dabei ist es wichtig, dass - wie Thomas im Prinzip schon schrieb - die Gruppe Staff Lesen & Schreiben darf. Diese haben wir nun im Server-Admin explizit gesetzt und anwenden lassen.

Problem weiterhin: Lege ich eine Datei auf dem Server an/ab, dann darf Staff wieder nur lesen - was ja an sich Sinn macht, jedoch bei Adobe-Programmen/Dateien Probleme bereiten kann.

Ein ähnliches Problem - welches uns natürlich auch nicht erspart blieb (man hat ja sonst nix zu tun :-) - hat Photoshop CS5: Irgendwann kann man eine Datei nicht mehr sichern, weil die Datei .afpDeleted123456 nicht gelöscht werden kann. Wen's interessiert: http://forums.adobe.com/thread/732422

Gruß
Bernhard

Hallo Bernhard,

kurz meine Erfahrung in dem Bereich - zugegeben nicht sehr umfangreich; ich habe es nur soweit getrieben, bis es bei uns lief.

Bis Tiger war es möglich, den AFP-Server so zu konfigurieren, dass beim Erstellen von Dateien und Ordnern in einer Freigabe die Rechte der Freigabe (in deinem Fall Lesen/Schreiben für alle) vererbt wurde. Das ist seit Leopard nicht mehr möglich (gilt für Server und die Client-Version).

Mit den POSIX-Rechten kommst du hier nicht mehr weiter, das scheint seit Leopard nicht mehr möglich zu sein (wie gesagt: nach meiner Erfahrung). Ursache scheint mir die übliche umask, die dafür sorgt, dass alle Dateien, die in einer Freigabe angelegt werden, eben nicht die Rechte der Freigabe erhalten, sondern die Rechte der umask. Leider ist aber eine umask meines Wissens nicht an eine Freigabe gebunden, sondern an einen Prozess. Damit würde also eine geänderte umask für alle Freigaben des Rechners gelten, was sicher nicht erwünscht ist. Früher wurde das Problem umgangen, indem der AFP-Server selbst die POSIX-Rechte - ausgehend von den Rechten der Freigabe - vergeben hat. Das hat Apple aber abgeschafft (und auch begründet, meiner Meinung nach).

Die Lösung sind die ACLs, die Apple mit Leopard endgültig eingeführt hat. Dabei muss beachtet werden, dass mit ACLs nicht nur die aktuellen Rechte der Dateien und Ordner definiert werden, sondern dass eigens angegeben werden muss, ob und wie Rechte auf Dateien und Unterordner vererbt werden sollen. Nachdem ich das richtig eingestellt hatte, war bei mir das Problem der fehlerhaften Rechte gelöst. (Leopard-Server, nicht Snow-Lepard. Aber da wirds genau so sein). Die entsprechenden ACLs sind file_inherit und directory_inherit.

Eine kurze Erklärung ist hier, allerdings bezogen auf Tinkertool: http://www.bresink.com/...281/Docs-de/ACL.html zum Verständnis reichts. Und da habe ich noch was gefunden: http://books.google.de/...ge&q&f=false. Hier wurde das auch schon mal in epischer Breite für das normale Leopard diskutiert: http://www.hilfdirselbst.ch/..._Server_P333193.html (Bitte ganz zu Ende lesen, ich habe in meinem vorletzten Post Mist geschrieben und das dann berichtigt).

Vorteil der ACLs ist, dass sie im Dateisystem wirken und unabhängig sind vom Prozess; heisst, es ist egal, ob du mit AFP, SMB oder FTP auf den Ordner gehst, die Rechtevergabe wird immer aus den ACLs übernommen. Und das ist wohl der Grund, warum Apple das so eingeführt hat.

Gruß

Hallo Peter,

nicht, dass das in die falsche Richtung abdrifftet: Die Zugriffe werden (nur) über ACLs geregelt.

Und: Die Probleme treten nur bei Adobe-Software (hier: PS CS5 und ID CS4/5) in Verbindung mit AFP auf (und das wohl nicht nur bei Apples AFP). Das übliche Spiel: der eine schiebt es auf den anderen! :-( Ach, ja und dann noch die sinnfreien Tipps von wegen SMB oder Datei lokal bearbeiten ... *grrr*

Gruß
Bernhard

Hallo Bernhard,

Das heisst, mit allen anderen Programmen funktioniert es? Das habe ich überlesen, tut mir leid … Dann habe ich auch keine Tipps.

Gruß

Antwort auf [ Bernhard Werner ]

[...]Und: Die Probleme treten nur bei Adobe-Software (hier: PS CS5 und ID CS4/5) in Verbindung mit AFP auf (und das wohl nicht nur bei Apples AFP).

Wobei mir da wieder die Warnung einfällt, die ich bekommen habe als wir unseren Helios Server abgeschafft haben, bloß keinen Apple Server zu nehmen. Ich dachte zwar Apple hat seine AFP Problem mittlerweile in den Griff bekommen aber...

Antwort auf:

Das übliche Spiel: der eine schiebt es auf den anderen! :-( Ach, ja und dann noch die sinnfreien Tipps von wegen SMB oder Datei lokal bearbeiten ... *grrr*

...scheinbar hat Apple immer noch die schlechteste APF Implementierung. Und wer hats erfunden...? Man wird wohl warten müssen bis iAFP auf dem Markt kommt...

Weiß schon, noch so ein sinnfreier Beitrag aber ich habe mich über eine Stunde damit beschäftigt, dein Problem in Google zu wälzen; Threads dazu gibt es ohne Ende, genau so viele mögliche Versuche das Problem zu lösen aber mit mäßigen bis keinen Erfolg.

Ich musste gerade eben selber erst nach wochenlangem Kampf kapitulieren. Ich habe es einfach nicht geschafft den alten Helios AFP Server sauber, störungsfrei und vor allem vollständig mittels rsync auf den neuen ExtremeZ-IP (AFP) Server zu migrieren. Es fehlten einfach sporadisch hier und da ein paar Megabyte, die Resource Forks wurden nur teilweise kopiert. Fazit: Es - geht - einfach - nicht! Jetzt hilft PresStore Syncronize aus.

Dann vielleicht doch noch ein halbwegs konstruktiver Tipp zum Schluss: Leg dir einen vernünftigen Third Party AFP Server zu. Helios, was teuer ist, oder Group Logic ExtremeZ-IP, was bezahlbar ist, können das einfach besser als Apple. Klingt komisch, iss aber so...

Bye Tom

Antwort auf [ pronto ]

Jetzt hilft PresStore Syncronize aus.

Für die einmalige Migration des alten Servers? Hätt's da nicht auch ein Einspielen des letzten Backups der Heliosmaschine getan? Oder geht das nur auf gleichen Serversystemen? Ne, oder?