Sequoia 15.2 Probleme mit smb shares auf synology nas

nun ja, viellicht liegt es ja an der Art und Weise wie du dein NAS eingerichtet hast und wie deinen Mac.

Auf dem NAS verwendest du ACL hast du geschrieben. So wie du das geschrieben hast, hast du das womöglich auf Ebene des Filesystesm gemacht und nicht auf Ebene von Samba. Deine Ausgabe von testparm -s gibt da nichts zu ACL her.

Ich verwende Berechtigungen am NAS, wie das Synology intern dann macht interessiert mich erstmal nicht, da es soweit funktioniert.

1747132431890.png1747132488832.png1747132673507.png

Vielleicht verdeutlichen die Screenshots mehr, was ich mit Berechtigungen (ACL) meine.

Die erwiterten attribute, die du im Terminal auf dem share siehst, sind _nicht_ von macOS angelegt, sondern werden von Samba so über smb ausgeliefert an macOS.

Warum?

Der ursprüngliche Ordner vor dem Kopieren hatte keine erweiterten Attribute. Und diese erw. Attritubte tauchen nach deinen Aussagen auch dann auf, wenn die Ordner von einem Windows-Client auf das Nas kopiert wurden und du im Terminal von macOS aus diese Ornder ansiehst.

Falsch hier dürftest du etwas verwechselt haben oder ich habe es nicht klar und deutlich beschrieben. Also nochmal was passiert:

Auf MacOS im Finder erstelle ich unter meinem Benutzerverzeichnis einen Ordner TempCopy. In diesen kopiere ich ein paar Videodateien rein, die ebenso auf der lokalen Disk am mac liegen. Zur Kontrolle eine dir Listening davon im Terminal.

Code:
xxx@imac-xxx ~ % ls -la
total 10936
drwxr-x---+ 29 xxx     staff    928 13 Mai 12:42 .
drwxr-xr-x   5 root    admin    160 13 Mai 08:30 ..
...
drwxr-xr-x+  4 xxx     staff    128 13 Jan 23:06 Public
drwxr-xr-x  12 xxx     staff    384 13 Mai 08:41 TempCopy
xxx@imac-xxx ~ %

Der Ordner TempCopy hat noch keine erweiterten Attribute. Nun kopiere ich diesen Ordner vom iMac auf die Freigabe am Synology NAS, die per SMB eingebunden ist.

Nach dem Kopieren prüfe ich das Ergebnis aus dem Terminal vom Mac am Nas.

Code:
xxx@imac-xxx ~ % mount
...
//xxx@diskstation/diskstation/shared on /Volumes/shared (smbfs, nodev, nosuid, mounted by xxx)
xxx@imac-xxx ~ % cd /Volumes/shared/Downloads
xxx@imac-xxx Downloads % ls -la
total 280
drwx------  1 xxx     staff  16384 13 Mai 12:47 .
drwx------  1 xxx     staff  16384 12 Jan 19:08 ..
-rwx------@ 1 xxx     staff   8196 13 Mai 12:48 .DS_Store
drwx------  1 xxx     staff  16384 26 Dez 15:03 CeeCoach
drwx------  1 xxx     staff  16384 12 Jan 21:36 Dateierweiterungen anpassen
drwx------  1 xxx     staff  16384 13 Jan 23:27 Downloads Mac
drwx------  1 xxx     staff  16384 22 Feb 16:01 Downloads Windows
drwx------  1 xxx     staff  16384 22 Feb 12:31 ISO Files
drwx------@ 1 xxx     staff  16384 13 Mai 08:41 TempCopy
xxx@imac-xxx Downloads % xattr -l TempCopy
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:
xxx@imac-xxx Downloads % xattr -c TempCopy
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
xxx@imac-xxx Downloads %

Für meine folgenden Ausführungen unterstelle ich mal, dass dein NAS als Dateisystem ext4 verwendet und auf Linux-Basis läuft (tut ja Synology) Linux kann aber grundsätzlich nicht selbst mit Windows ACL = NFSv4 ACL (die faktisch identisch mit den ACL sind, die macOS nutzt) umgehen und diese nicht im Dateisystem selbst vollständig speichern.

Ich verwende BTRFS siehe auch Screenshot
1747133617705.png


Samba ist da also in einem Konflikt, wie es diese ACL nun verwalten, speichern und bei Zugriffen von clients ausliefern soll. Dazu verwendet Samba erweiterte Attribute.

Wenn du nun auf dem NAS ACL verwendest (wie erwähnt, hattest du das ja so geschrieben) _muss_ Samba diese ACL auch an die Clients ausliefern.

Wenn das nun ACL sind, die du auf Ebene des Dateisystems verwendest, wird Samba diese nicht anfassen, mit der Folge, dass du die nicht über smb löschen kannst.

Das ist meine Erklörung zu deinem "Problem", auch wenn ich dir eigentlich, wegen deiner sehr persönlichen angrefenden art, eigentlich gar nicht helfen wollte. Mir ist es aber wichtig, dass andere Mitleser dieses Thread halt auch Wissen erlangen können.

Ich würde hier also als Tipp geben: verzichte auf ACL

Ok soweit verstehe ich das ja generell. Aber gemäß Codeauszug vom ls gibt es ja auch eine Datei ._DS_Store mit erweiterten Attributen. Und da kommt nun erstaunliches. Ich kann diese löschen. Also bin ich mir wiederum nicht sicher ob es an den ACLs liegt.

Code:
xxx@imac-xxx Downloads % xattr -l .DS_Store
com.apple.FinderInfo:         @
xxx@imac-xxx Downloads % xattr -c .DS_Store
xxx@imac-xxx Downloads % ls -la
total 280
drwx------  1 xxx     staff  16384 13 Mai 12:47 .
drwx------  1 xxx     staff  16384 12 Jan 19:08 ..
-rwx------  1 xxx     staff   8196 13 Mai 12:48 .DS_Store
drwx------  1 xxx     staff  16384 26 Dez 15:03 CeeCoach
drwx------  1 xxx     staff  16384 12 Jan 21:36 Dateierweiterungen anpassen
drwx------  1 xxx     staff  16384 13 Jan 23:27 Downloads Mac
drwx------  1 xxx     staff  16384 22 Feb 16:01 Downloads Windows
drwx------  1 xxx     staff  16384 22 Feb 12:31 ISO Files
drwx------@ 1 xxx     staff  16384 13 Mai 08:41 TempCopy

Zusammenfassend anhand der Screenshots wirst du ja eingestehen, dass es etwas komplex ist. Ausgehend davon, dass auf der Mac Platte das Verzeichnis vor dem Kopieren keine erweiterten Attribute besitzt, hat es nach dem Kopieren welche und zwar jene die der Finder setzt um im Falle des Abbruchs vom Kopieren wieder fortsetzen zu können. Das macht der Finder auch wenn Dateien oder Ordner lokal von einer Location auf die andere kopiert werden. Ist das Kopieren erfolgreich löscht "das Kopieren" diese Attribute wieder. Wir sprechen hier von den Attributen
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:
Auf dem NAS scheint das nicht zu funktionieren, weil eben der Fehler Not a Directory kommt. Deswegen bleiben sie leer am Ordner erhalten.

Abschließend wäre das Ergebnis folgenden Tests interessant: Kopiere den Ordner zurück vom NAS auf den Mac und prüfe dann ob dort auf dem Mac erweiterte Attribute vorhanden sind und falls ja, ob du sie löschen kannst.

Here we go. Ich kopiere den Ordner extra an einen anderen Ort auf meiner lokalen Disk (~/Downloads). Ergebnis:

Code:
xxx@imac-xxx Downloads % pwd
/Volumes/shared/Downloads
xxx@imac-xxx Downloads % cd ~/Downloads
xxx@imac-xxx Downloads % pwd
/Users/xxx/Downloads
xxx@imac-xxx Downloads % ls -la
total 10564704
drwx------+ 36 xxx  staff        1152 13 Mai 13:08 .
drwxr-x---+ 29 xxx  staff         928 13 Mai 13:08 ..
-rw-r--r--@  1 xxx  staff        8196 13 Mai 13:08 .DS_Store
-rw-r--r--   1 xxx  staff           0 13 Jan 23:06 .localized
...
drwx------@ 12 xxx  staff         384 13 Mai 08:41 TempCopy
...

xxx@imac-xxx Downloads % xattr -l TempCopy
com.apple.finder.copy.source:
xxx@imac-xxx Downloads % xattr -c TempCopy
xxx@imac-xxx Downloads % ls -la
total 10564704
drwx------+ 36 xxx  staff        1152 13 Mai 13:08 .
drwxr-x---+ 29 xxx  staff         928 13 Mai 13:08 ..
-rw-r--r--@  1 xxx  staff        8196 13 Mai 13:08 .DS_Store
-rw-r--r--   1 xxx  staff           0 13 Jan 23:06 .localized
...
drwx------  12 xxx  staff         384 13 Mai 08:41 TempCopy

Der Finder verändert ja diese Attribute wieder und hinterlässt auch eines davon am Verzeichnis, welches ich lokal löschen kann. Dieses hier aufgezeigte Verhalten habe ich auch, wenn ich einen Ordner vom Mac mittels Finder auf einem Share kopiere, der per SMB von Windows 11 Pro bereit gestellt wird.

Ich hoffe nun ist etwas klarer was ich genau meine.
 
du verwendest ACL, das sagen auch deine neuen screenshots aus. Nennt sich dort halt "erweiterte Freigabeberechtigungen".

Samba liefert die ACL an macOS aus. Die legt nicht der Finder an. Kannst du nun glauben oder nicht. Die einzigen ACL die macOS verwendet, wenn es auf einen smb-Server zugriefen will, sind dazu da die Zugriffsrechte auf den Mac-User zu setzen, der zugreift.

Das alles wird im Normalfall vom vfs_fruit gehandhabt und eben in erweiterten Attributen gespeichert. Daher ist. es ja auch rundum zu empfehlen, diese macOS Module zu verwenden, was du nicht tust, da du ja auf Reddit irgendwelche Horrorgeschichten gelesen hast und denen glaubst.

Wenn du also ACL auf dem NAS verwendest, gleichzeitig aber nicht die macOS erforderlichen Attribute ist es für mich durhcaus nachvollziehbar, dass die ACL für Verzeichnisse durcheinander kommen.

Bei macOS 14 und älter ist zudem beim Kopieren von zip-Dateien auf einen samba-Server ein Fhelr mit den Berechtigungen von Ordnern aufgetreten. Der ist hat allerdings das Verzeichnis nicht löschbar gemacht. ich weiß das, weil ich damals dann den source code von samba entsprechend gepatched und den Fehler behoben habe. Seit Sonoma ist der Fehler nicht mehr vorhanden.

Auch hier gilt: die verwendest ACL und nutzt nicht die macOS vfs Module, wenn nun noch ein Sonoma oder älteres System zum Einsatz kommt, kann auch das diese Effekte haben.

So, nun weißt du die entsprechenden Möglichkeiten. Ob du mir glaubst und die Tipps anwendest oder nicht ist deine Entscheidung.

Weiter Hilfe gibt's von mir nicht mehr. Viel Glück.
 
Zuletzt bearbeitet:
Wir sind uns aber einig das

com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:

vom Finder kommt und nicht von smb.

Bei mir kommt derzeit nur MacOS Sequoia 15.5 zum Einsatz, keine ältere Version.
 
so gemäß Configure Samba to Work Better with Mac OS X - SambaWiki smb.conf angepasst.

Code:
testparm -s
Load smb config files from /etc/samba/smb.conf
lpcfg_do_global_parameter: WARNING: The "ldap ssl ads" option is deprecated
/etc/samba/smb.reserved.conf not found
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

WARNING: The 'client ipc signing' value may mean SMB signing is not used when contacting a domain controller or other server. This setting is not recommended; please be aware of the security implications when using this configuration setting.

WARNING: You have not configured 'reject md5 servers = yes' (the default). Your server is vulernable to CVE-2022-38023
If required use individual 'reject md5 servers:NETBIOSDOMAIN = no' options

Server role: ROLE_STANDALONE

# Global parameters
[global]
    passdb backend = smbpasswd
    printcap name = cups
    realm = *
    security = USER
    server min protocol = SMB2
    server signing = No
    smb2 leases = Yes
    syno catia = Yes
    syno directory lease grant restrict home only = Yes
    winbind enum groups = Yes
    winbind enum users = Yes
    winbind expand groups = 1
    fruit:delete_empty_adfiles = yes
    fruit:wipe_intentionally_left_blank_rfork = yes
    fruit:model = MacSamba
    fruit:posix_rename = yes
    fruit:veto_appledouble = no
    fruit:nfs_aces = no
    fruit:metadata = stream
    notify:synotify = yes
    rpc_server:msftewds = external
    rpc_daemon:wspd = fork
    fruit:locking = none
    rpc_server:mdssvc = external
    rpc_daemon:mdssd = fork
    tdb_hashsize:netsamlogon_cache.tdb = 768
    tdb_hashsize:smbprofile.tdb = 1536
    tdb_hashsize:leases.tdb = 10007
    tdb_hashsize:smbxsrv_open_global.tdb = 10007
    tdb_hashsize:locking.tdb = 10007
    tdb_hashsize:smbxsrv_tcon_global.tdb = 768
    tdb_hashsize:smbxsrv_session_global.tdb = 768
    idmap config * : backend = syno
    durable handles = No
    follow symlinks = Yes
    include = /var/tmp/nginx/smb.netbios.aliases.conf
    strict sync = No
    syno directory lease grant = Yes
    vfs objects = "fruit streams_xattr"


[Diskstation]
    comment = "Diskstation"
    edit synoacl = Yes
    enable recycle bin = Yes
    guest ok = Yes
    invalid users = nobody,nobody
    path = /volume1/Diskstation
    read list = nobody,nobody
    read only = No
    recycle bin admin only = Yes
    service exist = Yes
    strict allocate = No
    syno directory lease grant = No
    syno fstype = 3
    valid users = nobody,@administrators,@fs-users,nobody
    win share = Yes
    write list = nobody,@fs-users,@administrators,nobody

erneut getestet - Problem besteht weiterhin.
 
so gemäß Configure Samba to Work Better with Mac OS X - SambaWiki smb.conf angepasst.

Code:
testparm -s
Load smb config files from /etc/samba/smb.conf
lpcfg_do_global_parameter: WARNING: The "ldap ssl ads" option is deprecated
/etc/samba/smb.reserved.conf not found
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

WARNING: The 'client ipc signing' value may mean SMB signing is not used when contacting a domain controller or other server. This setting is not recommended; please be aware of the security implications when using this configuration setting.

WARNING: You have not configured 'reject md5 servers = yes' (the default). Your server is vulernable to CVE-2022-38023
If required use individual 'reject md5 servers:NETBIOSDOMAIN = no' options

Server role: ROLE_STANDALONE

# Global parameters
[global]
    passdb backend = smbpasswd
    printcap name = cups
    realm = *
    security = USER
    server min protocol = SMB2
    server signing = No
    smb2 leases = Yes
    syno catia = Yes
    syno directory lease grant restrict home only = Yes
    winbind enum groups = Yes
    winbind enum users = Yes
    winbind expand groups = 1
    fruit:delete_empty_adfiles = yes
    fruit:wipe_intentionally_left_blank_rfork = yes
    fruit:model = MacSamba
    fruit:posix_rename = yes
    fruit:veto_appledouble = no
    fruit:nfs_aces = no
    fruit:metadata = stream
    notify:synotify = yes
    rpc_server:msftewds = external
    rpc_daemon:wspd = fork
    fruit:locking = none
    rpc_server:mdssvc = external
    rpc_daemon:mdssd = fork
    tdb_hashsize:netsamlogon_cache.tdb = 768
    tdb_hashsize:smbprofile.tdb = 1536
    tdb_hashsize:leases.tdb = 10007
    tdb_hashsize:smbxsrv_open_global.tdb = 10007
    tdb_hashsize:locking.tdb = 10007
    tdb_hashsize:smbxsrv_tcon_global.tdb = 768
    tdb_hashsize:smbxsrv_session_global.tdb = 768
    idmap config * : backend = syno
    durable handles = No
    follow symlinks = Yes
    include = /var/tmp/nginx/smb.netbios.aliases.conf
    strict sync = No
    syno directory lease grant = Yes
    vfs objects = "fruit streams_xattr"


[Diskstation]
    comment = "Diskstation"
    edit synoacl = Yes
    enable recycle bin = Yes
    guest ok = Yes
    invalid users = nobody,nobody
    path = /volume1/Diskstation
    read list = nobody,nobody
    read only = No
    recycle bin admin only = Yes
    service exist = Yes
    strict allocate = No
    syno directory lease grant = No
    syno fstype = 3
    valid users = nobody,@administrators,@fs-users,nobody
    win share = Yes
    write list = nobody,@fs-users,@administrators,nobody

erneut getestet - Problem besteht weiterhin.
Die genannte Konfig von der verlinkten Seite ist auch nicht ganz korrekt.
setze mal auf jeden Fall in Global:
fruit:nfs_aces = yes (WICHTIG!)

Und im Share sollte drin sein:
vfs objects = catia fruit streams_xattr
fruit:encoding = private
fruit:metadata = stream
fruit:resource = xattr

Weiterhin gehören auch mWn keine "" in
vfs objects = "fruit streams_xattr"
sondern nur
vfs objects = fruit streams_xattr
Allerdings habe ich diesen Parameter gar nicht in meiner Global section.

Teste dann nochmal ... vielleicht hilft es ja ... ich weiss nur nicht, wie der samba-server der Syno das verarbeitet
 
das ändert alles nichts.
 
Übertragt doch mal von einem Windows einen Ordner mit n GB auf einen anderen oder ein NAS. Da kann man seeehr lange zusehen.
Na ja, geht hier schneller als mit MacOS. Mit so pauschalen kommt man selten weiter. Mac/ Apple und Netzwerk, da hätte ich gsegt ist noch sehr viel Luft nach oben.
 
Wofür soll der gut sein? So wie ich es in Erinnerung habe, ist das Modul nur um irgendwelche "Kryptozeichen" zu übersetzen. Ohne weitere Konfiguration Parameter macht es auch genau nichts (Womöglich hat sich das aber verändert. Ich habe es nicht jetzt extra nachgelesen)
 
stimmt, ist auch vollkommen logisch.

-> ACL
nochmal du erklärst mir, dass ich für ACL bestimmte module brauche, dann gebe ich das in die Konfiguration rein und die ACL ist wieder das Problem? Die ACL mit den User Berechtigungen wird aber benötigt und funktioniert auch.

und diese extented Attribute löst der Finder mit seiner Copy API aus, auch wenn du das nicht wahrhaben willst. Warum sollt sich der smb Server einfach so aus Spass irgendwelche erweiterten Attribute in Verzeichnisse schreiben wollen.
 
nochmal du erklärst mir, dass ich für ACL bestimmte module brauche, dann gebe ich das in die Konfiguration rein und die ACL ist wieder das Problem? Die ACL mit den User Berechtigungen wird aber benötigt und funktioniert auch.

und diese extented Attribute löst der Finder mit seiner Copy API aus, auch wenn du das nicht wahrhaben willst. Warum sollt sich der smb Server einfach so aus Spass irgendwelche erweiterten Attribute in Verzeichnisse schreiben wollen.

ich habe es dir x mal erklärt. Lies es einfach nochmals in Ruhe durch.

Und wenn du meinst ACL brauchen zu müssen, solltest du dich mit denen befassen. Es gibt etliche Module, die zum korrekten Handling von ACL gehören. Die manpages des Projektes sind sehr gut.

Und da diese "copy API" ja wohl auch bei mir und anderen Usern mit NAS verwendet wird, fragst du dich nicht, warum all diese User dein Problem nicht haben?

Wenn ich mal viel Lust und Zeit habe, installiere ich mir DSM auf einem meiner PCs, nur um mal zu versuchen, ob ich das NAS auch so verbasteln kann wie du.

Abschließend: mehr an Hilfe gibts nicht mehr von mir, ich habe alles wesentliche genannt. Der Rest der Umsetzung liegt an dir. Denn eine config werde ich dir garantiert nicht liefern, auch wenn ich es kann.
 
Ich habe nur einen Share - keine Timemachine nichts - deswegen auch die Globale Sektion.
 
letzter Tipp:

Ein "Spezialist" meint, es ist typisch für Synology NAS im Gegensatz zu NAS anderer Hersteller oder Linux Shares. man kann erweiterte attribute komplett abschalten, oder durch Module anders handhaben lassen. Sollte der "Spezialist" Recht haben, ist dies für mich ein weiterer Grund für openmediavault als NAS-Software.
 
Wofür soll der gut sein? So wie ich es in Erinnerung habe, ist das Modul nur um irgendwelche "Kryptozeichen" zu übersetzen. Ohne weitere Konfiguration Parameter macht es auch genau nichts (Womöglich hat sich das aber verändert. Ich habe es nicht jetzt extra nachgelesen)
Dann lies mal hier: https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html
Die "Description" und schau dir das "Example" der Verwendung an.
Ich bin ja alles andere als ein "Fachmann" - aber ich weiss: bei mir funktionierts.
 
letzter Tipp:

Ein "Spezialist" meint, es ist typisch für Synology NAS im Gegensatz zu NAS anderer Hersteller oder Linux Shares. man kann erweiterte attribute komplett abschalten, oder durch Module anders handhaben lassen. Sollte der "Spezialist" Recht haben, ist dies für mich ein weiterer Grund für openmediavault als NAS-Software.
Ok welche fertige Hardwarelösung zu OMV gibt es bzw. welcher NAS Hersteller arbeitet dann mit MacOS sauber? Windows verhält sich wie Synology und lässt sich ebenso nicht wirklich konfigurieren.

Alle anderen Eröterungen erspare ich mir, weil nicht zielbringend. Es bringt halt nichts über omv Konfigurationen oder generelle samba Konfigurationen zu sinnieren, wenn der NAS Hersteller Synology sein samba dementsprechend modifiziert hat und eigene Module verwendet und zudem auch noch Default Settings vom Original Samba umgepatched hat.

bspw.: Configure Samba to Work Better with Mac OS X - SambaWiki sagt

Code:
Apple extensions require support for extended attributes(xattr) - defaults to yes in Samba 4.9+:

ea support = yes

der Parameter ist gemäß einem Output von testparm -sv auf No.

ansonsten noch danke an @jteschner der mir beim Testen geholfen hat mit seinen Outputs.
 
Ok welche fertige Hardwarelösung zu OMV gibt es
Na, eigentlich jeder Standard-PC
Ich würde das nächste mal (wie du weisst habe ich heute einen RPi) einen kleinen Mini-PC nehmen. So wie diesen hier:
https://www.amazon.de/dp/B0CQYT2QHY (oder vergleichbar)
Debian drauf, OMV drauf, Platten dran (per USB), konfigurieren, fertig
Das sollte für jemanden mit Basiskenntnissen in 1 -2 Std zu machen sein.

Code:
Apple extensions require support for extended attributes(xattr) - defaults to yes in Samba 4.9+:

ea support = yes

der Parameter ist gemäß einem Output von testparm -sv auf No.

ansonsten noch danke an @jteschner der mir beim Testen geholfen hat mit seinen Outputs.
1. ea support ist bei mir auch auf "no"
2. gern
 
hast du die externen platten als RAID konfiguriert wegen Ausfallssicherheit?
 
Zurück
Oben Unten