Freigegebener Ordner hat seltsame Berechtigungen - nicht änderbar

[KSCHMID]

Hallo, nach der Ausführung eines unglücklichen rsync auf einem freigegebenen Ordner waren alle Berechtigungen auf dem Ordner in der Systemsteuerung weg und in der File Station hatte ich noch drei seltsame: 2x root, 1x Everyone (s.u.). Die hatte ich vorher nicht. Auch nach Reparatur der Berechtigungen in der Systemsteuerung und in der File Station blieben die drei erhalten. Da sie ausgegraut sind, kann ich sie nicht löschen. Mit den root Berechtigungen könnte ich ja noch leben, aber die "Lesen" Berechtigung für Everyone will ich nicht. Was tun?

 

[Benares]

Die Grautastung besagt, dass die Rechte von einer der Ebenen darüber vererbt wurden. Das ist auch gut so, denn dadurch ist sichergestellt, dass die Rechte in allen Teilen des Baums gleich sind. Du kannst aber die Vererbung an jede Stelle des Baums kappen (Erweiterte Optionen, Übernommene Berechtigungen ausdrücklich machen) und ändern, das wird aber ganz schnell sehr unübersichtlich. Und bitte niemals an den Berechtigungen von "homes" spielen, darum kümmert sich der Benutzer-Home-Dienst.

 

[KSCHMID]

Danke für den Tipp. Leider nützt er in diesem Fall nicht, da diese unerwünschten Berechtigungen schon auf obersten Ebene des freigegebenen Ordners enthalten sind und da kann ich nichts "ausdrücklich" machen. Ich vermute, das Problem ist nur zu lösen, in dem man die Berechtigungen auf der Kommando-Ebene ändert. Dazu kenne ich mich zuwenig aus.

 

[Benares]

Quatsch, auf oberster Ebene kannst du das immer ändern, da muss man auch nichts "ausdrücklich" machen.

 

[KSCHMID]

Reicht das als Beweis?

 

[Benie]

Da bist Du ja auch falsch abgebogen.
Gehe zu Systemsteuerung - Freigegebene Ordner
Dort mache einen re. klick auf den Ordner Bearbeiten g dann Register Berechtigungen, das ist die Oberste Ebene zum Regeln der Berechtigungen.

 

[KSCHMID]

Danke für Deine Geduld. In der Systemsteuerung war ich natürlich auch. Wie schon oben gesagt, waren da ja nach der rsync Aktion alle Berechtigungen weg (auf "kein Zugriff"). Ich habe die Zugriffe dann wieder eingerichtet. Aber in der Liste gibt es ja kein "root" und kein "Everyone", so wie es bei _keinem_ anderen freigeg. Ordner Einträge für root und Everyone gibt. Weder in der Systemsteuerung noch in der File Station. Und vor der rsync Aktion waren bei dem "backup" Ordner auch keine drin.

 

[Benie]

Prüfe doch mal unter dem Freigegeben Ordner die Berechtigungen für den System User.

Von wo komen denn die Ordner via Rsync? Von einer zweiten DS?

 

[Benares]

@KSCHMID, hast du dir evtl. die Berechtigungen von /volume1 selbst zerschossen, weil du nun eine Mischung aus vererbten und expliziten Rechten hast? Ist das bei den anderen Ordnern auch so?

Ich denke, da musst mal über die Konsole ran

root@DS1522:~# ls -als / | grep volume
0 drwxr-xr-x   1 root root  1226 Mar  1 00:04 volume1

root@DS1522:~# ls -als /volume1 | grep backup
 0 drwxrwx---+  1 root           root                 114 May  8  2024 backup

root@DS1522:~# synoacltool -get /volume1
(synoacltool.c, 596)It's Linux mode

root@DS1522:~# synoacltool -get /volume1/backup
ACL version: 1
Archive: has_ACL,is_support_ACL
Owner: [root(user)]
---------------------
         [0] system::allow:rwxp--aARWc--:fd-- (level:0)
         [1] user:ActiveBackup:allow:rwxpdDaARWc--:fd-- (level:0)
         [2] group:boxusers:allow:r-x---a-R-c--:fd-- (level:0)
         [3] group:boxadmins:allow:rwxpdDaARWc--:fd-- (level:0)
         [4] group:administrators:allow:rwxpdDaARWc--:fd-- (level:0)

Verzeichnisse mit zusätzlichen ACL-Rechten erkennt man an dem + hinter den Rechten. Wie du siehst läuft /volume1 im Linux-Mode, mit den ACLs geht es erst ab den Freigegebenen Ordnern los.

 

[*kw*]

@KSCHMID: auch mal im Nutzerleitfaden unter Nr. 3 schauen, insbesondere die zwei Grundlagenvideo zu Nutzer und Berechtigungen.

Du „verknotest“ dich sonst wieder.

 

[NSFH]

Also des Rätsels Lösung braucht man keine Konsole. Selbst in verkorkseten Ordnern (ausser Sonderfall homes) erstellt die Syno eine saubere ACL.
Wie schon oben geschrieben Systemsteuerung > Freigaben.
Hier in der entsprechenden Freigabe sowohl unter Berechtigungen als auch erweiterten Berechtigungen alles rauslöschen.
Dann über die Filestation auf die oberste Freigabeebene gehen und checken, ob die Berechtigungen jetzt stimmen und ggf. noch die Vererbung wieder aktivieren und den Haken setzen bei Vererbung auf weitere Unterordner und Dateien.
Danach sollte alles wieder normal sein.
Sollte nach dem nächsten Backup in dem Backupordner ab der zweiten Ebene wieder root und everyone stehen, wird dies vom Quellsystem so übernommen. Ist aber sicherheitstechnisch kein Problem, denn everyone kommt nicht zu diesem Ordner, da er in der Freigabe nicht erscheint. Du kannst nicht durch die zweite Tür gehen, wenn die erste verschlossen ist. Von daher egal wenn ein Unterordner Freigaben enthält die unzutreffend sind.

 

[KSCHMID]

@KSCHMID, hast du dir evtl. die Berechtigungen von /volume1 selbst zerschossen, weil du nun eine Mischung aus vererbten und expliziten Rechten hast? Ist das bei den anderen Ordnern auch so?

Ich denke, da musst mal über die Konsole ran

root@DS1522:~# ls -als / | grep volume
0 drwxr-xr-x   1 root root  1226 Mar  1 00:04 volume1

root@DS1522:~# ls -als /volume1 | grep backup
 0 drwxrwx---+  1 root           root                 114 May  8  2024 backup

root@DS1522:~# synoacltool -get /volume1
(synoacltool.c, 596)It's Linux mode

root@DS1522:~# synoacltool -get /volume1/backup
ACL version: 1
Archive: has_ACL,is_support_ACL
Owner: [root(user)]
---------------------
         [0] system::allow:rwxp--aARWc--:fd-- (level:0)
         [1] user:ActiveBackup:allow:rwxpdDaARWc--:fd-- (level:0)
         [2] group:boxusers:allow:r-x---a-R-c--:fd-- (level:0)
         [3] group:boxadmins:allow:rwxpdDaARWc--:fd-- (level:0)
         [4] group:administrators:allow:rwxpdDaARWc--:fd-- (level:0)

Verzeichnisse mit zusätzlichen ACL-Rechten erkennt man an dem + hinter den Rechten. Wie du siehst läuft /volume1 im Linux-Mode, mit den ACLs geht es erst ab den Freigegebenen Ordnern los.

bei mir sieht das so aus:
ACL version: 1
Archive: is_inherit,has_ACL,is_support_ACL
Owner: [Klemens(user)]
---------------------
[0] group:b....:deny:rwxpdDaARWcCo:fd-- (level:0)
[1] group:http:deny:rwxpdDaARWcCo:fd-- (level:0)
[2] group:administrators:allow:rwxpdDaARWc--:fd-- (level:0)
[3] user:K....:allow:rwxpdDaARWc--:fd-- (level:0)
[4] group:f....:allow:r-x---a-R-c--:fd-- (level:0)
[5] user:K....:allow:rwxpdDaARWc--:fd-- (level:0)
[6] user:root:allow:rwxp-DaARWc--:fd-- (level:1)
[7] group:root:allow:r-x---a-R-c--:fd-- (level:1)
[8] everyone::allow:r-x---a-R-c--:fd-- (level:1)

Ungewöhnlich ist wohl der Owner "Klemens" und das "is_inherit".
Der Ordner "photo" ist der zweite, in den ich etwas mit rsync reingeschoben habe. Der sieht zwar in der Systemsteuerung und in der File Station normal aus, aber synoacltool sagt, er wäre im Linux mode udn der Owner ist ebenfalls "Klemens".
Ich vermute, bevor ich das mache, was Kollege NSFH empfohlen hat, sollte ich erstmal den Owner umschießen.
Aber erstmal ziehe ich mir die Grundlagen-Info rein.

 

[Benares]

"level:1" zeigt an, dass es vererbt wurde. Wie sieht /volume1 selbst aus?
Kann durchaus sein, dass dein "photo" noch nicht im Windows-ACL-Modus läuft, früher war das nicht der Standard. Schau mal, ob diese Option ausgegraut ist oder nicht.

 

[KSCHMID]

"photo" war nicht im ACL-Modus. Hab's geändert. Keine Ahnung, ob das vorher schon so war. Der NAS ist neu, aber die Bilder habe ich vom alten kopiert. Das war auch so ne Aktion...
Volume1 ist im Linux-Mode. kann/sollte ich die 3 level 1 Berechtigungen mit synoacltool rauswerfen? oder erstmal den owner umschießen? Nicht dass am Ende alles geschrottet ist.

 

[KSCHMID]

@KSCHMID: auch mal im Nutzerleitfaden unter Nr. 3 schauen, insbesondere die zwei Grundlagenvideo zu Nutzer und Berechtigungen.

Du „verknotest“ dich sonst wieder.

Danke. Die Videos waren jetzt nicht der große Bringer. Die haben zB nicht erklärt, warum die Berechtigungen für die freigeg. Order über die Systemsteuerung gemanagt werden und die Berechtigungen für die Ordner darunter über die File Station (historische Gründe??). Und die Konfusion wird ja dadurch komplett, dass die Berechtigung für die freigeg. Ordner auf beide Arten geändert werden kann.

 

[Benares]

Leg mal einen neuen Ordner z.B. "Klemens2" an und schau, wie es da mit den da Berechtigungen aussieht. Dann verschiebe die Inhalte von Klemens nach Klemens2 über die Filestation, das sollte schnell gehen, lösche Klemens und benenne Klemens2 um.

 

[*kw*]

Ich habe im Kapitel auch noch einen Absatz zur Herangehensweise der Rechte geschrieben. Das Prinzip des Rechte- und Rollenmanagements sieht halt vor, dass die logische Aufteilung auf der oberen Ebene stattfinden sollte und nicht "klein-klein" darunter. Da würde man sich auch mit Gruppenrichtlinien irgendwann verzetteln.

Dann lieber auf der obersten Ebene die Ordner so anlegen, dass die Unterverzeichnisse nur "Schubladen" und nicht wieder "Schließfächer" sind, für die man separate Schlüssel an die Nutzer verteilen muss.

Edit: Ich merke, dass es gerade am Anfang zu "Verwirrungen" kommt, weil mit dem Admin gearbeitet wird und nicht nur administriert wird. Der sieht natürlich mehr, als der user. Einfach mal den "Blickwinkel" ändern und danach strukturieren. Da erkennt man auch besser, wer was sehen können soll.

 

[Benares]

Das mit den "Erweiterten Berechtigungen" ist auch nicht ganz einfach zu verstehen. Ich hab mal ein wenig geforscht. Die "normalen" Berechtigungen sind wohl normale ACLs, die auf den Freigegeben Ordnern liegen und 1:1 nach unten vererbt werden, wenn ein Ordner im Windows-ACL-Modus läuft. Die "Erweiterten Berechtigungen" dagegen scheinen eher so ein App-/Samba-Gedöns zu sein, die woanders gespeichert werden, eher vergleichbar mit den NFS-Freigaben. Vielleicht weiß ja ein anderer dazu mehr, ich habe das nie genutzt.

 

[*kw*]

Unter dem Gesichtspunkt dieses Hinweises:



...sollte die Rechtevergabe so bodenständig als möglich umgesetzt werden, also nicht die Ausnahme zur Regel machen.