Hi all,
habe einen Mini (2020 M1/16GB mit SSD) ein Promise Pegasus32 R6 (HFS+) hängen, auf dem 7 Leute über SMB arbeiten. Alle auf Monterey. Mini auch. Immer wieder habe ich dort Probleme mit den Zugriffsrechten. Ich weiße sie dann rekursiv zu, dann ist kurze Zeit Ruhe. Sieht für mich so aus, als ob sich das nicht vererben würde. man kennt das ja noch von älteren Mac Systemen, dachte aber nicht, dass es das noch immer gibt.
Habe mit
die ACLs zu löschen. Da spuckt er mir aber Fehler aus. So wie es aussieht, sind es so schöne Ordner und Dateinamen mit den schönen • zeichen. Da werde ich wohl noch mehr finden. wie Handhabt ihr das?
mit ABFR umbenennen? Die werden mich dann wohl umbringen wollen.
Hab mir den Beitrag von Sascha77 durchgelesen. Scheint, das es bei ihm geklappt hat.
https://www.mactechnews.de/forum/discussion/Hilfe-Zugriffsrechte-auf-Mac-Server-wollen-nicht--343368.html
Leider kann ich dort nicht weiter antworten, weil der Thread zu ist (zu alt).
Hab mir auch reingezogen, was Marcel Bresink dazu zu sagen hatte.
Kann es sein, dass 12.x auch probleme beim duplizieren direkt auf dem server hat?
Vielleicht jetzt auf einem HFS+ Volume?
Hat irgendwer eine Idee, was ich noch versuchen könnte, bevor ich mich ans Dateiumbenennen mache?

- bitte solche Fehler exemplarisch im Wortlaut nennen, wie sind keine Hellseher
- es wäre natürlich praktisch für die Fehlersuche, wenn man mal sehen würde, wie sich die ACLs bei euch in der Realität vererbt haben oder auch nicht? Leider hast du jetzt alle Beweise vernichtet. Auch schlecht bei der Fehlersuche.
- Preisfrage: setzt Monterey überhaupt ACLs bei den Freigaben und falls ja (s.o.) ansonsten muß man die mit Terminalbefehlen oder zB Tinkertool System setzen.

Es ist genau umgekehrt: In älteren Systemen gab es den grundsätzlichen Design-Fehler, dass sich Rechte vom freigegebenen Ordner "irgendwie" auf den Inhalt vererbt haben. Ab Mojave hat Apple das endlich korrigiert. Für freigegebene Daten gibt es keine Sonderbehandlung mehr. Die Objekte verhalten sich jetzt ganz normal, so dass jede Datei und jeder Ordner seine eigenen Berechtigungen hat, die der Eigentümer beim Anlegen vergibt.

Wer trotzdem Vererbung will, kann diese mit der Befehlszeile zielgenau über Zugriffssteuerungseinträge (ACEs) einrichten. Dort sind dann die Optionen "file_inherit" und "directory_inherit" einzuschalten. Auf keinen Fall darf Vollzugriff (bzw. die Detailrechte "writesecurity" und "chown") erteilt werden. Neben den gefährlichen Sicherheitslücken, die man damit öffnet, würde das ja dazu führen, dass man Eigentümern das Recht gibt, die gezielte Rechtevergabe durch das System wieder außer Kraft zu setzen.

Damit kann man natürlich unsinnige Einträge entfernen, die der Finder erzeugt hat, aber normalerweise ist das genau das Gegenteil, von dem, was Du willst: Ohne ACLs wird Vererbung komplett ausgeschaltet.

Apple hat den beschriebenen APFS-Bug in
- macOS Mojave 10.14.6 ab Build 18G9028 oder höher,
- macOS Catalina 10.5.7 ab Build 19H1030 oder höher,
- und in allen anderen Versionen ab macOS 11.3
behoben.

Nein, auf HFS gibt es die Funktion "Duplizieren durch Klonen" überhaupt nicht.

Dateinamen sollten keine Rolle spielen. Über die Befehlszeile kann und darf man sogar mit ungültigen Dateinamen (z.B. mit enthaltenen NUL-Zeichen oder Doppelpunkten) arbeiten.

also keine ACLs verwenden? nur die UNIX rechte zuweisen?

chmod: Failed to clear ACL on file MODULUX - Messesystem LED hinterleuchtet.mp4: No such file or directory
liegt in einem ordner mit einem • im namen.

Was soll denn erreicht werden? Nochmal: automatische Vererbung geht nur mit ACLs.

Wurde dieser Ordner von macOS aus angelegt, oder von einem anderen Betriebssystem (z.B. Windows oder Linux)?

ich will eigentlich ganz einfache rechte. gruppo soll lesen/schreiben/löschen. habe aber das problem, dass hin und wieder jemand dateien/ordner anlegt, die er und andere, später nicht mehr öffnen kann. deswegen dachte ich, ich lass das rekursiv vererben. hab ich da einen denkfehler?
vorher ist da ein macpro gestanden und hat über AFP die freigaben verwaltet. kein windows oder LINUX im spiel.

HudriWudri
Jetzt fehlt der Befehl der diesen Fehler ausgeworfen hat. Ich könnte wetten, das du die Leerzeichen bzw den Pfad nicht „escaped“ hast. Alternativ kann man den kompletten Pfad auch in Anführungszeichen (nicht typographische) setzen.

Nein, genauso ist das richtig. Um aber zu sehen, ob Du Vererbung überhaupt eingeschaltest hast, müsstest Du den obigen ACE-Eintrag grp_server doppelklicken. Alle 4 Vererbungsoptionen müssen an sein.

Natürlich dürfen die ACLs dann nicht gelöscht werden, also darf das eingangs beschriebene "chmod -RN" auf gar keinen Fall benutzt werden.

ich wollte die komplatten ACLs mal rauspuffen und neu machen.
die grp_server sieht so aus

du meinst, den zum rekursiv ACL löschen?

Ja, den Befehl, mit dem du die genannte Fehlermeldung provoziert hast
Bei Fragen sollte immer Ursache (hier dein Befehl) und das Resultat gepostet werden. Dazu, was man erwartet hat bzw. warum man etwas getan hat.
Wie soll man sonst helfen wenn nicht alle Infos auf dem Tisch liegen
Wobei Marcel dir bereits die Lösung deines „Vererbungsproblems“ beschrieben hat. Der vermutliche Syntaxfehler bei der Pfadangabe ist ja nur noch ein Nebenkriegsschauplatz und dient zum Verständnis dazu, warum die Fehlermeldung entstand

OK, das kann man natürlich machen, aber dann werden die Benutzer ja vorübergehend sämtliche Rechte an den Daten verlieren und Ersatz-ACLs müssten danach neu propagiert werden. Wie im richtigen Leben findet Vererbung ja nur bei neu erzeugten Objekten statt.

Das ginge oben auch durch Auswahl von "Operationen: Alle ACLs in diesem Ordner entfernen", bzw. "Operationen: Zugriffsrechte übertragen".

So ist es korrekt. Das Schreib-/Leserecht wird dann für alle zukünftigen neuen Objekte im gesamten Teilbaum an Mitglieder dieser Gruppe erteilt.

ok. schau ich mir nochmal an. aber wie du richtig sagst, ist das ja eher ein nebenschauplatz.
tu mir nur ein bissl schwer mit dem testen, weil sonst keiner arbeiten kann
hab das mit den ACLs löschen natürlich abends gemacht. mit neu zuweisen, dauert das ja ein bissl.
das habe ich anfänglich mit tinkertool system gemacht. der rödelt sehr lange....sind auch heftig viele daten...und dann kommt er mit der fehlermeldung, das er das nicht kann. die kann ich aber jetzt nicht liefern, weil ich das ja dann gleich mit chmod -RN versucht habe. werde das heute nacht nochmal machen.

aber so wie es aussieht, ist meine überlegung richtig, oder?
bis auf die genauen fehlermeldungen, die ich mangels stress nicht lierfern kann.
ich könnte noch nachsehen, mit welcher SMB version die alle verbunden sind.

Das dürfte Marcel sicher brennend interessieren warum sein Tinkertool da gestreikt hat Er wird hoffentlich auch sagen können, ob und wo und ggf wie du du die Fehlermeldung in einem Log findest. Auch die Tatsache, das du bereits zu allererst mit Tinkertool System gearbeitet hast, gehört eigentlich in den Eröffnungspost. Lieber zu Anfang mit zuviel Infos um sich werfen (außer kompletten Crashreports) als sich die Würmer alle nacheinander aus der Nase ziehen zu lassen

hab schon verstanden
ich werde heute abend mit TTS nochmal die ACL löschen und dann die fehlermeldung posten.
dann mache ich das nochmal über das terminal. ich bemühe mich auch, es richtig zu machen.
dann werde ich die dateien und ordner mit dem "•" in "-" umbenennen.
danach werde ich die ACLs neu zuweisen.

also....hab jetzt mal diesen "•" aus den ordner und dateinamen in "-" geändert. hat ein bissl gebraucht.
dann habe ich mit TTS die ACLs gelöscht. weil ich sie dann wieder neu machen wollte.
nach ~ 10min. schreibt gibt mir TTS die fehlermeldung "es war nicht möglich, den vorgang erfolgreich abzuschließen" (siehe screenshot)
die ACL rechte sind dann zumindest für den root ordner "SERVER" gelöscht. ob darunter was fehlt, weiß ich nicht. wüßte auch nicht, wie ich da draufkomme. hab dann mit
dann nochmal das gleiche gemacht. es kommen dann heftig viele einträge, wo er das nicht kann.
und damit hat er recht, weil das alles alias sind.

weiße jetzt gerade die ACLs wieder mal rekursiv mit TTS zu.
mal sehen, was morgen so passiert. soll ich mich überhaupt melden?
oder interessiert es euch ohnehin nicht mehr?

Das ist zu ungenau. Was der Finder "Alias" nennt, könnte sein:
- ein Alias-Objekt aus dem klassischen Mac OS,
- ein macOS-Bookmark-Objekt,
- ein symbolischer Link.

Wenn chmod das auswertet, dürfte es sich wahrscheinlich um einen symbolischen Link handeln. Wenn das Ziel nicht gefunden wird, ist der Link möglicherweise kaputt.

Wozu soll das jetzt wieder dienen? Wenn man Propagieren statt Vererben verwendet, könnte man das Schreib-/Leserecht für bestehende Objekte ja über den Gruppeneigentümer regeln. Oder soll mit Absicht Vererbung durch Propagieren simuliert werden, um im gesamten Teilbaum implizite statt explizite ACEs zu erzeugen?

ich kenne nur classische alias und symlinks. macOS-Bookmark-Objekt sagt mir nichts. aber ich denke, darum geht es jetzt ohnehin nicht. es sind auf jeden fall keine symlinks, weil die user garnicht wissen, wie man sowas erstellt. aber wie gesagt, ich sehe die meldung von chmod nicht als fehler. er sagt ja nur, dass es kein file oder folder ist. womit er ja IMHO recht hat.
ok. es schheint so, als ob ich da grundlegendes nicht verstehe.
im prinzip brauch ich nur die UNIX rechte. ich habe dort am server keine superspezialrechte, dass irgendeine gruppe nur was lesen aber nicht schreiben darf. die gruppe soll alles können.
in der vergangenheit war das aber nur mit ACL rechten hinzubekommen, weil bei den UNIX rechten (ohne ACL), der user immer eigentümer war und andere user die datei nicht löschen konnten. deswegen habe ich mir gedacht, dass derartiges nur über ACL mit "vererben" funktioniert.
deswegen habe ich gestern nach der "•" in "-" umbenennungsaktion...
die ACLs gelöscht und neu zugewiesen. weil ich der meinung war, dass es dort hakt. was du mit "propagieren" meinst, ist mir fremd.
irgendwie hhabe ich das gefühl, dass ich da grundsätzlich was falsch mache, dich aber nicht verstehe.
und du bist (logischerweise) schon genervt darüber.
sorry

Es gibt Programme, die selbst symbolische Links erstellen, ohne dass der Benutzer das wissen muss. Weder chmod noch TinkerTool System werten echte Alias-Objekte aus, so dass es sich eigentlich um symbolische Links handeln muss, die von macOS automatisch ausgewertet werden. Es müsste die zusätzliche Option "-h" verwendet werden, um zu verhindern, dass chmod das verlinkte Objekt sucht. (Oder das Dateisystem ist kaputt.)

Nein, das sagt er nicht. Die Meldung bedeutet, dass das Zielobjekt nicht (mehr) da ist.

Auf einem UNIX-System wie macOS gibt es nur UNIX-Rechte.
Meinst Du in Wirklichkeit POSIX-Rechte?

"Alles" soll sie nicht können, denn auf keinen Fall soll sie die Rechte wieder verstellen dürfen. Dass jemand versehentlich "Vollzugriff" erteilt, löst nicht nur Sicherheitslücken aus, sondern sorgt hauptsächlich für Probleme mit den Rechten. Aber die oben abgebildeten Rechte waren richtig und genau das, was Du willst.

Genauso ist es. Das ist zwingend nötig, wenn Benutzer auch Daten bearbeiten sollen, die sie nicht selbst erstellt haben.

Vererben heißt, dass für neu erzeugte Objekte diejenigen ACEs, bei denen Vererbung eingeschaltet ist, an das neue Objekt weitergegeben wird. Es entsteht dabei ein ererbtes implizites Recht.

Propagieren oder Übertragen heißt, dass der Administrator für bereits bestehende Objekte Rechte auf einen ganzen Teilbaum kopiert. Dabei entstehen nicht ererbte explizite Rechte.

Das was Du erreichen willst, hätte man in zwei Schritten machen können:
1. Am obersten Ordner die ACL löschen, den Gruppeneigentümer wie gewünscht einstellen und dem Gruppeneigentümer Schreib-/Leserecht geben. Dieses Recht auf alle enthaltenen Objekte übertragen. Dabei werden automatisch alle ACLs entfernt, weil ja die "leere" ACL kopiert wird.
2. Am obersten Ordner einen ACE für die Gruppe einrichten und außer den Administrationsrechten alle Rechte einschalten. Dadurch wird das Schreib-/Leserecht in Zukunft für alle neuen Objekte durch automatische Vererbung eingestellt. Alle bestehenden Dateien bleiben unberührt.

Eine Alternative ist:
1. Alle ACLs in diesem Teilbaum löschen.
2. Wie im vorigen Punkt (2) beschreiben, die gewünschte ACL am obersten Ordner einrichten und dann in TTS die Rechte auf den Teilbaum übertragen, und zwar nicht die POSIX-Rechte, sondern nur die ACL mit der Option "Vererbung simulieren".

Die zweite Lösung kann eleganter sein, da dann alle POSIX-Eigentümer erhalten bleiben, wie sie sind, und die Vererbung der ACLs nachgeholt wird, als ob sie von Anfang an richtig eingestellt gewesen wäre. Die Dateien bekommen dann ererbte statt propagierte Rechte. Nachteil ist, dass dabei aus technischen Gründen das Änderungsdatum aller Ordner aktualisiert wird.

also zuallererst mal, wirklich großen dank, dass du die gedult mit mir nicht verlierst.
nach dieser nacht und nebel (eher regen) aktion, beobachte ich mal, ob noch beschwerden kommen.
habe die order rausgegeben, dass sie das testen sollen. mal sehen. es ist 10:17, bis jetzt habe ich noch nichts gehört.

ok? mir kommt vor, ich konnte sie auflösen.
ist mir aber jetzt puff. ist ja nur ein nebenschauplatz.

ja natürlich. es war schon ein bissl spät


ich glaube, dass habe ich verstanden. also nur die POSIX rechte!das dann so aussieht, wie mein screenshot oben?!
aber das muß ich doch dann noch rekursiv zuweisen? oder nicht?
die POSIX sind dann also egal, weil sowieso über die ACL geregelt wird? ok?
aber das mit dem „vererbung simulieren“ habe ich nicht verstanden. ich dachte, da macht er nichts sondern simuliert.
[/quote]
was bei mir eig. schon egal ist, weil ich die POSIX wie ACLs sowieso schon rekursiv mit TTS nachträglich zugewiesen habe. oder?
sollte ich das mit dem „vererbung simulieren“ jetzt noch machen?

Nicht ganz. In dem Fall wäre ja wichtig gewesen, die nicht vorhandene ACL auch zu übertragen. Durch diesen Trick wäre sie gleichzeitig mit dem Setzen der POSIX-Rechte überall gelöscht worden.

Ja.

Nein, nicht in diesem Schritt (2). Die Vererbung gilt ja sofort für den gesamten Teilbaum, es sei denn, man hätte sie durch Abschalten der Option "Auf alle Unterordnerebenen anwenden" gezielt beschränkt.

Für den Zweck, dass die Gruppe bestimme Rechte haben soll, ja. Wirklich egal sind sie nicht. macOS verwendet die Auswertungsreihenfolge "von oben nach unten", wie es der große Pfeil im Bild oben andeutet. Die POSIX-Rechte würden z.B. für Benutzer gelten, die nicht Mitglied dieser Gruppe sind.

In dem Fall tut das Programm so, als hätte macOS die ACEs vererbt. Es kopiert die ACL nicht durch rekursives Übertragen. Wenn ein ACE z.B. so eingestellt wäre, die Vererbung nach einer Ebene zu stoppen, würde das einen Unterschied machen.

Im Prinzip ja. Bei den bestehenden Objekten werden die ACEs dann nicht als vererbt markiert, da sie ja nicht ererbt sondern direkt kopiert sind. Das ist letztendlich der einzige Unterschied, der sich hier in diesem Fall quasi nur "optisch" auswirkt.

ok.....also. heute habe ich mal nichts vernommen, dass irgendwer irgendwas nicht öffnen kann.
THX
PS. TinkerTool System ist zu günstig