Hallo zusammen,
wir haben letzet Woche von Panther-server 10.3.9 auf Tiger-Server eine Migrations-Inst. vorgenommen. Zunächst schien alles rund zu laufen. Dienste sind AFP, Windows FS, Open Dir, Print.
Nun haben wir doch ein größeres Problem zu lösen:
1) Am Server 10.4.7 hängen 8 Clients (6 Mac 2 DOSen) auf welchen wiederum lokale Benutzer angelegt sind. Diese haben vor der Migration zu 10.4.7 bestens unter AFP in einer Gruppe (Mitarbeiter) zusammengearbeitet . Die Clients/ Benutzer verwenden OS X 10.4.7 und greifen auf den Server mit eingeschränkten Benutzerkonten zu.
2.) Im Arbeitsgruppenmanager ist die Zuordnung der ZG Rechte / Gruppen wie auch vor der Mig. abgeschlossen: alles an seinem Ort.
3.) Nun kommts: Obwohl die User der Gruppe Mitarbeiter alle als Mitarbeiter auf die jeweiligen Netzwerkvolumes zugreifen können passiert beim erstellen einer neuen Datei/ Ordner auf dem NW Volume folgendes:
Die ZG Rechte werden festgelegt als: Eigentümer: "<jeweiliger User>" lesen &schreiben, Gruppe: "Mitarbeiter" nur lesen; Jeder nur lesen. Die NW-Volumes sind aber konfiguriert als RW-RW--- sollten also die Benutzereinstellungen unterstützen (zumindes taten sie das zuvor).
Nun das Resultat: jeder User in "Mitarbeiter" kann lustig die Arbneit des anderen sehen aber eben nicht daran arbeiten geschweige löschen oder verschieben.
Frage: wie stelle ich sicher, dass alle neuen Objekte auf den Volumes auch der Gruppe "Mitarbeiter" immer RW genehmigen? kann ich das erzwingen? woran kann es liegen, dass das passiert ist und wie kann ich das ganzheitlich beheben?
Frage 2: ein client legt wenn er neue objetke auf den volumes erzeugt stets ein gruppenrecht "admin" -r- an, owbohl der angemeldete nutzer selbst kein mitglied von admin ist?!? Any ideas?
Eine Neuinstallation kommt kaum in Frage, da das Upset wirklich stets sehr lange dauert... Wenn es jedoch sein muss... aber vielleicht ist es ja doch nur ein Klick...
Danke für eure schnelle Hilfe, es ist sehr langatmig jeden Abend die BN Rechte wieder per Sharing zurückzusetzen...
wir haben letzet Woche von Panther-server 10.3.9 auf Tiger-Server eine Migrations-Inst. vorgenommen. Zunächst schien alles rund zu laufen. Dienste sind AFP, Windows FS, Open Dir, Print.
Nun haben wir doch ein größeres Problem zu lösen:
1) Am Server 10.4.7 hängen 8 Clients (6 Mac 2 DOSen) auf welchen wiederum lokale Benutzer angelegt sind. Diese haben vor der Migration zu 10.4.7 bestens unter AFP in einer Gruppe (Mitarbeiter) zusammengearbeitet . Die Clients/ Benutzer verwenden OS X 10.4.7 und greifen auf den Server mit eingeschränkten Benutzerkonten zu.
2.) Im Arbeitsgruppenmanager ist die Zuordnung der ZG Rechte / Gruppen wie auch vor der Mig. abgeschlossen: alles an seinem Ort.
3.) Nun kommts: Obwohl die User der Gruppe Mitarbeiter alle als Mitarbeiter auf die jeweiligen Netzwerkvolumes zugreifen können passiert beim erstellen einer neuen Datei/ Ordner auf dem NW Volume folgendes:
Die ZG Rechte werden festgelegt als: Eigentümer: "<jeweiliger User>" lesen &schreiben, Gruppe: "Mitarbeiter" nur lesen; Jeder nur lesen. Die NW-Volumes sind aber konfiguriert als RW-RW--- sollten also die Benutzereinstellungen unterstützen (zumindes taten sie das zuvor).
Nun das Resultat: jeder User in "Mitarbeiter" kann lustig die Arbneit des anderen sehen aber eben nicht daran arbeiten geschweige löschen oder verschieben.
Frage: wie stelle ich sicher, dass alle neuen Objekte auf den Volumes auch der Gruppe "Mitarbeiter" immer RW genehmigen? kann ich das erzwingen? woran kann es liegen, dass das passiert ist und wie kann ich das ganzheitlich beheben?
Frage 2: ein client legt wenn er neue objetke auf den volumes erzeugt stets ein gruppenrecht "admin" -r- an, owbohl der angemeldete nutzer selbst kein mitglied von admin ist?!? Any ideas?
Eine Neuinstallation kommt kaum in Frage, da das Upset wirklich stets sehr lange dauert... Wenn es jedoch sein muss... aber vielleicht ist es ja doch nur ein Klick...
Danke für eure schnelle Hilfe, es ist sehr langatmig jeden Abend die BN Rechte wieder per Sharing zurückzusetzen...
Zuletzt bearbeitet von einem Moderator:
@rasta ... ja, danke für den Hinweis, das war bekannt; die Ordner 1up haben ja seltsamerweise die korrekten Rechte!