DSM 4.3 » 5.2: Unix-Rechte und alles neu?

Status
Für weitere Antworten geschlossen.

killerbees19

Benutzer
Mitglied seit
26. Jun 2010
Beiträge
158
Punkte für Reaktionen
2
Punkte
22
Meine DS freut sich nun auch endlich über DSM 5.2, vorher lief noch 4.3! Ich habe das ganze nach 4 Jahren gleich einmal mit einer sauberen Neuinstallation verbunden, bei der ich auch die Raid-Konfiguration aufgelöst habe, um es dieses Mal besser zu machen. Mein selbst erstelltes Backup spiele ich gerade manuell mit rsync zurück, bis auf die Photo Station, das überließ ich dem DSM. Soviel zur Vorgeschichte.

Was mir in der aktuellen Version noch nicht ganz klar ist, sind die Berechtigungen für Ordner/Dateien. Offenbar hat Synology sich endlich vom 0777-Murks verabschiedet. Bei Ordnern war das nicht so ein Drama, aber für Dateien fand ich das immer mehr als unpassend. Je nach Zustand der diversen "Standard Unix-Berechtigungen verwenden" Konfigurationen sind die Standardrechte jetzt endlich bei 0755/0777 für Ordner und 0644/0666 für Dateien. So weit, so gut – sagt zumindestens die Hilfe.

Ich habe vorhin über die File Station einen Ordner und eine Datei angelegt/hochgeladen. Was mich dabei etwas verwundert, sind die Berechtigungen, die ich über SSH sehe:
Rich (BBCode):
39321603    4 d---------    2 admin    users       4.0K Jun  9 11:15 .
11544221    4 d---------    4 root     root        4.0K Jun  9 11:09 ..
39321606  100 ----------    1 admin    users      96.5K Jun  8 14:52 test.pdf
39583746   64 ----------    1 admin    users      61.7K Jun  7 11:19 test.png
---------- würde ich jetzt mal mit "chmod 0" gleichsetzen.

Läuft das jetzt alles über ACLs oder wie darf ich mir das vorstellen? Oder ist die Ausgabe vom eingebauten ls falsch? Kann da irgendjemand Licht ins Dunkel bringen, wie Synology das in DSM 5.x umgesetzt hat, weil ich blicke da nicht ganz durch.


MfG Christian
 

killerbees19

Benutzer
Mitglied seit
26. Jun 2010
Beiträge
158
Punkte für Reaktionen
2
Punkte
22
Ich darf mir meine Frage teilweise selbst beantworten: https://help.synology.com/dsm/?section=DSM&version=5.2&link=AdminCenter/file_share_privilege.html

Bei DSM 5.0 oder höheren Versionen basieren die Zugriffsrechte der gemeinsamen Ordner standardmäßig auf Windows ACL. Neu erstellte, gemeinsame Ordner implementieren die Berechtigungseinstellungen von Windows ACL, in dem auch die Zugriffsrechte auf einzelnen Dateien und Unterordner angepasst werden können.

Und ich darf ergänzen: Auch home/homes verwendet ACL noch nicht, was logisch erscheint.

Eines verstehe ich allerdings trotzdem nicht ganz: Wie kann ich die Rechte dann über FTP/NFS verwalten, damit sie auch wirklich zum Tragen kommen?

Die Erklärung zu den diversen "Standard-UNIX-Berechtigungen anwenden" Optionen helfen da nicht viel weiter: https://help.synology.com/dsm/?section=DSM&version=5.2&link=AdminCenter/file_ftp_general.html

Führen Sie für freigegebene Ordner, für die Windows ACL aktiviert ist, den Befehl chmod auf Ihrem Linux- oder FTP-Client aus, um die Ordner- und Dateiberechtigungstypen von Windows ACL auf UNIX umzustellen.

Echt jetzt, das soll funktionieren? Irgendwie wirkt das so, als ob dabei Inkonsistenzen der Rechte vorprogrammiert sind! Wird darunter auch kurz erwähnt.

Ich bin ja prinzipiell kein Verweigerer von ACL, aber sie machen alles oftmals komplizierter, als es notwendig wäre. Der Unix-Gedanke von Besitzer/Gruppe/Rest kam mir da deutlich entgegen. Dem Fortschritt kann man sich aber kaum verschließen… :rolleyes:


MfG Christian
 

dil88

Benutzer
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
31.056
Punkte für Reaktionen
2.560
Punkte
829
Ich ergänze einmal ein paar Anführungsstriche: "Fortschritt". ACL ist für bestimmte Szenarien sicherlich gut und sinnvoll, für mich persönlich ist es ein Rückschritt.
 

killerbees19

Benutzer
Mitglied seit
26. Jun 2010
Beiträge
158
Punkte für Reaktionen
2
Punkte
22
Interessant wäre ja, ob man ACL irgendwie wieder deaktivieren kann. Bei synoshare und synoacltool habe ich zumindestens keine Möglichkeit gefunden. Einfach um'chmod'en bringt auch nichts, weil die Info, ob ACL beim Share genutzt wird, irgendwo in der DB oder sonst wo steckt.

Lustigerweise ist ACL bei wiederhergestellten Ordnern (die automatische Funktion beim Booten) aber automatisch deaktiviert! Irgendwie muss ein Share also doch ohne ACL angelegt/geändert werden können. Ich könnte wetten, dass es da einen undokumentierten Schalter gibt. Ich werde nachher einmal weiter forschen… :D


MfG Christian
 

killerbees19

Benutzer
Mitglied seit
26. Jun 2010
Beiträge
158
Punkte für Reaktionen
2
Punkte
22
Nach diversen Tests und dem Nachforschen was/wo/wie passiert, bin ich ein wenig schlauer. Vorerst einmal nur die Kurzfassung: Die Hardcore-Methode zum Deaktivieren von ACL ist das Löschen des gemeinsamen Ordnern (aber nicht der Daten) mit synoshare, wobei alle Zugriffsrechte und sonstigen Einstellungen davon gelöscht werden! Danach muss man alle enthaltenen Ordner/Dateien mittels chmod und/oder synoacltool berühren, man muss dabei aber einige Sonderfälle der @eaDir's beachten. Jetzt kann mit synocheckshare die automatische Wiederherstellung (wie sie normalerweise beim Boot erfolgt) angestoßen werden. Das Resultat ist ein jungfräulicher gemeinsamer Ordner ohne ACL mit den alten Dateien.

Ich versuche das gerade in einem Script unterzubringen, damit man das eventuell komfortabler ausführen kann. Mal sehen, ob es etwas wird. Ich melde mich wieder… :)


MfG Christian

PS: Offenbar kann nur libsynoshare (u.a. über synocheckshare) einen gemeinsamen Ordner ohne ACL gefahrlos in der /usr/syno/etc/synoshare.db anlegen. Direkte Befehle für die Konsole gibt es dafür nicht. Von daher bleibt wohl nur die Hardcore-Methode von oben.
 

dil88

Benutzer
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
31.056
Punkte für Reaktionen
2.560
Punkte
829
Astrein, vielen Dank für Deine Mühe und den Bericht!
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat