Unix permissions immer rwx

[gSynM24]

Hallo zusammen,

immer wenn ich eine Datei vom Mac auf das Synology-SMB-Share kopiere und wieder zurück (oder einfach den smb-Mount direkt anschaue), dann sind die Unix Dateirechte-RWX-Bits alle drei gesetzt. Ich verstehe ja, dass man hier gewisse Abstriche machen muss, da ja Quelle und Ziel nicht bzgl. Benutzern und Gruppen irgendwie synchronisiert sind usw. usf.

Aber das ganze passiert unabhängig von der Einstellung "SMB -> Advanced -> Others -> Apply Default Unix Permissions", die ja wie folgt wirken sollte:

Apply default UNIX permissions: Enable this option to apply the default UNIX permissions when uploading or creating files and folders. The UNIX permission will be 744 for files and 755 for folders. When this option is disabled, UNIX permission is 777 for files and folders.

Ich habe diesbezüglich mit und ohne ausprobiert und keinen Unterschied bemerkt - muss ich da erst irgendwas manuell neu starten, damit die Änderung wirksam wird?

Ich sehe es direkt auf der Synology (SSH login) immer so:

-rwxrwxrwx+ 1 NameSyn users 20 Mar 24 17:42 test.sh

Und dasselbe File sieht auf dem Mac im Mount immer so aus:

-rwx------@ 1 NameMac staff 20 24 Mär 17:42 test.sh

Aber selbst wenn diese Option wie beschrieben wirken würde, bliebe es ja in jedem Fall bei "rwxrw-rw-" (744).
Hauptsächlich stört mich das executable-Bit, das will ich nicht auf allen Dateien ungefragt gesetzt kriegen.

Wenn ich von einem Mac zum anderen direkt per SMB kopiere, passiert das alles übrigens nicht (natürlich wird user und group aufs Zielsystem angepasst, aber es kommt kein "x" ungefragt hinzu), also prinzipiell sollte das doch irgendwie gehen.

Gibt's da eine Lösung dafür? Konnte weder hier im Forum noch anderswo was finden

 

[Benares]

Das + hinter den Rechten zeigt an, dass der Freigegebene Ordner wohl im Windows-ACL-Modus läuft. Da werden die Rechte normalerweise vom Ordner aus allen Objekte darin und darunter nach unten vererbt. Das sieht man ganz schön, wenn man sich die Rechte mit Rechts-Klick, Eigenschaften, Berechtigungen in der Filestation anzeigen lässt. Die vererbten Rechte erscheinen dann graugetastet.

Auf der Konsole sieht man die ACLs mit "synoacltool -get /volume1/<Share>". Zeig mal was rauskommt.

 

[gSynM24]

Das sieht so aus:

synoacltool -get /volume5/homes/


ACL version: 1
Archive: has_ACL,is_support_ACL
Owner: [root(user)]
---------------------
[0] group:administrators:allow:rwxpdDaARWc--:fd-- (level:0)
[1] everyone::allow:--x----------:fd-- (level:0)
[2] owner::allow:rwxpdDaARWcCo:fd-- (level:0)

Und wie ich gerade gesehen habe, gibt es in der GUI pro Freigabe nochmal separat diese Option "Apply Default Unix Permissions" (derzeit disabled), die global beim SMB-Dienst gesetzt irgendwie gar nichts bewirkte. Vielleicht hat sie hier einen Einfluss, noch nicht probiert ... aber wie gesagt, ich will v.a. das x-Bit loswerden, was damit ja auch nicht passieren wird.

Was liest Du aus der synoacltool-Ausgabe heraus?

 

[Benares]

Ja, das passt für homes, aber dein Script wird ja wohl kaum dort liegen.
Das x-Recht für Everyone ist notwendig, um homes durchqueren zu können, um nach /homes/<User> (=/home) zu gelangen. Wenn dann dort irgendwelche Scripte liegen, erben die das wohl. An den Rechten dort solltest du auch nicht fummeln. Besser, du legst Scripte nicht gerade in den homes-Zweig, wenn du das nicht willst.

Mach besser einen eigenen Freigegeben Ordner "scripts" o.ä. für sowas. Ist zwar dann auch ACL, was wesentlich flexibler ist, aber du kannst Everyone dort weglassen.

 

[gSynM24]

Das Script war nur ein Test, wollte sehen, ob das wirklich durchs kopieren ausführbar wird (ja).

Als SW-Entwickler liegen bei mir leider naturgemäß überall Executables (mit X) und Quelltext (ohne X) gemischt im /home herum, und ich wollte evtl. auch git working directories im /home ablegen, die aber reagieren ohne besondere Massnahmen auch empfindlich auf falsche x-Bits. Von daher ist das leider keine Lösung.

Gibt es keinen Modus, bei dem einfach die Bits nicht angerührt werden? Der User darf gerne ersetzt werden, Gruppen sind auch ziemlich egal. So wie es auch bei Mac<->Mac per SMB von selbst passiert, oder auch, wenn ich einfach mit einem USB-Stick von Rechner zu Rechner gehe.

 

[Benares]

Bei ACL-Shares gelten Einstellungen wie "Apply Default Unix Permissions" usw. nicht, es wird einfach vererbt. Besser, du legst das einfach anderswo hin und kappst z.B. mit "chmod 744 /volumex/share" o.ä. die ACLs und die Vererbung. Mittlerweile ist ACL bei neuen Shares Standard - zum Glück.

 

[gSynM24]

Verstehe. Ja, das klappt so halbwegs:

synoacltool -get /volume5/TestNoACL
(synoacltool.c, 596)It's Linux mode

Und wenn ich in diesem "TestNoACL"-Share Dateien/Verzeichnisse erstelle, dann werden die lokal auf der Synology brav mit der "umask" (=077) erzeugt, also 600 bzw. 700. Und auch der Schalter "Apply Default Unix Permissions" im SMB-Dienst bewirkt genau, was beschrieben ist. (Und der zweite Schalter mit gleicher Bezeichnung in der File Station scheint sich nur generell auf eben mit der File Station direkt erstellte Ordner/Dateien zu beziehen, nicht auf einzelne Shares oder so.)
Soweit so gut - lokal gesehen!

Aber über SMB spielt das immer noch keine Rolle, Dateien haben immer noch "700" aus Sicht des Macs, der das Share mounted. Auch wenn sie lokal "600" haben. Irgendeine Kleinigkeit fehlt hier noch, lokal stimmt's, aber remote noch nicht.

 

[Benares]

Spiel mal weiter damit rum und berichte.

 

[gSynM24]

Leider gehen mir langsam die Ideen aus.

Ich kann das Problem Mac-seitig nur "verschlimmern", indem ich manuell per Kommandozeile smb_mount benutze und dabei die Datei/Ordner Permissions vorgebe - aber nicht verbessern: wenn ich also nichts vorgebe, dann bleiben die x-Bits gesetzt. Zwangsweise löschen könnte ich sie wohl, aber ich will sie ja unverändert erhalten.

Es kommt also wohl schon so vom SMB-share. In der /etc/samba/smb.share.conf findet sich dieser Eintrag:
skip smb perm=yes
Das klingt interessant, aber ich finde nichts dazu an Dokumentation. Eine proprietäre Erweiterung von Synology? In der GUI finde ich nichts, das damit verknüpft zu sein scheint, und es einfach in der Datei mal zu ändern, habe ich noch nicht probiert (wird wahrscheinlich eh wieder zurückgesetzt).

Auf Reddit habe ich mittlerweile einige Jahre alte Threads zu dem Thema gefunden, die aber alle leider ergebnislos versandet sind.

 

[Benares]

Du kannst doch über die Filestation die Rechte-Vererbung an jeder beliebigen Stelle kappen (Übernommene Berechtigungen ausdrücklich machen), ändern, und wieder nach unten vererben. Lass aber bitte /homes und /homes/<Benutzer> selbst in Ruhe.

 

[gSynM24]

Alle Tests mache ich (erstmal) natürlich außerhalb von /homes. Aber was meinst Du mit Vererbung kappen?
Die Vererbung (die auf neue Dateien angewendet wird) ist ja nicht das Problem. Auch Dateien, die ich lokal mit Berechtigungen nach Wunsch erzeuge, sind extern immer RWX. Das was da ist, wird einfach nicht nach außen so weitergeleitet.

 

[Benares]

Schau es dir mal über die Filestation an, ausgehend von einem "Freigegebenen Ordner", dann hangle dich runter. Du wirst sehen, dass auf den Ebenen darunter dir Rechte graugetastet (=vererbt) erscheinen. Mit "Übernommene Berechtigungen ausdrücklich machen" kannst die bisher vererbten Rechte als lokale Rechte übernehmen (=Vererbung kappen), was daran ändern, und ab dieser Stelle wieder weiter nach unten vererben (Auf diesen Ordner, die Unterordner und Dateien anwenden).

 

[gSynM24]

Ja, soweit hatte ich das mit der Vererbung schon verstanden und es funktioniert auch - bewirkt aber alles nichts "nach außen", d.h. die Dateien in dem auf dem Mac gemounteten Share sind immer RWX, egal ob geerbte oder explizite, ACL- oder Unix-Rechte. Die Rechte-Unterschiede sehe ich nur auf der FileStation und in der SSH-Konsole.

Daher denke ich, es liegt an der SMB-Konfiguration. Ein "skip smb perm=no" bewirkt leider auch nichts nützliches (das share ist dann gar nicht mehr sichtbar). Hat wohl irgendeine andere undokumentierte Bedeutung.

Mal andersrum nachgeforscht, in der SAMBA-Dokumentation findet sich:

cifs UNIX Extensions
unix extensions = yes
Dieser Parameter ermöglicht es, mittels cifs-vfs oder smbclient auch auf dem Client die Original Dateirechte und Zeitstempel des Servers zu sehen, zu verwenden und ggf. auch zu verändern. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions (z.B. verschiedene UID und GID für gleiche Benutzer auf Server und Client) deaktiviert werden.

Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Ob diese Extensions auf dem Synology wohl aktiv sind? Oder aktivierbar? Unter /etc/samba/*.conf ist nichts zu finden, weder yes noch no, und default ist noch obigem eigentlich yes.

 

[Hagen2000]

Die unix extensions gibt es m.W. nur für SMBv1. Neuere SMB-Protokolle verwenden die Posix extensions.

 

[Benares]

Zur Umsetzung der Linux-Rechte auf den MAC kann ich dir wenig sagen - bin kein Apple-Jünger. Aber SMB (=CIFS) und NFS solltest du strikt trennen. Das sind total unterschiedliche Methoden/Vorgehensweisen.

 

[gSynM24]

Mit NFS wollte ich eigentlich auch gar nichts erst anfangen. SMB ist ja seit einiger Zeit auch auf Macs der offizielle Standard - hat sogar AFP verdrängt. Und mit SMB von Mac2Mac klappt das ja auch ohne weiteres mit den Permissions.
AFP wäre vielleicht sogar noch ein Ausweg, das gibt's ja auch auf der DS. Aber mit fraglicher Performance seitens des Protokolls(?). Noch nicht probiert, wollte eigentlich ohne das auskommen. [Edit: geht auf meinen Macs gar nicht mehr, also kein Workaround]

Unix vs. Posix extensions, SMB=1 vs SMB>1: danke für den Hinweis. Da blicke ich in der Samba-Doku nicht so ganz durch, ob oder was man da aktivieren müsste (wenn's Synology überhaupt zuließe?), bzw. umgekehrt, ob Synology da explizit was deaktiviert hat, was normalerweise aktiv ist... keine Ahnung.

 

[Benares]

Hör mir auf mit SMB1, das braucht kein Mensch mehr.

 

[gSynM24]

Das bezog sich ja nur auf den Hinweis, dass ich in der Samba-Doku wohl versehentlich bei v1 gelandet war. Unbeabsichtigt. Will sicherlich niemand.

 

[gSynM24]

Ich habe deswegen jetzt mal ein Ticket bei Synology aufgemacht. Mal sehen, ob's was bringt - und sei es nur eine klare Antwort im Sinne von "es geht definitiv nicht anders".

In dem Fall müsste ich mein Nutzungsszenario für den /home-Teil anpassen, da also nur Dateien ablegen, für die das alles egal ist. Ein Workaround wäre noch, da ein Disk-Image reinzulegen und auf dem Mac nur damit zu arbeiten. Dann sind alle Metadaten garantiert unverändert.
Aber das beißt sich dann wieder mit dem Home-Backup-Konzept (v.a. beim Restore: man müsste das komplette Disk-Image zurücksetzen, um eine einzelne Datei aus dem Backup zurückzuholen ... unschön!).