macOS Sonoma: Berechtigungs-/Zugriffsprobleme auf SMB/Samba-Freigabe

[Tratschwelle]

Hallo,

ich habe ein Problem mit den Datei-/Ordnerberechtigungen bei einer SMB-Freigabe.

Zum System: Das MacBook Air M1 läuft unter macOS 14.1 (23B74), die SMB-Freigabe liegt auf einem Raspberry Pi OS 11 Bullseye (aktuelle Version 64-bit), auf diesem läuft openmediavault 6.9.4-2 (Shaitan).

Kopiere ich eine Datei per Finder auf die SMB-Freigabe, gibt es keine Probleme. Sobald ich aber einen Ordner mit Inhalt per Finder auf die SMB-Freigabe kopiere, erhalte ich sofort eine Fehlermeldung "fehlende Berechtigungen". Ich kann dann unter macos Sonoma weder in den Ordner wechseln noch diesen löschen, auch nicht per cli (inkl. sudo): Zugriff verweigert mangels Berechtigung. Auch der Zugriff von anderen Linux-Clients auf diesen Ordner scheitert.

Setze ich die Berechtigungen der SMB-Freigabe auf dem Raspberry Pi OS rekursive zurück, klappt dann der (Voll)Zugriff wieder, bis ein nächster Ordner unter macOS Sonoma kopiert werden soll.

Der Zugriff auf die SMB-Freigabe klappt hingegen von anderen Linux-Clients grundsätzlich OHNE Berechtigungsprobleme und da mir das Problem erst gerade aufgefallen ist, die SMB-Freigabe aber schon seit Monaten besteht, gehe ich davon aus, dass das ein problem seit macOS Sonoma (oder dem letzten Update) ist.

Mein Workaround ist, Berechtigungen der Freigabe auf dem Raspberry Pi OS Host zu vererben. Diese Option brauchte ich bisher nicht.

Die Option setzte ich per openmediavault GUI, dort heißt es in der Bescheibung:

"Berechtigungen erben
Die Zugriffsrechte neuer Dateien und Verzeichnisse sind normalerweise durch die Create- und Directory-Maske geregelt, aber der Parameter Berechtigungen erben überschreibt dies. Das kann besonders auf Systemen mit vielen Benutzern nützlich sein um eine einzelne Freigabe flexibel von jedem Benutzer benutzbar zu machen."

Die GUI setzt entsprechend den Parameter unter

/etc/samba/smb.conf

[SMB-SHARE]
inherit permissions = yes

Kann jmd. das Problem bestätigen bzw. ist das schon bekannt und meine Internetsuche verlief bisher lediglich erfolglos?

 

[MrChad]

Interessant in diesem Zusammenhang wären die POSIX-Berechtigungen der Dateien und Ordner auf dem Raspi (!!) :

1. Alte Datei/alter Ordner, die schon länger da rumliegen
2. Neue Datei/neuer Ordner vor der inherit-Änderung
3. Neueste Datei/neuester Ordner nach der Änderung

jeweils gelistet mit

ls -nl DATEI.TXT

ls -ndl ORDNER

 

[lisanet]

Du musst in omv sicherstellen, dass jedes share auch vfs_fruit nutzt. Leider ist (war?) das bei omv nicht der Fall, sondern nur beim TimeMachine Share. Zudem bietet es sich an und es ist teilweise notwendig um eine hohe Kompatibilität zu macOS zu erhalten, eineige andere setting in der /etc/samba/smb.conf zu setzen. Leider erlaubt omv das nicht durchgend in der GUI.

Ich gehe auch davon aus, dass du die Rechte bei "Users" und "Shared Folders" korrekt gesetz hast.

Für den Server, also in der [global] section von /etc/samba/smb.conf setze auf jeden Fall mindestens (fruit:aapl = yes wird gesetz, wenn du ein TimeMachine-Share verwendest, andernfalls musst du es manuell setzen)

fruit:aapl = yes
fruit:nfs_aces = yes

Für jedes Share setze dann auch:

inherit acls = yes
inherit permissions = yes
ea support = yes
vfs objects = catia fruit streams_xattr
fruit:encoding = private
fruit:metadata = stream
fruit:resource = xattr

Für den Server bietet sich zusätzlich an:

fruit:locking = none
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes

 

[Tratschwelle]

Interessant in diesem Zusammenhang wären die POSIX-Berechtigungen der Dateien und Ordner auf dem Raspi (!!) :

1. Alte Datei/alter Ordner, die schon länger da rumliegen
2. Neue Datei/neuer Ordner vor der inherit-Änderung
3. Neueste Datei/neuester Ordner nach der Änderung

jeweils gelistet mit

ls -nl DATEI.TXT

ls -ndl ORDNER

Hab mal auf dem Raspi/OMV eine neu SMB-Freigabe sowie einen lokalen Benutzer angelegt.
SMB-SHARE = Freigabe
smbshare = lokaler Benutzer

Dann eine Datei/Ordner per ssh auf dem Raspi direkt sowie eine Datei/Ordner von einem Linux-Client per smb://… Freigabezugriff.

1. "alte" Datei/Ordner, die (schon) auf der Freigabe liegen

$ ls -nl DATEI1_rpihost
-rw-rw-rw-+ 1 1000 100 5 Oct 30 16:03 DATEI1_rpihost

$ ls -ndl ORDNER1_rpihost/
drwxrwsrwx+ 1 1000 100 0 Oct 30 16:10 ORDNER1_rpihost/

$ ls -nl DATEI1_linuxclient.txt
-rw-rwxr--+ 1 1002 100 5 Oct 30 16:02 DATEI1_linuxclient.txt

$ ls -ndl ORDNER1_linuxclient/
drwxrwsr-x+ 1 1002 100 0 Oct 30 16:02 ORDNER1_linuxclient/

2. neue Datei/Ordner vor der Inherit-Änderung (vom MacBook Air M1 per Finder)

$ ls -ndl Ordner_NEU_mba/
drw-rwsr-x+ 1 1002 100 0 Oct 30 16:28 Ordner_NEU_mba/

$ ls -nl Datei_NEU_mba.txt
-rw-rwxr--+ 1 1002 100 4 Oct 30 16:27 Datei_NEU_mba.txt

Anmerkung: Es kam KEINE Fehlermeldung beim Kopieren des Ordners (leer) und der Datei. Die Datei lässt sich löschen, der Ordner nicht, hier kommt dann die Fehlermeldung "nicht erforderliche Zugriffsrechte".

Kopiere ich einen weiteren Ordner, der aber nicht leer ist, sondern eine Datei enthält, erhalte ich die Fehlermeldung "nicht erforderliche Zugriffsrechte" direkt.

$ ls -ndl Ordner_NEU1_mba/
drw-rwsr-x+ 1 1002 100 0 Oct 30 17:03 Ordner_NEU1_mba/

3. neueste Datei/Ordner mit Aktivierung der Vererbung (Inherit per OMV GUI)

$ ls -nl Datei_NEUESTE_mba.txt
-rwxrw-rw-+ 1 1002 100 4 Oct 30 16:27 Datei_NEUESTE_mba.txt

$ ls -ndl Ordner_NEUESTE_mba/
drwxrwsrwx+ 1 1002 100 18 Oct 30 17:15 Ordner_NEUESTE_mba/

Ordner mit Inhalt

$ ls -ndl Ordner_NEUESTE1_mba/
drwxrwsrwx+ 1 1002 100 62 Oct 30 17:16 Ordner_NEUESTE1_mba/

 

[Tratschwelle]

Du musst in omv sicherstellen, dass jedes share auch vfs_fruit nutzt. Leider ist (war?) das bei omv nicht der Fall, sondern nur beim TimeMachine Share. Zudem bietet es sich an und es ist teilweise notwendig um eine hohe Kompatibilität zu macOS zu erhalten, eineige andere setting in der /etc/samba/smb.conf zu setzen. Leider erlaubt omv das nicht durchgend in der GUI.

Ich gehe auch davon aus, dass du die Rechte bei "Users" und "Shared Folders" korrekt gesetz hast.

Für den Server, also in der [global] section von /etc/samba/smb.conf setze auf jeden Fall mindestens (fruit:aapl = yes wird gesetz, wenn du ein TimeMachine-Share verwendest, andernfalls musst du es manuell setzen)

fruit:aapl = yes
fruit:nfs_aces = yes

Für jedes Share setze dann auch:

inherit acls = yes
inherit permissions = yes
ea support = yes
vfs objects = catia fruit streams_xattr
fruit:encoding = private
fruit:metadata = stream
fruit:resource = xattr

Für den Server bietet sich zusätzlich an:

fruit:locking = none
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes

Ich hab mir mal die vfs_fruit Parameter meiner

$ cat /etc/samba/smb.conf

angeguckt:

[global]
# Special configuration for Apple's Time Machine
fruit:aapl = yes
fruit:copyfile = yes
fruit:nfs_aces = no

Der Teil dürfte in der Tat von der SMB-Freigabe für Time Machine stammen.

Der relevante vfs_fruit bzw. Berechtigungsvererbungs-Teil meiner neuen Test SMB-Freigabe:

[SMB-SHARE]
inherit acls = no
inherit permissions = yes

vfs objects =  fruit streams_xattr btrfs shadow_copy2

Mit diesen Parametern klappt der Zugriff ohne offensichtliche Probleme…

Wie kann ich nun eigentlich sicher sein, dass Time Machine zuverlässig läuft, ist ja schließlich auch eine SMB-Freigabe und dort ist

[TimeMachine]
inherit acls = no
inherit permissions = no

fruit:encoding = private
fruit:locking = none
fruit:metadata = stream
fruit:resource = file
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
fruit:time machine = yes

 

[MrChad]

Hab mal auf dem Raspi/OMV eine neu SMB-Freigabe sowie einen lokalen Benutzer angelegt.

Danke für die Listings, die zeigen (in etwa) das erwartete Ergebnis.

Ich habe allerdings gesehen, dass sich die vollständige Geschichte hinter den +-Zeichen (in den sog. ACLs) versteckt. Das hatte ich so nicht auf dem Schirm und kann es jetzt auch nicht mehr verbessern. Sorry dafür.

----

ACL = Access Control List
Auf dem Raspi ist das ein zusätzliches Feature, was anscheinend bei OpenMediaVault mit installiert worden ist.

ACLs sind ein System von Berechtigungseinstellungen, mit dem die Systeme genauer als mit POSIX-Rechten nachhalten können, wer was genau darf. Wenn es auf dem Raspi genauso funktioniert wie auf anderen Systemen, dann ist das sehr sinnvoll, aber kompliziert.

Auch das inherit ist sehr sinnvoll und sorgt dafür, dass ACLs (= Rechte) von Ordnern auf die enthaltenen Dateien übertragen werden.

----

(Geraten) nehme ich jetzt mal an, dass die alte Version des MacOS beim Kopieren mit den SMB-Befehlen bisher vollständige ACL-Einstellungen (inkl. des inherit) mitgeschickt hat und dass sich in der neuen Version da etwas geändert hat.

Leider kann ich mit der vorliegenden Info nix konkreteres mehr sagen.

----

Langer Rede, kurzer Sinn:

Halte dich an die Empfehlung von @lisanet. Das ist die hiesige Expertin für Raspis und OpenMediaVault.

In den codierten Empfehlungen stehen im Wesentlichen zwei Dinge drin

• Schalte inherit für permissions und ACLs an. Das sollte deine Probleme mit Zugriffsrechten fixen.
• Schalte fruit für alle Shares an. Das sollte die SMB-Performance optimal einstellen.

Beides kann ich nur für sehr sinnvoll halten.

 

[lisanet]

fruit:nfs_aces = no

Das ist die Wurzel deines Problems. macOS erfordert, dass das auf yes gesetzt wird. Nur so kann macOS die Zugriffsrechte des Ordners so setzen, dass macOS auch Dateien darin speichern können.

Ich habe dieses Thema wochenlang analysisert mit den verschiedensten Kombinationen zu POSIX Rechten ACL, Vererbung etc. Ergebnis: für macOS setze es auf yes.

vfs objects = fruit streams_xattr btrfs shadow_copy2

Da fehtl catia. Und zwar vor fruit. Das sagt auch die Doku zu vfs_fruit so aus.

Und, ganz wichtig: Setze die fruit Eingenschaften, die ich oben beschrieben habe je share. Wenn du das nicht tust, dann hat das vfs object streams_xattr überhaupt keinen Effekt für das share, da die default Werte in Samba sonst AFP-kompatible xattr und metadata verwenden.

Also je share mindestens

fruit:metadata = stream
fruit:resource = xattr

Edit:

falsches copy&paste korrigiert: richti ist xattr, nicht file. (offnesichtlich setz omv mittlerweile auch TimeMachine auf file.... so ein Mist.

Also: ändere auch den Eintrag zum TimeMachine-Share entsprechend

 

[Tratschwelle]

Erstmal 1000 Danke an euch alle, @lisanet und @MrChad!

Muss das Feedback erstmal etwas sacken lassen um zu verstehen und nachvollziehen zu können. Man wächst mit seinen Aufgaben und es zeigt mir nur, dass ich mit meinen Ambitionen, mich mehr mit dem ganzen Unterbau von Linux, CLI usw. zu beschäftigungen, nicht so falsch liege. Es sind immer wieder Puzzleteile und hier und dort entsteht bei mir auch eine neue Erkenntnis.

Danke dafür, auch an alle anderen, die ich jetzt hier nicht explizit erwähne.

@lisanet Mir ist nur nicht so ganz klar, wann ich einzelne Parameter pro SMB share bzw. bei den allg. SMB Einstellungen bei den Erweiterten Optionen hinzufügen muss oder nicht.

fruit:nfs_aces = no

was lt. deiner Empfehlung

fruit:nfs_aces = yes

sein sollte, ist ja von OMV in den [global] Einstellungen erfolgt, nachdem ich (wahrscheinlich) eine SMB Freigabe für Time Machine eingerichtet habe. Was gewichtet denn höher? Eine globale Einstellung oder die des einzelnen Share?

Ein MUST NOT ist auf jeden Fall eine Änderung in der

/etc/samba/smb.conf

per CLI…

Mal konkret gefragt: Wo bzw. wie ändere ich

fruit:nfs_aces = yes

?

 

[lisanet]

habe ich doch oben geschrieben, was in global = Server gehört und was je share.

In OMV kannst du zumindest das in der GUI in den extra options beim Server und bei den shares eingeben. Oder per setzen der entsprechenden Umgebungsvariablen.

Einen Einstieg dazu bietet mein Blog. Die Artikelserie ist aber noch nicht fertig, da nun die Dinge mit patchen von omv source codes beginnen würde. Das wird dann alles andere als Einsteiger-tauglich werden.

https://lisanet.de/tweaks-fuer-openmediavault-6/

Wo was stehen muss und wie das zusammen spielt -> lies die Doku zu vfs_fruit -> https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html

 

[jteschner]

Ich habe mal eine "Unwissenden-Frage". Ich hatte das gleiche Problem wie der TE (siehe #1).
Gelöst habe ich das durch einschalten der Berechtigungsvererbung + ACL in der OMV-GUI bei Server und Freigaben.
Auch hatte ich aus lisanets Blog den Artikel zu samba/macos umgesetzt.

Nun hatte ich oben gelesen, dass u.a
fruit:nfs_aces = yes
gesetzt sein sollte. Ein Blick in meine /etc/samba/smb.conf zeigt, dass das auch bei mir auf "no" steht.
Auch steht dort ganz oben in smb.conf, dass diese nicht geändert werden sollte, da omv diese "bearbeitet" und manuelle Einträge überschrieben werden.
Wenn ich fruit:nfs_aces = yes über die Gui eintrage, dann wird ein zusätzlicher Eintrag in der smb.conf von omv vorgenommen, so dass es dort dann zwei Einträge in der Global section gibt:

....
fruit:nfs_aces = no
# Extra options
fruit:metadata = stream
fruit:nfs_aces = yes
...

Ich bin nun verwirrt (aus Unwissenheit, denke ich), denn: Was gilt denn nun?? yes oder no?
Darf ich nun die smb.conf ändern oder besser nicht?
Oder wirklich besser die Einträge über die Gui machen für Server und jeder der einzelnen Freigaben?

Seht es mir nach - aber ich fange gerade erst an mich damit zu beschäftigen und möchte natürlich keinen Fehler machen.

 

[Tratschwelle]

Ich habe mal eine "Unwissenden-Frage". Ich hatte das gleiche Problem wie der TE (siehe #1).
Gelöst habe ich das durch einschalten der Berechtigungsvererbung + ACL in der OMV-GUI bei Server und Freigaben.
Auch hatte ich aus lisanets Blog den Artikel zu samba/macos umgesetzt.

Nun hatte ich oben gelesen, dass u.a
fruit:nfs_aces = yes
gesetzt sein sollte. Ein Blick in meine /etc/samba/smb.conf zeigt, dass das auch bei mir auf "no" steht.
Auch steht dort ganz oben in smb.conf, dass diese nicht geändert werden sollte, da omv diese "bearbeitet" und manuelle Einträge überschrieben werden.
Wenn ich fruit:nfs_aces = yes über die Gui eintrage, dann wird ein zusätzlicher Eintrag in der smb.conf von omv vorgenommen, so dass es dort dann zwei Einträge in der Global section gibt:

....
fruit:nfs_aces = no
# Extra options
fruit:metadata = stream
fruit:nfs_aces = yes
...

Ich bin nun verwirrt (aus Unwissenheit, denke ich), denn: Was gilt denn nun?? yes oder no?
Darf ich nun die smb.conf ändern oder besser nicht?
Oder wirklich besser die Einträge über die Gui machen für Server und jeder der einzelnen Freigaben?

Seht es mir nach - aber ich fange gerade erst an mich damit zu beschäftigen und möchte natürlich keinen Fehler machen.

Dito. Es steht explizit in den Kommentaren, dass keine manuelle Anpassung in der

/etc/samba/smb.conf

gemacht werden soll. Davon ab habe ich das gleiche Ergebnis nach Hinzufügen von

fruit:nfs_aces = yes

als erweiterte Option unter den globalen SMB Einstellungen,
in der

/etc/samba/smb.conf

steht dann

fruit:nfs_aces = no

sowie

fruit:nfs_aces = yes

in der

/etc/samba/smb.conf

bringen tut das ganze aber bei mir nichts.

Ich muss explizit die Option "Berechtigungen vererben" per GUI aktivieren und erhalte dann

inherit permissions = yes

in der

/etc/samba/smb.conf

und ich habe damit keine Zugriffsprobleme mehr.

 

[lisanet]

Ich bin nun verwirrt (aus Unwissenheit, denke ich), denn: Was gilt denn nun?? yes oder no?
Darf ich nun die smb.conf ändern oder besser nicht?
Oder wirklich besser die Einträge über die Gui machen für Server und jeder der einzelnen Freigaben?

ich habe doch oben geschrieben, dass die GUI nicht alles ermöglicht und dass Einstellungen möglich und sinnvoll sind für einen Mac, die es sogar erfordern, die sourcen zu patchen. Und in meinem blog sind auch Dinge beschrieben, die über die GUI hinaus gehen.

Wenn du wissen willst welche Einstellungen gelten,logge dich per ssh auf dem NAS ein und gib ein

testparm

Du musst nochmals RETURN drücken, wenn du aufgefordert wirst. Dann siehst du die Einstellungen, die du in der smb.conf gesetzt hast und die effektiv verwendet werden.

Wenn ihr mit mit nfs_aces nicht glaubt, dann lest doch mal die Doku zu vfs_fruit. Das ist das Modul, dass die Kompatibilität zum Mac herstellt. Dort ist erwähnt, dass nfs_aces standarmäßig auf yes steht. Warum wohl?

Testet es einfach, was die Folgen sind:

a= stellt auf no

nehmt eine Dokuemten-Datei, also z.B. eine Datei von TextEdit) auf dem Mac und seht euch dort die Rechte in Terminal an. Das macht ma mit

ls -l

Sofern ihr am Mac nicht herum gebastelt habt, sind die Rechte -rw-r--r--. Das bedeutet, ihr könnt die Datei lesen ® und beschreiben/ändern (w), die Gruppe kann nur lesen, alle anderen auch lesen. So wie es sein sollte.

Kopiert diese aufs NAS. Dann kopeiert ihr diese vom NAS wieder zurück auf den Mac und seht euch die Rechte erneut an: Sie sind nun -rwx------.

Das heißt, dass nun auf einmal die Datei als ausfürhbar gekennzeichnet ist, und weder die Gruppe noch alle anderen die Datei überhaupt mehr lesen können. Eure Samba-Server verändert also die Rechte.

b) setzt es auf yes

und die rechte bleiben unverändert, wie sie auf dem MAc ursprünglich waren.

Was ist euch lieber? Was findet ihr korrekt?

 

[lisanet]

bringen tut das ganze aber bei mir nichts.

ich habe ja auch oben deutlich mehr geschrieben, was zu ändern ist und nicht nur 1 Eintrag. Zudem habe ich oben vorausgesetzt, dass du die Rechte korrekt in den Einstellungen gesetzt hast. Auch hast du ja schon beschrieben, dass du die Vererbung aktiviert hast.

Dennoch, sorry, das ich hier angefangen habe, Hilfe zu Samba zu geben.

Samba ist sehr komplex und im Grunde nicht für Einsteiger geeignet. OMV ist sehr Linux und Windows zentriert eingestellt. Das merkt man nicht nur daran, dass einige Mac-spezifischen Dinge nicht so recht passen, sondern u.a. auch daran, dass OMV Dinge so einstellt, dass sie über eine GUI nicht verändert werden können. Ein ganz banales Beispiel: Der Name des NAS wird immer und ausschließlich in Kleinbuchstaben dargestellt. Es wird auch immer "SMB/CIFS" angehängt, was ebenso vollkommen untypisch für den Mac ist. Oder: Das Spindown von manchen Festplatten wird einfach ausgeschalten, egal was man einstellt. Bei TimeMachine werden AFP relevante metadata und streams verwendet, obwohl die Freigabe via SMB erfolgt.

Das alles erfordert dann etwas mehr als die GUI, bis hin zum patchen der sourcen.

Sollte das mit den 2 nfs_aces einträgen und der Kontrolle via testparm nicht zum gewünschten Ergebnis (yes) fürhen, muss man halt leider mehr machen.

Ich hatte hier versucht, schnelle Hilfe zu geben. wenn ich damit euch verwirrt habe, sorry. Bitte versteht aber auch mich, dass ich nicht parallel zur Lösung auch noch ellenlange Begründungen und Erklärungen zu Samba schreiben kann und auch noch Hilfe zum Umgang mit Terminal und patchen. Das Thema Samba + OMV ist nichts für Einsteiger oder einfache Postings in einem Forum. Und och werde definitiv kein HowTo zu Samba schreiben.

Also, wenn es für euch passt, gut. Wenn nicht, lest euch bitte etwas in Samba ein, besonders in vfs_fruit und lest mein blog.

 

[jteschner]

ich habe doch oben geschrieben, dass die GUI nicht alles ermöglicht und dass Einstellungen möglich und sinnvoll sind für einen Mac, die es sogar erfordern, die sourcen zu patchen. Und in meinem blog sind auch Dinge beschrieben, die über die GUI hinaus gehen.

Danke für deine Geduld! Also ich zumindest erwarte von dir auch kein HowTo zu Samba! Ganz bestimmt nicht ...
Du sprichst vielleicht, bedingt durch dein extensives Wissen, zT eine etwas andere Sprache als ein "Anfänger".
Wenn du von "patchen" sprichst, meinst du das manuelle editieren über Terminal der smb.conf, richtig? Ein ja, nein reicht.

Wenn du wissen willst welche Einstellungen gelten,logge dich per ssh auf dem NAS ein und gib ein

testparm

Aktuell in "Global"

fruit:nfs_aces = no

Dann habe ich über GUI für den Server fruit:nfs_aces = yes eingegeben.
Testparm:

fruit:nfs_aces = yes

Testet es einfach, was die Folgen sind:

b) setzt es auf yes

und die rechte bleiben unverändert, wie sie auf dem MAc ursprünglich waren.

Nur Global "yes" : Original Mac 644 -- nach Kopieren 664
auch zusätzlich auf Share "yes" : Original Mac 644 -- nach Kopieren 664

Also ganz unverändert bleiben sie nicht ... zumindest sind die Executable Rechte weg.
Vielleicht mache ich was falsch oder es ist wie es ist

Ergänzung:
Vielleicht liegt es daran, dass bei den Shares lt. testparm noch steht:

create mask = 0664
force create mode = 0664

so dass beim kopieren auf omv diese Rechte gesetzt werden und beim zurückkopieren sie so erhalten bleiben.

 

[lisanet]

Danke für deine Geduld! Also ich zumindest erwarte von dir auch kein HowTo zu Samba! Ganz bestimmt nicht ...
Du sprichst vielleicht, bedingt durch dein extensives Wissen, zT eine etwas andere Sprache als ein "Anfänger".
Wenn du von "patchen" sprichst, meinst du das manuelle editieren über Terminal der smb.conf, richtig? Ein ja, nein reicht.

nein

Aktuell in "Global"

fruit:nfs_aces = no

Dann habe ich über GUI für den Server fruit:nfs_aces = yes eingegeben.
Testparm:

fruit:nfs_aces = yes

Nur Global "yes" : Original Mac 644 -- nach Kopieren 664
auch zusätzlich auf Share "yes" : Original Mac 644 -- nach Kopieren 664

nur auf global ändern. global gilt für share

lies die Doku zu vfs_fruit für welche Einstellungen was gilt, ob global oder share.

Also ganz unverändert bleiben sie nicht ... zumindest sind die Executable Rechte weg.
Vielleicht mache ich was falsch oder es ist wie es ist

Ergänzung:
Vielleicht liegt es daran, dass bei den Shares lt. testparm noch steht:

create mask = 0664
force create mode = 0664

ja

und möglicherweise an diversen Einstellungen zu inherit und/oder acl

so dass beim kopieren auf omv diese Rechte gesetzt werden und beim zurückkopieren sie so erhalten bleiben.

ja und nein.

Das ist genau das Problem das ich meine, mit Posting hier im Forum. Da sind 2 User im Thread, die meinen das gleiche Problem zu haben, deren Konfiguration aber unterschiedlich ist.

Ich vermute, du hast acl und inheritance nicht aktivert. Zudme weiß ich nicht, ob du die Rechte in der GUI korrekt gesetzt hast.

Bedenke bitte auch, dass das ursprüngloiche Problem war, dass man vom Mac aus keine kompletten Ordner aufs NAS kopieren konnte. Nicht nur um irgendwelche andere Themen zu Rechten.

 

[jteschner]

DAS nenne ich mal eine "knappe Antwort"

 

[lisanet]

DAS nenne ich mal eine "knappe Antwort"

du hast es ja so gewollt

 

[jteschner]

Ich vermute, du hast acl und inheritance nicht aktivert. Zudme weiß ich nicht, ob du die Rechte in der GUI korrekt gesetzt hast.

Doch, ich glaube, das habe ich.
Aus Testparm:

[Daten]
    create mask = 0664
    directory mask = 0775
    force create mode = 0664
    force directory mode = 0775
    hide special files = Yes
    inherit acls = Yes
    inherit permissions = Yes
    path = /srv/dev-disk-by-uuid-1ad11bc6-65dc-4e74-b525-8ee7a2b35f0a/Daten/
    read only = No
    store dos attributes = No
    vfs objects = catia fruit streams_xattr
    fruit:resource = xattr
    fruit:metadata = stream
    fruit:encoding = private

Und GUI:

 

[lisanet]

dann ändere die Rechte zu create / directory / force damit es mit dem Mac übereinstimmt

 

[jteschner]

dann ändere die Rechte zu create / directory / force damit es mit dem Mac übereinstimmt

getan. Testparm:

[Daten]
    create mask = 0644
    directory mask = 0755
    force create mode = 0644
    force directory mode = 0755

Ergebnis beim Testen im Finder/Forklift:
Passt! Nur wird das ja wahrscheinlich nicht bleiben, da omv ja nicht gepatcht ist ...