Sequoia 15.2 Probleme mit smb shares auf synology nas

- Apple hat ein spezielles macOS mit Dateisystem, Dateihandling, Berechtigungskonzept, .... , das im Falle eines NAS mit einem "Standard-Linux"
einer "Übersetzung" bedarf, damit Dateien "unfallfrei" hin und her kopiert werden können

Sorry, das ist so nicht korrekt.

macOS ist was die Rechte betrifft POSIX kompatibel. Zudem setzt macOS die NFSv4 ACL um. Auch das ist ein Standard. Linux jedoch ist zwar POSIX kompatibel, setzt aber die NFS ACL nicht vollständig um. Die NFSv4 ACL und die Windwos ACL sind auch nicht durchgehend kompatibel.

Ich wiederhole mich:

Das Samba-Projekt hat sich als Ziel gesetzt, Windows-Kompatibilität zu erreichen. Das tun sie. Mein Respekt dafür.

Da Windows ACL aber eben nicht so mit den NFS ACL zusammen passen und auch Linux, auf dem Samba halt läuft, die NFSv4 ACL nicht durchgehend implementiert hat, sondern ein eigenes Süppchen kocht, ist es so wie du sagst, übersetzt Samba die NFS ACL in die unter Linux möglichen ACL und sorgt dafür das ein Windows-Client die nicht mit kriegt.

Es ist nicht so dass Apple irgendwas "spezielles" macht. macOS verwendet einen Standard. Linux implementiert diesen Standard nicht. Und Windows setzt mit seiner Marktmacht einfach seine eigenen Standards.

Edit:

ich muss obiges ergänzen und teilweise korrigieren:

NFSv4 ACL und Windows ACL sind kompatibel. Linux ist das OS, das die nicht vollständig implementiert hat / nutzt.
 
cp -X?
Code:
cp and mv preserve Extended Attributes by default. To copy a file without its Extended Attributes, use cp -X

edit: Bin mir gerade nicht sicher, ob ein Smilie passt oder nicht. :hehehe:
Ich hab mit cp -p oder cp ohne option gearbeitet in beiden Fällen wurden mir die Timestamps zerschossen, was ich ja nicht wollte. Bei GUI Copy bleiben Timestamps erhalten. Somit ist der cp Befehl auch keine option. Vor allem wenn die Anzahl der zu kopierenden Elemente gross ist, wirds dann wieder komplex
 
... tja, da du ja einer der beiden User bist: Ich lasse dich in deinem Glauben.

Was spielt es für eine Rolle was ich glaube? Fakt ist das Problem in der Form ist da und selbst wenn es Apple richtig macht, der Markt und die Hersteller werden sich nach der Mehrheit richten und schauen, dass ihre Geräte damit korrekt funktionieren. Das ist dann halt für die blöd die auf Apple setzen, weil die müssen sich dann Bastellösungen antun, in dem sie irgendwelche Hardwaretrümmer zu einem Eigenbau NAS zusammenstoppeln und dann ein System drauf installieren, dass samba vollwertig konfigurieren lässt. Die Zielgruppe, die das machen wird, ist aber auch überschaubar.

Ich hab auch deine Lösungen bzgl. QNAP gelesen Theoretisch gibt es dieses Entware Repo oder wie man es nennen mag auch für Synology, nur das ist dann halt wieder eine Bastellösung, weil das nächste DSM Update diese Umbauten wieder zerlegen könnte und dann beginnt das Ganze wieder bei Null.
 
Darum geht es nicht.

Entgegen der hier im Forum vorherrscheden Ansicht, dass es an Apple liegen würde, bin ich halt jemand, die sich die Zeit nimmt, Dinge zu ergründen. Das ist nun mal meine Art mit der Welt umzugehen. Wie du sagst, ich bin eine "Spezialistin", okay, ich würde mich eher als sehr neugierig bezeichnen. Und ich kann halt recht gut und schnell Dinge erfassen und analysieren (ist nicht immer eine positive Eigenschaft).

Daher habe ich eben mal das ganze Thema rund um samba angesehen, da auch ich die diversen Unzulänglichkeiten erlebt habe. Der mich am meisten störende Effekt war ein Problem mit den Rechten meines QNAP. Ich hatte da nach den "offiziellen" QNAP Anleitungen und den Beiträgen eines QNAP Forums das NAS eingerichtet. Sollte also eigentlich laufen. Pustekuchen.

Wenn ich da eine Datei, die unter macOS die Rechte -rw-r--r-- hatte (also exakt die Standardrechte, wenn man nichts auf macOS verändert) auf das NAS kopierte und irgendwann später wieder zurück auf den Mac, dann waren die Rechte der zurück kopierten Datei verändert. Und zwar auf -rwx------

Nicht nur waren die Leserechte für Gruppe und other verschwunden, es war auch noch ein executable Bit dazu gekommen.

Hier im Forum würde das, wenn es bemerkt würde, natürlich sofort ein "Beweis" sein, dass Apple smb verhunzt hat, da es bei Windows und Linux nicht passiert.

Diese Art der Logik erinnert mich eher, auch wenn ich damit nun einigen auf die Füße trete, an das berühmte Milchmädchen. Okay, so ein Schluss liegt nahe. Wenn dann aber jemand anderes sagt, dass es an samba liegen würde, dann wir dieser jemand blöd angemacht, "man wolle es nicht wahr haben dass es an Apple liegt", "man verteidige ja nur Apple", "man sei ja nur Fan-Boy" nd all diese Dinge. Besonders zwei der Foristen hier im Forum stechen da ganz besonders raus. Vielleicht liegt es ja auch daran, dass das eine Frau sagt, die noch nicht mal in der IT tätig ist. Da kann dann nicht sein, was nicht sein darf.

Tja, neben der Milchmädchen-Logik gibt es einen anderen Erklärungsansatz habe ich mir gedacht: Das alles wird durch Software gesteuert. Was wäre, wenn diese Software nur dann diese Verhalten zeigt, wenn ein Mac auf das share zugreift. Der Code wird also nur dann durchlaufen, wenn ein Mac erkannt wird. Bei Linux oder Windows Clients wird der Code nicht angewandt. Softwaretechnisch ist sowas durchaus möglich. Der nächste Hinweis für mich war dann, dass es tatsächlich ein Modul in Samba gibt, das explizit für den Mac entwickelt wurde.

Tja, anders als die ganzen Milchmädchen, habe ich mir dann die Frage gestellt, ob es nicht an diesem Modul liegen könnte.

Und so habe ich dann in langer und aufweniger Arbeit die manpages zu samba im Allgemeinen und besonders die des Moduls studiert. Das hat dann schon viele der Unzulänglichkeiten gelöst. Bei diesem Vorgehen wurde dann aber auch meine unstillbare Neugier geweckt und ich wollte den source code des Moduls ansehen und versuchen ob ich was erkenne. Das hat wiederum lange gedauert. Ich musste erst mal erlernen, wie ich unter Debian sourcen so kompiliere und patche, dass sie dem System entsprechen.

Diese Analyse der sourcen hat dann ergeben, dass es dort zwei kleinere Unzulänglichkeiten gibt. _Ich_ nenne das nicht "bug". Jedenfalls habe ich dabei erkannt, dass der Code dieses Moduls nicht durchlaufen wird, wenn ein Linux oder Windows Client auf den Samba-Server zugreift, sondern ausschließlich dann, wenn es ein Mac ist.

Das bedeutete nun für mich, dass die ganzen Aussagen hier im Froum (und anderswo) "mit Windows und Linux klappt es aber" stimmen, aber die Schlussfolgerung "daher ist macOS / Apple Schuld" einfach falsch ist.

Ich habe den Code dann weiter analysiert und schließlich so gepached, dass diese beiden Unzulänglichkeiten nicht mehr auftreten.

Folge all meiner Bemühungen zur Konfiguration und dem Patch des Moduls:

der samba-server verhält sich so wie eine samb-Freigabe eines Macs. Keine Apple-Double-Dateien, keine Veränderung der Rechte, keine unnätigen ACL auf dem Server und das Beste: Windows und Linux sind vom Patch überhaupt nicht betroffen.

Und als ich dieses Wissen dann anfing hier im Forum zu teilen, gab es durchaus User, die das gerne annahmen und begrüßten (Danke an den betreffenden User). Aber es gab und gibt halt auch weiterhin diese User (besonders zwei) die despektierlich darauf reagieren und mich persönlich als "nicht wahr haben wollen" "verteidigt doch eh nur Apple" und und und blöd anmachen. Man sieht das ja auch hier im Thread. Es darf nicht sein, dass es am samba-server liegt. Apple ist shice, macOS ist shice, bla bla bla.

Und nun, glaubt hier jemand, dass ich nach all der Zeit in der ich blöd angemacht werde, noch Lust habe mein Wissen hier im Forum zu teilen?

Und bevor jemand fragt: Die Entwickler-Community im Linux-Umfeld habe ich leider oft genug als eher toxisch erlebt. Wenn da jemand kommt, der nicht schon jahrelang in Entwickler-Communites unterwegs ist und dann noch sagt, dass eine Unzulänglichkeit (ihr seht, ich vermeide sogar hier "big") in einem der ganz großen Open-Source-Projekte vorliegt, der wird nicht sonderlich ernst genommen. Und wenn das dann noch eine Frau ist, dann noch weniger.

Vielleicht schreibe ich mal einen Artikel in meinem blog. Oder ich veröffentliche einfach nur mal den Patch dort. Dann kann jeder damit anfangen was er will. Die Milchmädchen werden es eh nicht ansehen, geschweige denn verstehen.
Danke, ich finde es gut wie Du Dich mit dem Thema beschäftigst und auch Lösungen findest. Wenn ich dort Probleme hätte würde ich Deine Lösungen sicher annehmen. Für mich stellt sich dann nur noch die Frage, was ist mit den vielen Benutzern, die einfach nur "anwenden/nutzen" wollen und nicht so tief einsteigen möchten. Wenn es Dir so einfach möglich ist, warum nimmt Apple diese Möglichkeit auf und bietet es einfach mit an - z.B. als Option, wenn man mit Windows SMB arbeiten möchte.
 
Und bevor jemand fragt: Die Entwickler-Community im Linux-Umfeld habe ich leider oft genug als eher toxisch erlebt. Wenn da jemand kommt, der nicht schon jahrelang in Entwickler-Communites unterwegs ist und dann noch sagt, dass eine Unzulänglichkeit (ihr seht, ich vermeide sogar hier "big") in einem der ganz großen Open-Source-Projekte vorliegt, der wird nicht sonderlich ernst genommen. Und wenn das dann noch eine Frau ist, dann noch weniger.
Das kann ich Bedauerlicherweise bestätigen. Ich hatte vor vielen, vielen Jahren Kernel-Patch geschrieben, weil für ein großes Projekt ich Swap over NFS brauchte.
Anderes mal, hatte ich etwas für Samba gemacht bzw. machen wollen.... ja das sind schon sonderbare Erfahrungen.

Und als ich dieses Wissen dann anfing hier im Forum zu teilen
Egal was jemand macht - es wird immer Leute geben die für Hilfe Dankbar sind und andere die es nicht tun.
Wenn jeder sich durch die sagen wir Kritiker "zurückzieht", wird es "bald" keine Foren mehr geben, weil Millionen von Fragen aber keine Antworten.
Hier noch mal von meiner Seite - solltest Du in einem der letzten Beiträge Dich von mir als "angegriffen" füllen, dann tut es mir leid. Es war nicht meine Absicht, Dich und Deine Kompetenz in Frage zu stellen. Wenn dann vielleicht die Art wie Du "austeilst".

Ach ja - ich nehme dann an, dass Deine Änderungen an dem catia Modul (so fern es sich um diesen handelte), bis heute nicht im offiziellen Code sich finden oder?
 
Wenn es Dir so einfach möglich ist, warum nimmt Apple diese Möglichkeit auf und bietet es einfach mit an - z.B. als Option, wenn man mit Windows SMB arbeiten möchte.

Nochmal ganz deutlich:

Es muss im samba server konfiguriert werden. Und man kann es im samba Server einstellen. Da kann Apple nichts daran drehen. Es ist Sache der Hersteller des NAS das anzubieten.

Zu Windows-Server kann ich nichts sagen, da ich keinen Windows smb Server betreibe. Da aber bspw die ACl die macOS verwendet und die Windows verwendet faktisch identisch sind, verhalten sich auch die clients gleich. Der Unterschied kann dann noch in den macOS eigenen Finder-Infos liegen. Ob Microsoft das in deren smb Server implementiert hat, wei0 ich nicht.

Hier geht es aber halt um NAS-Systeme von Synology und QNAP. Und die basieren halt auf Linux und Samba.
 
Hier geht es aber halt um NAS-Systeme von Synology und QNAP. Und die basieren halt auf Linux und Samba.
So weit korrekt - aber das beschriebene Problem hier mit den erweiterten Attributen die auf Verzeichnisse gesetzt sind und dann nicht gelöscht werden können tritt auch dann auf, wenn der SMB Server eine Windows Freigabe ist. Und bei Windows Servern kann man hier nichts derartiges konfigurieren wie eben bei Samba. Und es ist erstmalig mit MacOS Sequoia aufgetreten, mit Sonoma oder älteren MacOS Versionen existierte das spezielle Problem nicht.

ein xattr -c Ordnername liefert auch auf einen Ordner, der von MacOS mit erweiterten Attributen auf eine Windows Freigabe kopiert wurde diesen Not a Directory Fehler. Für den normalen Betrieb eher irrelevant, fällt auch so gleich gar nicht auf. Nur mir ist es aufgefallen, weil ich die Dateien dann noch extern auf ein exfat sichere und keine AppleDoubles haben will und deswegen immer die erweiterten Attribute vor dem Kopieren von MacOS aus lösche und das klappt auf Verzeichnisse seit Sequoia eben nicht mehr. Bei Dateien klappt es.

Verbindungsabbrüche oder ähnliches hab ich mit dem NAS nicht. Ein weiteres Problem ist im Finder oder auch auf im Terminal mit ls wenn in einem Ordner einige Tausend Dateien sind, dann kann es sein, das MacOS seitig was abstürzt oder die Verbindung getrennt wird. Auch dieses Problem kann ich umgehen.

Das hier ist für mich kein kritischer Fehler aufgrund dessen ich nicht arbeiten könnte. Nur die Workarounds dafür kosten mich halt extra Zeit. Und wie gesagt vor Sequoia existierte dieses Problem auch nicht.
 
Und es ist erstmalig mit MacOS Sequoia aufgetreten, mit Sonoma oder älteren MacOS Versionen existierte das spezielle Problem nicht.
An der Stelle drehst Dich aber im Kreis. Ich glaube alle haben verstanden, dass du vorher das Problem nicht hattest. Jetzt aber schon.
Es ist durchaus möglich, dass Apple in den Versionen etwas verändert hat (bei mir tat die TM nicht mehr und ich musste tricksen).
Du hast jetzt zwei Möglichkeiten (aus meiner Sicht)
1. @lisanet doch noch um Hilfe bitten und die Vorschläge umsetzen. Zu der Standardkonfiguration kommst du doch immer
2. Nichts tun ich sich weiter ärgern.

In wie weit man als User bei den Synology NAS die Konfiguration verändern kann, die dann auch Reboot usw. überleben weiß ich nicht. Wenn ich es richtig verstanden habe hat @lisanet QNAP und da geht es scheinbar, kann gut sein, dass es bei Synology auch geht, vielleicht aber nicht6.

Zu dem Verhalten bei Windows. Wenn Apple etwas verändert hat und danach sieht es aus, dann kannst du schon mal Wetten abschliessen, dass Microsoft nichts ändern wird. Vielleicht wird Apple die Änderungen wieder Rückgängig machen wenn z.B es zu viel Ärger macht und sich größere Firmen (gibt es das überhaupt) deswegen bei Apple/ Service melden.
 
Es ist durchaus möglich, dass Apple in den Versionen etwas verändert hat (bei mir tat die TM nicht mehr und ich musste tricksen).

Natürlich lässt sich das nicht ausschliessen. Ich glaube das wurde hier mehrfach geschrieben.

2. Nichts tun ich sich weiter ärgern.

3. wieder das macOS installieren das keine - oder diese Probleme bzw. nicht hat.

Alternativ das neueste macOS, welches man meint unbedingt zu brauchen, auf eine separate Partition, so kann man damit testen und eine einfache Auswahl des Startvolume bringt den Nutzer in die Position zu entscheiden was er will. Entweder neue Versionsnummer oder einen störungsfreien Betrieb - wie vorher.

In wie weit man als User bei den Synology NAS die Konfiguration verändern kann, die dann auch Reboot usw. überleben weiß ich nicht.

Im Prinzip habe ich mich immer daran gehalten und seltenst damit mal ein Problem gehabt, ausser Apple hat ein neues erschaffen.
https://kb.synology.com/de-de/DSM/help/SMBService/smbservice_smb_settings?version=7

Ob die ältere Ausgabe für DSM 6 davon auch noch dort zu finden ist weiß ich nicht.
 
Ach ja - ich nehme dann an, dass Deine Änderungen an dem catia Modul (so fern es sich um diesen handelte), bis heute nicht im offiziellen Code sich finden oder?

es betrifft nicht catia sondern fruit. Und ja, der patch ist nicht im offiziellen Code. Ich habe noch keine Lust auf die dann folgenden Diskussionen gehabt.

Wenn du weißt, wie man samba selbst kompiliert, würde ich den Patch als download zur Verfügung stellen.
 
Wenn ich es richtig verstanden habe hat @lisanet QNAP und da geht es scheinbar,

Nein, ich hatte ein QNAP aber damit eben diverse Probleme und Unzulänglichkeiten erlebt, was mich zuerst dazu bewogen hat, das QNAP zu patchen und als das einfach zu stressig wurde mit entware zu arbeiten, habe ich das QNAP verkauft und verwende seither openmediavault.
 
Wenn du weißt, wie man samba selbst kompiliert, würde ich den Patch als download zur Verfügung stellen.
An sich schon und Danke für Dein Angebot.
Ich verwende TrueNAS und zwar in Core Version was FreBSD basiert. Wie ich da ggf. es kompilieren könnte habe ich ehrlich gesagt noch gar nicht geschaut.
Es läuft ja alles (bis auf die genannte Trinkerei mit Time Machine). Immer wieder habe ich mir überlegt auf die TrueNAS SCALE Version zu wechseln (die ist Linux basierend), aber zum einem fehlt mir die Zeit und viel wichtiger - ein wenig "Dusel" habe ich schon, dass bei der Migration doch etwas schief läuft und ich aber ganz schön blöd da stehe und im schlimmsten Fall eine Großbaustelle aufmache die ich nicht haben will.
 
Ich nutze z.Z. QNAP mit aktueller Firm-/Software. Bei mir funktioniert alles was ich will, auch mit Time Machine keine Probleme. Bei den aktuellen Versionen gibt es einen SMB-Dienst, der auch ständig aktuell gehalten wird; (AFP) wird natürlich auch unterstützt). Der Dienst kann dann auch im ControlPanel z.T. konfiguriert werden. Ich habe z.B. SMB-Mehrkanal aktiviert, weil ich die Server von mehreren Clients gleichzeitig nutze. Bei älteren Versionen kann es z.B. Probleme mit Time Machine geben. Den Zugriff auf die Freigaben kann man auch einschränken. Vielleicht hilft dies anderen QNAP Nutzern
 

Anhänge

  • SMB-1.png
    SMB-1.png
    80,6 KB · Aufrufe: 28
  • SMB-2.png
    SMB-2.png
    69,6 KB · Aufrufe: 23
  • SMB-3.png
    SMB-3.png
    103,6 KB · Aufrufe: 23
  • SMB-4.png
    SMB-4.png
    121,8 KB · Aufrufe: 23
  • SMB-5.png
    SMB-5.png
    59 KB · Aufrufe: 23
  • SMB-6.png
    SMB-6.png
    236,3 KB · Aufrufe: 26
Ich habe z.B. SMB-Mehrkanal aktiviert, weil ich die Server von mehreren Clients gleichzeitig nutze.
Nach meinem Verständnis hat das Eine mit dem Anderen so ziemlich genau garnix zu tun.
  • mehrere SMB-Clients geht immer, ging schon immer. Auch ohne Trick 17 mit Selbstüberlistung.
  • SMB-Mehrkanal heißt lediglich, dass ein (in Worten: 1) Client mehrere Kanäle gleichzeitig öffnen und nutzen darf, um noch das letzte bisschen Performance herauszukitzeln.
Also so ungefähr das Gegenteil dessen, was du dir erhoffst.
 
Nach meinem Verständnis hat das Eine mit dem Anderen so ziemlich genau garnix zu tun.
  • mehrere SMB-Clients geht immer, ging schon immer. Auch ohne Trick 17 mit Selbstüberlistung.
  • SMB-Mehrkanal heißt lediglich, dass ein (in Worten: 1) Client mehrere Kanäle gleichzeitig öffnen und nutzen darf, um noch das letzte bisschen Performance herauszukitzeln.
Also so ungefähr das Gegenteil dessen, was du dir erhoffst.
Die Praxis zeigt leider andere Ergebnisse. Ein Client an einem LAN Switch an dem einen Port vom NAS Server, der andere Client an einem zweiten LAN Switch an dem anderen Port - beide starken Datentransfer - Der NAS Server mit automatischem SMB-Mehrkanal teilt es optimal auf, die Jobs sind schneller erledigt.
 
Das hier beschriebene Problem ist weiterhin mit MacOS 15.5 vorhanden - sowohl auf Shares bereitgestellt von Synology als auch auf Shares bereitgestellt von Windows 11 Pro.
 
Das Samba-Projekt hat sich als Ziel gesetzt, Windows-Kompatibilität zu erreichen. Das tun sie. Mein Respekt dafür.
Die verdienen sogar noch viel mehr Respekt! Es gab eine Zeit zu Samba1 Samba2, da hat Microsoft in seiner menschenverschleissenden Art alle Programmierer aus dem Segment aus der Firma gedrängt. Microsoft selbst hatte keine Doku zur Funktionsweise von SMB. Sie mußten das selbst mit dem Wissen der Samba-Leute wieder erarbeiten um damit zu NTFS und weiter zu kommen.

Was Samba configs angeht, die können sehr komplex und umfangreich sein. Und wer so etwas konfektioniert betreibt der muß sich halt auch darum kümmern (Synology oder QNAP oder ...). Das erfolgt mal mehr mal weniger gut. Linux und Macos sind da meist radikaler in ihrem Verhalten, funktioniert etwas nicht in der Norm gibt es eben Fehler. Microsoft hat schon seit den Plug&Play tagen das Verhalten dem User erstmal zu suggerieren "alles ist gut". Daher kommt auch die fatale Einschätzung "unter Windows funktioniert das aber". Ja tut es, aber die machen viele Klimmzüge unter der Oberfläche und das an allen Fronten. Eine der Gründe warum das System nicht so unmittelbar und schnell reagiert.

Mir ist es lieber eine dysfunktionalität wird aufgedeckt und dann behoben und ich finde dann einen Weg damit zu arbeiten. als dass ein System damit beschäftigt ist gegen alle Unwägbarkeiten einen prozeß am Laufen zu halten, der dann eben nie performant wird. Übertragt doch mal von einem Windows einen Ordner mit n GB auf einen anderen oder ein NAS. Da kann man seeehr lange zusehen.
 
Übertragt doch mal von einem Windows einen Ordner mit n GB auf einen anderen oder ein NAS. Da kann man seeehr lange zusehen.
Das liegt aber nicht am SMB Protokoll, sondern eher an verkackten Default Einstellungen von Microsoft in Windows auf Netzwerkkarten und TCP Ebene.

Im übrigen wenn sich MacOS an den Standard hält und radikaler ist, stellt sich mir die Frage warum unter Sonoma das hier beschriebene Problem mit Erweiterten Dateiattributen auf Ordnern nicht existierte. Hat Apple erst mit Sequoia auf seine eigene SMB Implementierung geswitched?
 
Im übrigen wenn sich MacOS an den Standard hält und radikaler ist, stellt sich mir die Frage warum unter Sonoma das hier beschriebene Problem mit Erweiterten Dateiattributen auf Ordnern nicht existierte. Hat Apple erst mit Sequoia auf seine eigene SMB Implementierung geswitched?
JEDER der auf so einem Komplexitätsgrad Software erstellt macht Fehler! Manchmal werden Fehler durch Reparaturversuche sogar noch schlimmer oder sie sind nicht mal sofort behebbar. Das kommt leider vor.

Die genauen Ursachen kann ich Dir nicht mal sagen - ich vermute sie sind ggf. auch gar nicht öffentlich lesbar. Ich jedenfalls arbeite noch mit Sonoma und habe seit eh und je auch Probleme mit meinem Synology NAS. Der neue Rechner wird Sequoia haben und ja ich rechne auch da wieder mit Problemen. Kann ich hier ja schon nachlesen.
 
m übrigen wenn sich MacOS an den Standard hält und radikaler ist, stellt sich mir die Frage warum unter Sonoma das hier beschriebene Problem mit Erweiterten Dateiattributen auf Ordnern nicht existierte.

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.

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.

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.

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

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.
 
Zurück
Oben Unten