Wir nutzen einen Mac PRO als Dateiserver. Mac OS Ventura 13.2
Auf der genutzten Partition ist "Eigentümer ignorieren" angehakt. Alle User verwenden zum Mounten den selben User mit Admin-Rechten.

Wir haben leider immer das Problem, dass man Dokumente ein/zweimal bearbeiten, verschieben oder umbenennen kann und dann der Zugriff gesperrt ist.

Aktuell lasse ich 3x täglich die Rechte per Script neu setzen, das ist aber keine Dauerlösung.

Du hast vergessen zu erwähnen, wie die Rechte dann stehen, wenn sie "kaputt" sind und auf welche Werte du sie zurücksetzt.
Das ist nur auf den ersten Blick ein "einfaches" Setup und ich könnte mir schon vorstellen, dass sowas für genau diese Phänomene verantwortlich ist.

Für eine sauberes Setup geht man den entgegengesetzten Weg. Der wird dir aber nicht gefallen:

• 1 User = 1 Account
• Jeder Ordner mit den notwendigen Zugriffsrechten, meinetwegen für Gruppen.
• Admin-Rechte nur, wenn nötig.

Ventura läuft ja regulär nicht mehr auf dem Mac Pro.
Ein mutiger Schritt einen Server über diesen Weg upzugraden.
Kann es möglicherweise daran liegen? Ich hätte mir das ehrlich gesagt gespart. Welchen Mehrnutzen hast Du Dir bei Ventura als Dateiserver erhofft? Reine Neugier...

Auf dem von 2019 natürlich …

Gib mal im Terminal für eine betroffene Datei
und poste hier das Ergebnis. Zusätzlich bitte noch Nutzer- und Gruppennamen (und ggf. zusätzliche Gruppenzugehörigkeiten) von einem Nutzer, der vergeblich versucht, darauf zuzugreifen.

Oh ja stimmt. vergesse die Serie tatsächlich immer wieder. Steht allerdings auch nicht dabei, welcher Mac Pro es ist.

Der Mac Pro wird doch mit Ventura ausgeliefert? Es ist ein aktueller MAC PRO. 32GB RAM 8TB SSD

Wie gesagt, wusste nicht welcher Mac Pro es war, dass hier gleich wieder alle mit Daumen runter durchdrehen ist Wahnsinn.

do shell script "chmod -R 777 Dass alle alles können.

Rechte sind dann wie im Bild, der User (ICH) ist nicht der mit der sich die User anmelden!

Der User der nicht darf heist "User"
total 96976
drwxr-xr-x 4 grafik staff - 128 18 Apr 12:40:46 2023 ./
drwxrwxrwx+ 33 grafik staff - 1056 18 Apr 12:40:42 2023 ../
0: user:user allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
-rw-r--r--@ 1 grafik staff - 40675916 18 Apr 12:39:21 2023 IMG_0026.CR2
com.apple.lastuseddate#PS 16
-rw-r--r--@ 1 grafik staff - 8973958 18 Apr 12:40:30 2023 IMG_0026.JPG
com.apple.FinderInfo 32
com.apple.lastuseddate#PS 16
com.apple.metadata:_kMDItemUserTags 42

Sieht schon einigermaßen verfummelt aus.

Wenn du wirklich auf sämtliche Permissions verzichten willst, könntest du es mit umask 000 probieren. Anleitung s.u.
Ich nehme an, dass der smbd im Sinne der Anleitung ein Systemprozess ist.

https://support.apple.com/de-de/HT201684

Und dass er nicht darf, ist auch korrekt, denn die beiden Bilddateien sind nur für den Eigentümer schreibbar (-rw-r--r--) und der heißt grafik. Der Nutzer user darf lediglich zu dem Ordner, in dem die Bilddateien liegen, Dateien oder Ordner hinzufügen oder löschen; Dateien bearbeiten darf er nicht (die Zeile mit der 0: vorne).

Das ergibt mehrfach keinen Sinn. Erstens ist das kein vollständiger Befehl. Soll das ein AppleScript sein? Wie führst Du das aus?

Zweitens ist das ein falscher Befehl. Die dritte 7 in chmod -R 777 erklärt alle einfachen Dateien zu entweder ausführbaren Programmen oder Ordnern. Da ist Chaos sozusagen vorprogrammiert. Dennoch scheint der Befehl nicht mal ausgeführt zu werden:
Der Finder-Screenshot sagt dasselbe aus wie schon das Terminal: schreiben darf nur der Eigentümer (Ich); Dein Befehl hat überhaupt nichts bewirkt.

Was mich verblüfft, ist, dass angeblich die Zugriffsrechte auf der Platte ignoriert werden. Ist das wirklich so eingestellt? (Diese Einstellung gibt es nur für externe Platten!)

Bloß nicht! Das setzt die umask für alle Systemprozesse!

Schon klar. Wollte aber keinen Vortrag halten, wie und warum er seine ganze Baumstruktur reparieren muss, angefangen bei seinem user grafik und allem anderen danach.

Und dass er nicht darf, ist auch korrekt, denn die beiden Bilddateien sind nur für den Eigentümer schreibbar (-rw-r--r--) und der heißt grafik. Der Nutzer user darf lediglich zu dem Ordner, in dem die Bilddateien liegen, Dateien oder Ordner hinzufügen oder löschen; Dateien bearbeiten darf er nicht (die Zeile mit der 0: vorne).[/quote]

Aber warum? Die Laufwerke werden nur mit dem User "User" verwendet? Also auch die Daten auf den Server kopiert.


Ja, ist ein Scipt:
try
do shell script "chmod -R 777 /Volumes/Daten_Werbung/" user name "Grafik" password "****" with administrator privileges

end try
[/quote]
OK. Blöd. Was muss die letzte 7 sein?

Das geht ab der zweiten Partition, wenn man die Interne in Partitionen aufteilt.

Weil Du die Funktion "Eigentümer ignorieren" eingeschaltet hast. Das heißt nicht, dass die Berechtigungen abgeschaltet werden, sondern dass eine zusätzliche Umabbildung der Eigentümer stattfindet, die im Einzelfall sehr schwer zu verstehen sein kann. Die Dateien werden beim Anlegen virtuell dem Benutzer zugewiesen, der sich gerade an der ersten Bildschirmsitzung an der Konsole des Servers angemeldet hat. Das macht die Verwaltung von Rechten noch wesentlich schwieriger, und bei einem Server der zur Zusammenarbeit genutzt wird, fast unmöglich.

Jede 7 ist falsch. Der Befehl ist komplett ungeeignet. Für das, was Du vorhast, muss man mit Zugriffssteuerungslisten (ACLs) arbeiten. Dann kümmert sich der Server selber darum, beim Anlegen von neuen Objekten vollautomatisch die gewünschten Rechte einzustellen.

Je nach dem, für wen was in welchem Land auf dem Server gespeichert wird, kann die bisherige Konfiguration sogar gesetzeswidrig sein, da gegen elementare Sorgfaltspflichten verstoßen wird.

Korrektur: Das sollte nicht "beim Anlegen", sondern "bei jedem Zugriff" heißen.

Danke. Dann werde ich das testweise wieder deaktivieren. Da aber ca. 10 Personen sich mit dem selben User anmelden, sollte das doch kein Problem sein?

TimSK
Zunächst mal zwei Bitten zur Lesbarkeit:

• Bitte versuche doch, Deine Beiträge korrekt zu formatieren, das macht sie für alle leichter lesbar. Klar geht das manchmal schief, aber das sieht man doch sofort, sobald man den Beitrag gepostet hat, und hat dann über 10 Minuten Zeit, das zu reparieren.
• Es ist eine eher doofe Idee, einem Beispielnutzer ausgerechnet den Namen User zu verpassen, weil man dann permanent zwischen user und User unterscheiden muss. Jeder x-beliebige andere Beispielname ist besser – ich nenne den user jetzt einfach mal stefan und habe auch die Zitate entsprechend korrigiert..

Aber dann verstehe ich das Problem überhaupt nicht mehr. Wenn sich alle ausschließlich als stefan anmelden, ergibt es doch weder Sinn, die Zugriffsrechte zu ignorieren noch, allen Dateien und Ordnern die Gruppenschreibbarkeit zu verpassen. Alle sind dann stefan und können als solcher lesen und schreiben.

(Ich hatte gedacht, es gibt stefan, ingrid, peter, bettina, …, die aber alle der Gruppe staff angehören, sodass Du deshalb via chmod die Gruppenschreibbarkeit einschalten wolltest. Wenn ich das tatsächliche Szenario richtig verstehen, gibt es doch überhaupt keinen Bedarf für den chmod-Befehl?)
Aber wenn die einzige Sache, die geschieht, der Unix-Befehl chmod ist, warum dann AppleScript und nicht einfach ein Shell-Skript? Wie rufst Du das Skript denn auf?
So, wie es momentan aussieht, ist das ja alles gar nicht nötig, aber nur zur Info: Du kannst Dateien und Ordner nicht über einen Kamm scheren, da die unterschiedliche Zugriffsrechte brauchen, z.B. bei Nur-Eigentümer-Schreibbarkeit Dateien 644 und Ordner 755. (Und Marcel Bresink hat recht, deshalb sind alle 7 verkehrt, nicht nur die letzte – da hatte ich einen Knoten im Hirn, sorry.)

Was Du ja vermutlich eigentlich wolltest (auch wenn es jetzt unnötig scheint), ist, auch der Gruppe staff Schreibrechte zu verpassen, den Unterschied zwischen Dateien und Ordnern aber unangetastet zu lassen. Das geht mit chmod nnn prinzipiell nicht, da die Ziffern für Dateien eben gerade und für Ordner ungerade sein müssen. Stattdessen würde man schreiben chmod g+w, was soviel bedeutet wie es bleibt alles beim alten bis auf die Tatsache, dass nun auch die Gruppe (g) schreiben darf (+w).
Oooops, danach habe ich so lange nicht mehr geschaut, dass ich das mit der Default-Einstellung von Apple verwechselt habe (die ist bei allen internen Partitionen Zugriffsrechte ein).

Ich versuche die ACLs nun mit Tinker Tool System zu setzen. Aber beim Klicken auf Anwenden passiert nichts.
Wenn ich das Fenster wechsle kommt eine Meldung "Möchtest du die geänderten Berechtigungseinstellungen anwenden?" dass ich mit Ja bestätige, aber ändert leider nichts. Festplatten-Vollzugriff ist gegeben.

Auch ACLs brauchst Du doch aber überhaupt nicht, wenn tatsächlich alle Nutzer stefan sind?

TimSK

Vielleicht kurz noch zum Verständnis, inwiefern sich via chmod eingestellte Unix-Zugriffsrechte und ACLs unterscheiden:

Die Unix-Zugriffsrechte werden über chmod immer nur für bereits existierende Dateien und Ordner verstellt und haben keinen Einfluss darauf, welche Zugriffsrechte neu angelegte Dateien bekommen. (Auch in einem Programm lediglich modifizierte Dateien werden teilweise als vollkommen neue Dateien geschrieben und dann wieder mit den Standard-Zugriffsrechten!)

Um die Unix-Zugriffsrechte neu angelegter Dateien zu verändern, bräuchtest Du den im Beitrag von MrChad am 18.04.2023 um 17:25 Uhr verlinkten umask-Befehl, der für einen bestimmten Nutzer dann aber wiederum systemweit gilt und nicht nur für einen bestimmten Ordner.

ACLs hingegen erlauben es – das ist hier das Entscheidende –, vererbt zu werden. Du kannst einem Ordner ACLs (z.B. Gruppenschreibbarkeit) dergestalt zuweisen, dass auch in dem Ordner zukünftig angelegte Dateien und Ordner wieder diese ACLs bekommen (und ihrerseits weitervererben).

Wie gesagt, ich verstehe im Augenblick gar nicht, wozu Du überhaupt irgendwas an den Zugriffsrechten ändern musst, wenn doch alle immer der Nutzer stefan sind, aber falls doch, dann aus den genannten Gründen auf alle Fälle ACLs.

Danke für die Details. Ich probiere jetzt mit ACLs und TInkerTool System das zu regeln.
Es gab Zugriffs-Probleme und meine Idee war es mit chmod das zu lösen. war wohl die falsche Idee...

Sorry, das Programm wurde heute morgen aktualisiert und für ein paar Minuten lang war ein fehlerhaftes Build auf dem Web-Server abrufbar. In diesem Build hat genau dieser Knopf "Anwenden" keine Funktion. Falls Du ausgerechnet diese Fassung (Version 8.5 Build 230418) heruntergeladen hast, lade das Programm erneut, kopiere es über die alte Version und starte zur Sicherheit auch den Computer neu, um mögliche Ventura-Bugs mit Hintergrundobjekten und dem Festplattenvollzugriff zu vermeiden.

Aber welche denn, wenn alle Nutzer stefan sind? Das habe ich immer noch nicht verstanden.

Vielleicht irre ich mich, aber ist es nicht so, dass da für diese Anwendung mit einem neuen MacPro als Server mit (komplizierten) Kanonen auf Spatzen geschossen wird?
Wäre es nicht viel einfacher, preiswerter und stabiler, es würde ein entsprechend dimensionierter NAS eingesetzt werden. Die gibt es mittlerweile auch mit 10GB-Ethernet und Platz für jede Menge SSD - sogar mit redundanter Speicherung für einen Bruchteil dieses Preises. Da dürften doch solche Probleme überhaupt nicht vorkommen und beim NAS könnte man die einzelnen Anwender sogar simpel mit ihrem eigenen Account zugreifen lassen und die Rechte trotzdem recht einfach auf das anpassend, was nötig wäre.
Oder liege ich da gänzlich falsch?
(dann sorry und ich gehe Asche kaufen, um sie auf meinen Kopf zu streuen)

Ob der neu ist oder nur so ungenutzt rumstand, wissen wir nicht.

NAS-Systeme sind nicht grundsätzlich "einfacher". Unter der Haube sind es auch nur ne Art UNIX(-oide) -Systeme, die Prinzipen der permissions etc. sind die gleichen.
Bloß das NAS-GUI ist besser auf Datei-Freigaben zugeschnitten und fokussierter. Beim Mac kommt man um ein paar Ausflüge ins Terminal nicht so leicht herum.

Den Grundfehler "ich mache alles sperrangelweit auf, dann brauch ich mich um Security nicht zu kümmern" kann man auf NAS genauso machen. Vielleicht mit weniger unmittelbaren Konsequenzen und vielleicht leichter zu fixen.

Wer sagt Dir denn, dass auf dem Mac Pro nichts sonst passiert? Die Dateien kann er doch locker nebenbei bereithalten.
Das wiederum kann ich überhaupt nicht nachvollziehen. Ein extra Gerät nur zum Speichern (was jeder Mac nebenbei kann), keine Mac-GUI, eine zusätzliche Sollbruchstelle, in der Regel hässlich wie die Nacht, oft mit lauten Lüftern, kein APFS. Wozu???

Ich hatte sowas vor 20 Jahren einmal in meinem Leben und habe mir geschworen: nie wieder!

Ha! Zufälle gibts! Mit dem neuen Build gehts!

Der Hauptgrund ist Spotlight, dass auf der NAS nicht so wollte, wie es sollte. Und der Kunde hat finanziell keine Einschränkung.

Das war mein Punkt. Ich komme mit den NAS-Einstellungen zumindest bei Synology super klar und das Teil verhält sich seit Jahren ultrastabil.

Okay, das könnte auf einem MacPro als Server tatsächlich deutlich schneller sein, da die CPUs selbst guter NAS doch lange nicht an dessen Power rankommen.

In Zeiten von AMD Epyc oder Dual Xeon im NAS eher unwahrscheinlich.

Ein kleiner Tipp zu dem chmod-Befehl, für alle, die das Zahlenzeugs als Parameter der reinen Unix-Rechte zu kompliziert finden...

Es geht auch:

chmod ugo+(-)rwx

u=user g=group o=others r=read w=write x=execute +=Recht hinzufügen -=Recht entziehen

Beispiel: um das zum Schreiben der Gruppe zu entziehen:

chmod g-w Dateiname

Beispiel: um das zum Schreiben der Gruppe und allen anderen zu entziehen:

chmod go-w Dateiname

Beispiel: um das Leserecht dem Benutzer und der Gruppe zu erteilen:

chmod ug+r Dateiname

Man muss sich also nur "ugo" und "rwx" merken bekommt damit alles eingestellt, ohne irgendwelche Zahlen und Bitdenkereien. Rekursiv geht das natürlich genauso mit -R.

Vielleicht kann der ein oder andere das gebrauchen.