Hallo, ich habe einen Mac im Netzwerk, auf dem regelmäßig Daten von externen Partnern in einem frei gegeben Verzeichnis landen. Immer wieder gibt es dort Schwierigkeiten, weil sich Verzeichnisse nicht umbenennen oder löschen lassen, das hängt mit den Rechten zusammen (bitte hier nicht diskutieren, warum das so ist – es ist einfach so.) Ich nehme dann BatChmod und habe wieder für ein paar Tage Ruhe. Trotzdem nervig.

Weder AppleScript, noch Automator oder Terminal sind Dinge, wo ich die absolute Kenne habe. Ich habe was gefunden mit Cron Jobs und irgendwo auch eine Lösung von Adobe, das kriege ich aber alles nicht hin. Jedenfalls nicht so, wie es erklärt wurde.

Frage: Wer kennt eine Lösung, die das automatisch jede Nacht macht? Verzeichnis scannen, alle Eigentümer und Gruppen löschen und durch einen neuen Eigentümer mit entsprechender Gruppe ersetzen?
So ähnlich wie das der BlueHarvest mit den DS_STORE Dateien macht, nur halt nicht löschen sondern mit Veränderung der Rechte. Danke für Hinweise.

Das zugehörige shell-Skript hat keine fünf Zeilen, und das könnte man per launchdaemon automatisch ausführen lassen, dafür gibt es mit Lingon auch eine gut bedienbare GUI.

Danke Hannes. Gut zu wissen. Hilft mir wirklich weiter.

Ich muss mich an das Thema auch noch einmal ranhängen...bei uns ähnliches Problem:

Auf dem Server befinden sich 1 freigegebener Hauptordner mit 5 Unterordnern.
Diese Unterordner haben für eine Handvoll Netzwerk-Benutzer aufgeteilt in verschiedene Gruppen (z.B. "Chefs", "Freelancer") verschiedene Rechte (manche User dürfen alles, manche nur lesen aber nicht schreiben oder schreiben aber nicht löschen, usw.).
Eigentlich soll an jedes Objekt im Unterordner die betreffenden Rechte vererbt werden, was aber immer wieder mal nicht funktioniert. Bei einigen der von Netzwerk-Usern erstellten oder bearbeiteten Objekte hat zufällig noch nicht einmal der Server selbst Zugriff, was dann spätestens bei den Backups Ärger macht.
Das heisst, man muss alle paar Tage mit +I das Infofenster des jeweiligen Ordner aufmachen und die Rechte "auf alle Unterobjekte anwenden ...", sprich übertragen.
Bisher versucht habe ich:
- mit TinkerTool die Vererbung eingestellt, was aber nicht ständig und zuverlässig an alle Unterobjekte übergeben wird.
- mit Automator versucht, eine Rechteübertragung zu scripten, scheitert aber an der notwendigen Passworteingabe während des "Abspielens" des Scripts
- BatChmod kann nur einen und nicht mehrere User ändern, kann daher auch nicht automatisiert werden
- mit dem Terminal-Befehl chmod kann ich (vermutlich mangels Kenntnis) auch nur 1 Besitzer, 1 Gruppe und Andere ändern - ich habe aber mehrere User bzw. mehrere Gruppen

vermutlich kann man chmod auch anders anwenden und auch scripten, aber das habe ich nicht geschafft.

Zusammengefasst: mir fehlt eine Idee, wie ich für einen Ordner regelmäßig die eingestellten Rechte für mehrere User und mehrere Gruppen an alle Unterobjekte übertragen kann.

Schön, dass das Thema noch mal hochgespült wird. Ich habe mich nach der letzten "Hilfestellung" ein wenig im Netz umgeschaut und dann diese Lösung für mich gefunden:

do shell script "chmod -R u+r+w+x,g+r+w+x,o+r+w+x /Volumes/zum/ordner" user name "username" password "daspasswort" with administrator privileges

Habe das mal als Script laufen lassen und nach dem Test dann den Script als .app gesichert. Als Kalender-Ereignis läuft diese App jetzt jede Nacht zur gewünschten Zeit ohne Probleme durch.
Du kannst ja auch verschiedene Scripts für unterschiedliche Verzeichnisse durchlaufen lassen, oder? Bei mir war das nicht erforderlich. Habe nur seitdem ein Problem weniger am Hals.

Danke, ich versuche mal mein Glück.
Damit habe ich schon einmal eine Idee zum Shell-Script.
Muss mir nur noch einfallen, wie ich chmod für mehrere Gruppen und mehrere User anwenden kann.
Vielleicht finde ich dazu ja noch was...

oh wie doof von mir... musste erstmal drauf kommen, dass das Janze im Script-Editor zu laufen hat und nicht im Automator...

ABER @ratz-fatz: Danke es funktioniert. Ich habe aber noch eine kleine Verbesserung vornweg:
Da mir am meisten die Dateien Probleme bereiten, die von anderen angelegt und auf den Server geschoben wurden, habe ich vor das chmod-Script noch sowas gehängt:

do shell script "chown -R username /Volumes/zum/ordner" user name "username" password "daspasswort" with administrator privileges

Damit mache ich den Server erstmal wieder zum Eigentümer und habe anschliessend weniger Probleme beim Rechte vergeben.

eher Geschmacksfrage: dein Script funktioniert auch oktal, also mit z.B. "777" statt "u+r+w+x,g+r+w+x,o+r+w+x"

Verständnisfrage: Wenn man den oben beschriebenen Befehl ausführt, ist jede Datei für alle Benutzer lesbar, änderbar und ausführbar. Hat das irgendeinen Grund? Vor allem, weil normalerweise normale Dateien nicht ausführbar sein sollten. Ich nutze immer chmod 644 (u+r+w-x,g+r-w-x,o+r-w-x) für normale Dateien. So sind die Dateien nur für den Benutzer änderbar, dem sie gehören, alle anderen Benutzer dürfen die Dateien nur lesen und keiner darf sie ausführen.

Hmm. Wir haben nie solche Probleme und hunderte von Nutzern auf vielen TB Fileshares. Reicht dafür nicht eine einzige ACL, die sicherstellt, dass alle, die auf das Share kommen auch alles lesen/schreiben dürfen, was darauf gelegt wird?

Ich habe bis heute nicht verstanden, was der Unterschied ist zwischen "Excel-Datei auf dem Server kann geöffnet werden" und "Excel-Datei auf dem Server kann ausgeführt werden". Meine Bitte an die Spezis hier: Die Frage ist keine Verarsche, ich wüsste wirklich gerne, wie sich das verhält mit dem "Ausführen".

@ Tobi1051: die chmod 777 war nur ein Beispiel für das Shell-Script, geht natürlich je nach Zweck auch anders

@ arminhempel: ja, wenn alle lesen und schreiben dürfen, ist das kein Problem. Wenn aber wie oben beschrieben verschiedene User verschiedene Rechte haben sollen, ist die Rechte-Vererbung scheinbar nicht mehr zuverlässig. Zumindest bei uns nicht und bei 2-3 anderen Büros auch nicht. Auch ACL hilft da nicht so recht, zumindest nicht zuverlässig.

ratz-ratz
Grob gesagt: Das Filesystem kennt praktisch nur Ordner und Dateien. Und das Markmal "ausführbar" macht eigentlich nur bei Textdateien Sinn denn die können Shellscripte etc. enthalten die man per Terminal starten kann. Bei allen anderen Dateien bringt die Ausführbarkeit absolut nix, die sind "nur Beifang"

Danke Mike, jetzt habe ich wieder was dazu gelernt

Statt per Skript automatisch regelmäßig die Rechte nachregeln zu müssen – das Setzen eines Sticky Bits , Setgid oder Setuid für das betreffende Verzeichnis mit Wirkung auf die drinliegenden Inhalte hätte es nicht auch getan oder tut es nicht auch, wäre nicht evtl. naheliegender/sinnvoller? Schon probiert? Funzt/reicht nicht?

Für mich alles absolute "Böhmische Dörfer".

Bis hierhin, denke ich, richtig.

Diese Aussagen sind für meine Begriffe ein wenig zu lax und dürften zudem, so wie es formuliert ist, unrichtig sein. Und "Beifang" ist da bestimmt auch nichts.

Verzeichnisse z.B., in die Du wechseln/schreiben können willst/musst, müssen ausführbar sein (x), sonst kannste da nicht reinwechseln und darin noch nicht mal irgendwas lesen geschweigedenn irgendwas schreiben... (z.B. chmod 755, chmod 1755, chmod 555, chmod 700)
Text- und Konfigurationsdateien müssen allgemein per se nicht ausführbar sein, sind es i.d.R. auch nicht, sollen es i.d.R. auch nicht, Les-/Schreibbarkeit reicht (z.B. chmod 644, chmod 600), sie werden erst durch Setzen des execute-Bits (x) an der betreffenden Stelle für den Nutzer (u), die Gruppe (g) oder alle anderen (o) ausführbar und damit, sind es shell-skripte, als solche sinnvoll und aktiv nutzbar (z.B. chmod 755). Binaries sind i.d.R. ausführbar, müssen es sein, haben das execute-Bit (x) also gesetzt (z.B. chmod 755).

Oder? Man möge mich bitte ggf. berichtigen oder ergänzen.

Nein leider ... eben auch ausprobiert: trotz gesetztem SUID des übergeordneten Ordners wird der Ersteller einer darin liegenden Datei auch immer sofort Eigentümer und alle anderen, einschl. des Servers und der Gruppe werden auf "nur lesen" gesetzt, auch wenn der Eigentümer und Server der zur selben Gruppe gehören.
( ... laut des Handbuches von Tinkertool wird SUID und SGID von macOS sowie Single-Unix3+ ignoriert...)

Wo hast Du das gelesen? Unter Marcel Bresinks Tinkertool-Doku Die Einstellungskarte ACL-Rechte - Zusätzliche Berechtigungsmarkierungen steht bzgl. SUID, SGID, Sticky-Markierung u.a. zutreffenderweise das Gegenteil dessen, was Du da grad' behauptest, nämlich u.a.:

Und auch die Release-Notes-Historie von Tinkertools redet ab und zu davon, den Umgang mit und die Erklärungen zu SUID, SGID und Sticky-Bit im Programm verbessert zu haben – kein Wort davon, dass da was nicht geht, nicht möglich wäre oder ignoriert würde. Auch in Apples (zugegeben schon etwas älteren, aber wohl immer noch aktuellen und durch nichts anderes ersetzten) UNIX 03 Conformance Release Notes kein Wort davon, dass unter macOS diesbzgl. was nicht gehen oder es ignoriert oder anders gemacht würde.

Schaue ich mir meine aktuelle macOS 10.12.6-Installation an, so finde ich bestätigenderweise im System so einige Dateien und Ordner mit gesetztem Sticky-Bit bzw. SUID und SGID. Also geht's. Ich wüsste auch nicht, warum Apple sowas Essentielles abschaffen oder ignorieren sollte, erst Recht im Hinblick auf Konformität mit dem in die Jahre gekommenen POSIX.1-2001/SUSv3/UNIX 03 oder gar dem aktuellen POSIX.1-2008/SUSv4/UNIX V7.

Solltest Du da andere Infos haben, lerne ich gerne hinzu und bin neugierig, was Du da an entscheidender Stelle wo entnommen haben willst, das Deine diesbzgl. Aussage nährt/stützt, das würde ich dann gerne mal selber lesen, für die Nennung der Quelle wäre ich hiermit dankbar.

hier:


Du hast natürlich recht, dass die Sticky-Bits insbesondere im System Sinn machen, steht ja auch so im Handbuch.
Es ging aber nicht um einen Nur-Hinzufügeordner, sondern, siehe Problemschilderung ganz oben, um "verschollene" Freigaben.

Ich habe also freigegeben Ordner, wo die Lese-, Schreib- und Lösch-Rechte für die verschiedenen User mit dem von Dir vorgeschlagenen Weg (SUID/GUID) nicht vollständig zu lösen waren. Hab´s kreuz und quer ausprobiert
Mir, und soweit ich es verstanden habe, ratz-fatz macht insbesondere die saubere Vererbung der im Mutter-Ordner eingestellten Rechte Probleme.

Jedenfalls konnte ich mein ganz oben geschilderetes Problem jetzt erst einmal mittels Tinker-Tool System lösen: Dort mittels ACL zusätzlich zu (user+group+others) weitere Gruppen erstellt. Diese mit verschiedenen Rechten ausgestattet und den Server selbst der Gruppe mit den vollen Lese+Schreibrechten zugeordnet.
Danach ebenfalls mit Tinkertool die Vererbung eingestellt und auf alle betreffenden Unterobjekte angewandt.

Beim Erschaffen einer neuen Datei wird zwar der Ersteller gleichzeitig der Eigentümer laut POSIX und group und others werden zum "nur lesen" verdammt, aber durch die Vererbung im ACL bleibt sowohl der Server als auch die sonstigen notwendigen Gruppen in der Lage, die Datei zu bearbeiten (zu löschen, usw.).

Hallo zusammen
habe letztes Jahr daran gebissen, Mac mini 10.10.5 Server und 10 User über Share über AFP (10.12.4): - Office 11-Probleme
Zuerst machte ich 'groups für die User, ohne Erfolg.
Dann setzte ich die Haupt-Ordner mit TinkerTool-System/ACL mit den verschiedenen 'groups; mit Vererbung:
- dann waren die Probleme weg!
- im Finder-Info-Fenster wird mit Standard-Einstelllungen nun Salat angezeigt ('Eigene ...)
- auch in der Server-App /Sharing
=> setze die Rechte NIE MEHR mit dem Finder-Info oder der Server-app; da seien falsche Vorlagen im Hintergrund.
Nun habe ich gewartet mit 10.12.