Sequoia 15.2 Probleme mit smb shares auf synology nas

[lisanet]

jt@omv:~ $ umask
0022

lt. testparm ist in Global fruit:nfs:aces=yes gesetzt.


"inherit permissions" habe ich bei allem aus (genauso wie ACLs vererben)
Habe ich aber mal gerade auf einem Test-Share eingeschaltet: keine Änderung.

Irgendwie habe ich Gefühl, dass es an

[test]
    create mask = 0664
    directory mask = 0775
    force create mode = 0664
    force directory mode = 0775
    ...

liegt. Denn wie gesagt: aus 0644 auf Mac wird 0664 auf NAS und selbst wenn ich die create mask auf 0644 ändere nutzt das nichts.
Es sieht also so aus, als wenn der force create mode da reinspielt.
Und das, obwohl ich diese Parameter weder in [Global] noch in [test] selbst gesetzt habe.

Das kann ich nicht nachstellen. Ich habe ein neues share erstellen und dort genau jene mask/mode verwendet. Die Unix-Perms des shares sind in der omv für meinen account auf rwx für users auf rwx und other auf rx. Keine ACL.

Die Rechte sind 644, sowohl direkt auf dem Server als auch via /Volumes/Test

Ich kann dir nur mal anbieten, deine smb.conf anzusehen, wenn du sie mir per PM sendest (nicht hier im Thread)

Was ich noch testen muss, wäre das ungepachte Modul, wobei darin hinsichtlich der Unix-Rechte gar nix verändert ist.

Edit: auch mit dem ungepachten Modul kann ich es nicht nachstellen. Die Rechte sind auf dem Mac 644, nach dem Kopieren aus NAS, sowohl direkt auf dem NAS als auch via /Volumes nach wie vor 644

 

[jteschner]

Das kann ich nicht nachstellen. Ich habe ein neues share erstellen und dort genau jene mask/mode verwendet. Die Unix-Perms des shares sind in der omv für meinen account auf rwx für users auf rwx und other auf rx. Keine ACL.

Da könnte ein Unterschied liegen.
Ich mache alles über die OMV-GUI und bei sieht es im Default folgendermassen aus:

jt@omv:/volumes/pool $ ls -l
total 68
-rw-------   1 root root   7168 May 12 19:29 aquota.group
-rw-------   1 root root   7168 May 12 19:29 aquota.user
...
drwxrwsr-x   2 root users  4096 May 15 11:46 test

Ich kann dir nur mal anbieten, deine smb.conf anzusehen, wenn du sie mir per PM sendest (nicht hier im Thread)

mach ich. Danke.

 

[lisanet]

jt@omv:~ $ umask
0022

jetzt sehe ich das erst:

nicht auf omv, sondern auf dem Mac die umask auslesen

 

[jteschner]

jetzt sehe ich das erst:

nicht auf omv, sondern auf dem Mac die umask auslesen

MacBookPro:jt - /Volumes/test
> umask
022

 

[OmarDLittle]

Vielleicht könnte jemand von omv oder diy NAS. mal einen Ordner im Finder, der Dateien enthält.,auf einen Share am NAS kopieren Vor dem Kopieren sollte der Source Ordner auf MacOS keine extended Attribute haben. also ls -la von dem Folder sollte im Output kein @ Zeichen haben. Mich würde interessieren ob nach dem Kopieren auf den NAS share auch dort besagte Attribute dann verbleiben und nicht gelöscht werden können.

Hab das mal eben mit meinem eigenen Fileserver gemacht der Samba v4.17.12-Debian mit den für Mac empfohlenen objects acl_xattr catia fruit streams_xattr nutzt und da ist vorher wie nachher kein @-Zeichen mit meinem M1-Mac mit Sequoia auffindbar. xattr -l listet vorher wie nachher für das Verzeichnis keine Attribute auf. Ich hab am Server aber ein Verzeichnis gefunden das es hat und da wird ein Attribut com.apple.macl aufgeführt das aber leer ist. Das Verzeichnis wurde vor 2 Jahren erstellt/bearbeitet, also nicht mit Sequoia.

Ich glaube nicht dass dein Problem mit einer falschen Samba-Konfig zu tun hat, sondern an irgendwas bei deinem MacOS liegt, aber warum es so ist weiß ich nicht.

Markiere ich alle 18k und sage kopieren und dann im Ordner vom NAS einfügen, vergehen Stunden mit kopieren wird vorbereitet, weil der idotische Finder für jedes File erstmal eine leere Datei erzeugen will.

Ja das ist so und funktioniert schlicht nicht. Warte ab, bis da mal eine Unterbrechung ist und du dann später die restlichen 8k Files der insgesamt 18k fertigkopieren willst. MacOS sieht dann jede leere "Hülle" als existierendes File an genauso wie die bereits erfolgreich kopierten Dateien und du kannst dir dann aussuchen, ob du alles von vorn machen willst oder ob du versuchst die 8k leeren Hüllen vorher runterzulöschen. Schlicht unmöglich wenn das 8k leere Hüllen auf zig Verzeichnisse verteilt sind, und auch unmöglich wenn die alle in einem Ordner liegen, weil du 8k Files nicht markiert und gelöscht bekommst ohne dass der Finder ewig hängt.

gebe ich die 18k Dateien in einen Ordner TEMP lokal. und kopieren den Ordner TEMP an die Position wo die Dateien am NAS sind klappt das ziemlich zügig.

Genau. Außer es bricht zwischendurch ab, dann hält MacOS eine "resumable copy" vor am NAS, aber wenn du sie fortsetzt startet es dennoch wieder ganz von vorne. Und bis der Kopiervorgang fertig ist, lässt sich der Ordner auch nicht öffnen.

Ich verwende dazu einfach rsync und hab da keine Probleme was kompilieren zu müssen, das ist über brew bezogen. Irgendeine Krot muss man schlucken, anders gehts mit MacOS und Samba nicht. Keine Sorge, ist mit iOS alles noch schlimmer. Freu dich, dass es nur auf MacOS-Level schlecht ist und nicht auf iOS-Level. Sonst verkaufst du alle Computer und baust hauptberuflich Gemüse an.

ok xattr auf Verzeichnissen auf meinem NAS bringt generell den Fehler xattr: [Errno 20] Not a directory:

Google meint dein Terminal hat eventuell in MacOS kein Full Disk Access. Der Fehler ist anscheinend einer in den man aus verschiedenen Gründen laufen kann, und das muss nichts damit zu tun haben, was in der Fehlermeldung drinsteht. Ergibt auch keinen Sinn wenn du es auf ein Verzeichnis laufen lässt, dass die Beschwerde kommt es sei kein Verzeichnis. Probiers mal mit einem absoluten Pfad im Terminal, also xattr -l /Volumes/NAS/... eventuell geht es dann schon.

 

[MOM2006]

Hab das mal eben mit meinem eigenen Fileserver gemacht der Samba v4.17.12-Debian mit den für Mac empfohlenen objects acl_xattr catia fruit streams_xattr nutzt und da ist vorher wie nachher kein @-Zeichen mit meinem M1-Mac mit Sequoia auffindbar. xattr -l listet vorher wie nachher für das Verzeichnis keine Attribute auf. Ich hab am Server aber ein Verzeichnis gefunden das es hat und da wird ein Attribut com.apple.macl aufgeführt das aber leer ist. Das Verzeichnis wurde vor 2 Jahren erstellt/bearbeitet, also nicht mit Sequoia.

Ich glaube nicht dass dein Problem mit einer falschen Samba-Konfig zu tun hat, sondern an irgendwas bei deinem MacOS liegt, aber warum es so ist weiß ich nicht.

Die Attribute kommen ja vom Finder für das Kopieren und Resumen und sollten vom Finder nach erfolgtem kopieren wieder gelöscht werden. Wenn du einen Ordner, der keine erweiterten Attribute hat, auf den Share oder lokal kopierst und das kopieren abbrichst dann ist der Ordner im Finder praktisch grau hinterlegt. wenn du nun am Terminal schaust, wirst du sehen, dass der Ordner nun diese erweiterten Attribute hat. Wenn du das kopieren fortsetzt oder abbrichst, werden diese Attribute gelöscht. Bei mir auf smb bleiben sie halt, weil das Löschen eben nicht funktioniert und im Hintergrund auch dieses not a Directory kommen wird. Soweit hätte ich das schon durchschaut. Und ich denke es liegt an der smb config.

Google meint dein Terminal hat eventuell in MacOS kein Full Disk Access. Der Fehler ist anscheinend einer in den man aus verschiedenen Gründen laufen kann, und das muss nichts damit zu tun haben, was in der Fehlermeldung drinsteht. Ergibt auch keinen Sinn wenn du es auf ein Verzeichnis laufen lässt, dass die Beschwerde kommt es sei kein Verzeichnis. Probiers mal mit einem absoluten Pfad im Terminal, also xattr -l /Volumes/NAS/... eventuell geht es dann schon.

Terminal hat vollen Festplattenzugriff. Bei normalen Dateien mit erweiterten Attributen auf smb funktioniert ja das xattr -c zum Löschen auch. Auch mit dem absoluten Pfad keine Chance. Also ich denke doch die Samba-Konfig ist das Problem. Interessant halt, dass bei einem Windows Share das gleiche Problem vorhanden ist. Vielleicht kannst du das ja mal probieren. Bei Windows 11 Shares habe ich das Problem auch. Alles in allem werd ich mir jetzt eben mal für OMV hardware organisieren und das dann in einem ruhigen Moment testen und dann umstellen. Die Arbeitsweise von Synology gefällt mir nicht mehr, deswegen auch der Plan zu wechseln und der intensivere Thread hier. Im Prinzip ist das Problem bei meiner Verwendung Kosmetik es kostet mich dann halt ein paar Mausklicks mehr bei den täglichen Aufgaben. Es ist aber jetzt nicht Existenzbedrohendes.

edit:

achja umask 022 hätte ich am mac auch, wenn ich umask einfach so starte.

was anderes noch. ich habe am mac keine nsmb.conf oder smb.conf files irgendwo erstellt mit irgendwelche Optimierungen für den Mac. Da gibt es im Netz ja auch einiges. Ich gehe mal davon aus, dass auch das nicht die Ursache sein wird dann.

 

[OmarDLittle]

Wenn du einen Ordner, der keine erweiterten Attribute hat, auf den Share oder lokal kopierst und das kopieren abbrichst dann ist der Ordner im Finder praktisch grau hinterlegt.

Hab ich extra jetzt gemacht, hast du ganz recht, nach Abschluss des Kopiervorgangs bleibt dann das leere Attribut com.apple.FinderInfo zurück. Einmal xattr -c auf den Ordner am Server laufen lassen und das Attribut ist weg, kein @-Zeichen mehr. Keine Fehlermeldung wie bei dir. Vielleicht liegt es einfach an der smb.conf am Server, ich hab drin: vfs objects = acl_xattr catia fruit streams_xattr

Das muss alles rein damit fruit richtig läuft glaub ich. In den globalen Settings hab ich zusätzlich fruit:model = MacPro, fruit:advertise_fullsync = true sowie fruit:aapl = yes.

Kannst du ja einfach probieren, die Samba-Version unterstützt das grundsätzlich schon, sofern Synlogy keinen Blödsinn treibt. Wenns nichts bringt kannst es ja wieder rausnehmen.

Windows kann ich nicht testen, hab kein Windows mehr im Einsatz im Heimnetzwerk. (Hab nur noch einen Spielerechner mit Win 11, aber der steht in einem separaten Netzwerk weil ich dem Mist nicht über den Weg traue, da komm ich vom Mac aus nicht ran.)

 

[MOM2006]

unglaublich. ich hab mir jetzt mal das log vom smbd angesehen.

../../lib/util/modules.c:49: [2025/05/16 07:44:41.506508, all 0, pid=13138] load_module
  Error loading module '/var/packages/SMBService/target/usr/lib/samba/vfs/acl_xattr catia fruit streams_xattr.so': /var/packages/SMBService/target/usr/lib/samba/vfs
/acl_xattr catia fruit streams_xattr.so: cannot open shared object file: No such file or directory

und in der Config steht

vfs objects=acl_xattr catia fruit streams_xattr

also da hat synology wohl ganze arbeit geleistet.

 

[MOM2006]

abgesehen davon hat synology gar nicht alle module, sondern andere.

root@diskstation:~# ls -la /var/packages/SMBService/target/usr/lib/samba/vfs/
total 528
drwxr-xr-x  2 root root  4096 Oct  8  2024 .
drwxr-xr-x 11 root root  4096 Oct  8  2024 ..
-rwxr-xr-x  1 root root 27368 Oct  8  2024 btrfs.so
-rwxr-xr-x  1 root root 60144 Oct  8  2024 catia.so
-rwxr-xr-x  1 root root 15080 Oct  8  2024 dirsort.so
-rwxr-xr-x  1 root root 56112 Oct  8  2024 fruit.so
-rwxr-xr-x  1 root root 68328 Oct  8  2024 shadow_copy2.so
-rwxr-xr-x  1 root root 31912 Oct  8  2024 synovfs_acl.so
-rwxr-xr-x  1 root root 19176 Oct  8  2024 synovfs_btrfs_clone.so
-rwxr-xr-x  1 root root 39728 Oct  8  2024 synovfs_c2fs.so
-rwxr-xr-x  1 root root 15080 Oct  8  2024 synovfs_recycle.so
-rwxr-xr-x  1 root root 51944 Oct  8  2024 synovfs_stream.so
-rwxr-xr-x  1 root root 23336 Oct  8  2024 synovfs_unlinkd.so
-rwxr-xr-x  1 root root 15144 Oct  8  2024 synovfs_worm.so
-rwxr-xr-x  1 root root 43752 Oct  8  2024 synovfs_xattr.so
-rwxr-xr-x  1 root root 31464 Oct  8  2024 synovfs_xferlog.so
-rwxr-xr-x  1 root root 15080 Oct  8  2024 widelinks.so

also die haben das richtig kaputt gepatched

 

[lisanet]

Ich möchte kurz auf einen gerade von mir erstellten Thread hinweisen:

-> https://www.macuser.de/threads/timemachine-wird-mit-updates-auf-samba-4-22-in-nas-nicht-mehr-funktionieren.957199/

In der akuellen Samba 4.22 Version wurde ein Feature entfernt, das für TimeMachine essetiell ist. NAS / Linux Server die samba 4.22 verwenden, werden dann TimeMachine-Backups nicht mehr korrekt unterstützen, sowohl neu angelegte als auch bereits bestehende Backups.

Aus meiner Sicht ist das der GAU für Mac User.

Und, wie so oft wird es dann wohl wieder heißen, dass Apple Schuld sei, was hier aber eben definitiv nicht der Fall ist. Es liegt hier eindeutig am Samba Projekt.

Ich möchte da Samba keinesfalls schlecht machen. Die machen echt einen super Job. aber deren Fokus ist nun mal Windows. Und wie bei vielen anderen open source Projekten ist macOS nicht nur das Stiefkind, es wird manchmal auch aus Prinzip nicht auf Macs geachtet, da viele Linux-Entwickler halt gerne auf Apple bashen, wie eben auch hier im Forum viele vermeintlichen "Kritiker" erst mal bei Apple die Schuld suchen.

 

[MOM2006]

Ich möchte kurz auf einen gerade von mir erstellten Thread hinweisen:

-> https://www.macuser.de/threads/timemachine-wird-mit-updates-auf-samba-4-22-in-nas-nicht-mehr-funktionieren.957199/

In der akuellen Samba 4.22 Version wurde ein Feature entfernt, das für TimeMachine essetiell ist. NAS / Linux Server die samba 4.22 verwenden, werden dann TimeMachine-Backups nicht mehr korrekt unterstützen, sowohl neu angelegte als auch bereits bestehende Backups.

Aus meiner Sicht ist das der GAU für Mac User.

Und, wie so oft wird es dann wohl wieder heißen, dass Apple Schuld sei, was hier aber eben definitiv nicht der Fall ist. Es liegt hier eindeutig am Samba Projekt.

Ich möchte da Samba keinesfalls schlecht machen. Die machen echt einen super Job. aber deren Fokus ist nun mal Windows. Und wie bei vielen anderen open source Projekten ist macOS nicht nur das Stiefkind, es wird manchmal auch aus Prinzip nicht auf Macs geachtet, da viele Linux-Entwickler halt gerne auf Apple bashen, wie eben auch hier im Forum viele vermeintlichen "Kritiker" erst mal bei Apple die Schuld suchen.

Das klingt mal gar nicht gut. Wir hatten in der Firma mal einen Fall vor 3-4 Jahren wo Samba auch Veränderungen machte und RedHat Enterprise diese Änderungen mit Patches auf die Kundschaft los lies. Nach Installieren der Patches war Windows nicht mehr in der Lage diese Shares zu verbinden. Gut 4 Monate mussten wir die Updates zurück halten bis RedHat nachbesserte und das Problem wieder beseitigte.

Seitdem sind wir da sehr kritisch was Samba Patches auf diversen Linux Servern angeht. Und der Focus liegt bei denen dann auch nicht immer so auf Windows.

Was Mac und SMB betrifft, nun ja allein schon Beruflich ist Windows für mich die Referenz, da ich einige Fileserver auf Windows Basis in der Firma mitadministriere und somit andere Systeme mit Windows funktionieren müssen, weil eben Windows die Mehrheit im Unternehmen ist. Nach dem das besagte Problem hier auch in Verbindung mit Windows present ist, ging ich eben von einem Fehler in MacOS aus.

 

[OmarDLittle]

unglaublich. ich hab mir jetzt mal das log vom smbd angesehen.

Ja das ist schon schwach, das ist schließlich ein Feature dass Synology bewirbt und für das man auch zahlt. Wie sieht es dann mit der auch vermutlich beworbenen Timemachine-Funktionalität aus? Das dürfte dann überhaupt nicht unterstützt sein...

Jedenfalls wäre es wie @lisanet es erwähnte für eine genauere Fehlersuche sinnvoll, zuerst mit einer unterstützten Samba-Konfig zu beginnen, sonst kann man nie das NAS als Fehlerursache ausschließen. Es gibt auch simple NAS-taugliche Server wo du auch nur die Platten reinsteckst, dir ein Linux aufspielst und dann läuft Samba so ziemlich out of the box, solange du diese gleichen Parameter wieder in die smb.conf reinwirfst.

Ich hab es schon seit vielen Jahren nicht mehr gemacht, aber du könntest alternativ auch schauen ob du ein Laufwerk via iSCSI einbinden kannst. Dann verhält es sich wie eine externe Festplatte, die du mit APFS formatieren musst (daher kein gleichzeitiges Sharing mit anderen Geräten und nur auf MacOS lesbar), und erhält dadurch auch abhängig von der Netzwerkgeschwindigkeit eine Performance die einer externen Platte entspricht. Das ganze Netzwerkgedöns von SMB/Samba fällt weg und auch alle Bugs die dadurch entstehen.

Weiß nicht ob das MacOS inzwischen nativ beherrscht oder ob es noch Software gibt, das NAS sollte es können. iSCSI könnte eigene Bugs wieder haben, aber meiner Erfahrung nach früher war das zumindest mit Ethernetkabel und bestenfalls 10GbE deutlich besser als alles Netzwerk-Zeugs im Finder.

 

[MOM2006]

ich kauf mir jetzt 2-Bay NAS Speicher für Zuhause und Büro | 4K-Medienserver – UGREEN NAS DE
kommt zwar von eine chinesischen firma. werde das initial mal testen. keine ahnung ob irgendwas an schadsoftware drinnen ist. ziel wird aber sein mit externen usb für eine ssd. omv auf dieser externen usb lösung laufen zu lassen mit speicher zweier disks oder ssd im raid 1 betrieb, die intern angebunden sind.

synology ist für mich mitterweile dann ein no go. wer samba so kaputt macht, der fliegt bei mir raus. da das die module nicht da sind ist eines, dass aber eine legitime konfig von dem synology konstrukt als fehlerhaft bewertet wird, ist dann untragbar.

 

[tehabe]

also die haben das richtig kaputt gepatched

Es funktioniert anders, Du findest ja in der Konfiguration zum Beispiel:

syno catia = Yes
syno fruit = Yes

 

[tehabe]

Ergänzung, die xattr-Daten werden bei DSM nicht im Dateisystem, sondern im Ordner @eaDir gespeichert. Der enthält bestimmt noch andere sehr wichtige Daten aber wenn du den löschst, sind die xattr-Daten nicht mehr vorhanden.

 

[MOM2006]

@tbo

beides hilft mir aber nichts.

funktioniert denn auf deiner Synology alles richtig? Hast du im Macos custom nsmb.conf oder smb.conf am laufen?

einfach mal probieren einen Ornder ohne erweiterten Attributen von der lokalen MacOS disk auf einen smb share der synology zu kopieren? hat der Ordner auf der Synology dann bei dir erweiterte Attribute wenn du ein ls -la im Terminal im jeweiligen SMB share machst?

was passiert wenn du diese mit xattr -c löschen möchtest?

 

[tehabe]

Also die erweiterten Attribute werden mit kopiert. Und können mit xattr -c nicht gelöscht werden. Wenn ich über ssh mit einlogge und dort die den @eaDir-Ordner lösche, sind sie weg.