OS X AFP-Freigaben und Zugriff

OS X AFP-Freigaben und Zugriff

Ich verwende den 10.5.6-Client als Mini-Server und habe Probleme mit AFP-Freigaben. Alle Clients sind OS X 10.5.7

Ich habe drei Benutzer nur für „File Sharing“ auf dem „Server“ erstellt. Ich habe Gruppen erstellt und diese Benutzer in bestimmte Gruppen eingeteilt. Ich habe ACLs erstellt, um jeder Gruppe Zugriff auf bestimmte Freigaben zu gewähren.

Zwei dieser Benutzer können auf allen Freigaben lesen und schreiben, ein Benutzer kann nicht auf die Freigaben schreiben, mit unterschiedlichen Ergebnissen:

  • beim Kopieren eines Verzeichnisses wird nur das Verzeichnis erstellt, es werden keine darin enthaltenen Dateien kopiert, das Betriebssystem gibt keine Fehler aus
  • beim Kopieren einer einzelnen Datei erhalte ich drei Dialoge: „Um das Element mit dem Namen ‚xxxx‘ zu ändern, müssen Sie möglicherweise den Namen und das Kennwort eines Administrators auf diesem Computer eingeben.“ „Das Element ‚xxxxx‘ enthält ein oder mehrere Elemente, für die Sie keine Leseberechtigung haben. Möchten Sie die Elemente kopieren, für die Sie eine Leseberechtigung haben?“ und „Der Vorgang kann nicht abgeschlossen werden, da Sie für einige der Elemente nicht über ausreichende Berechtigungen verfügen.“

Bei der Einzeldatei wird auf dem Server eine Datei angelegt, die allerdings leer ist.

Meine ACL für die Gruppe, zu der dieser Benutzer gehört, lautet:

 0: group:projectmembers allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
 1: group:informationtechnology inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
 2: group:executive inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
 3: group:everyone inherited deny list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

Benutzer 1 und 2 gehören zur Informationstechnologie und zu den Führungskräften und Projektmitgliedern. Sie können in der Freigabe frei lesen und schreiben. Benutzer 3 gehört zu den Projektmitgliedern und kann nicht frei lesen und schreiben.

Ich habe gelesen, dass es sich um ein UID-Problem handelt. Allerdings verfügen Benutzer 1 und 2 auf den Clients und dem Server nicht über übereinstimmende UIDs, obwohl sie funktionieren. Daher glaube ich nicht, dass dies der Fall ist.

Irgendwelche Ideen?

Antwort1

Habe meine ursprüngliche Antwort ersetzt, nachdem ich einige eigene Tests mit einem OS X 10.5.6-Server und einem 10.5.7-Client durchgeführt hatte:

Nach ein bisschen Experimentieren habe ich festgestellt, dass OS X ein bisschen verrückt ist, wenn es um die ACL-Vererbung für Sharepoints geht. Vererbte ACLs haben immer Vorrang vor ACLs, die am Sharepoint (oder weiter unten im Baum) festgelegt sind, aber nur fürschreibenBerechtigungen. Sie können einem Benutzer problemlos Leseberechtigungen für einen Ordner weiter unten im Verzeichnisbaum erteilen, und es wird funktionieren, aber wenn Sie ihm Schreibberechtigungen erteilen, wird es hoffnungslos fehlschlagen.

WastutArbeit. Deaktivieren Sie die Vererbung für die Verweigerungsregel über der Problemfreigabe (Sie können sie dort haben, lassen Sie sie nur in keiner Weise vererben). Legen Sie dann die Verweigerung explizit am Freigabepunkt fest (das Aktivieren der Vererbung an dieser Stelle scheint problemlos zu funktionieren). Bei meinen Tests funktionierte dies problemlos, aber es wäre mühsam, wenn Sie Hunderte ähnlicher Freigaben verwalten müssten.

Eine Möglichkeit wäre eine allgemeine Verweigerung auf oberster Ebene, wenn jeder gelesen hat, und dann die No-Inherit-Sperre beim Schreiben, wie oben vorgeschlagen. Bitte lassen Sie mich wissen, wie Sie vorankommen, da ich an meiner eigenen Freigabeverwaltung interessiert bin.

verwandte Informationen