Sequoia 15.2 Probleme mit smb shares auf synology nas

und win11 verwendet da kein samba?
Nein. Microsoft ist eigentlich das, das Samba und andere Nachbauen wollen. Im Prinzip verwendet Windows 11 smbv3. Nur das gibt es halt keine smb.conf wo man irgendwelche Module oder was auch immer setzt. Und Linux kann auch mit diesen Shares, so wie mit den Shares einer Synology korrekt umgeben.

sequoia mit finder schreibt etwas, das es ihm nachhinein selbst nicht mehr entfernen kann, weil der jeweilige Aufruf dafür in MacOs den Fehler not a Directory erhält, was ja falsch ist, weil es ist ja ein Verzeichnis und der Finder und Terminal kann da auch reinwechseln.
 
Warum sollte Windows Samba nutzen? Das ist "das Problem" mit Samba und anderen Sachen - fast immer hinter Änderungen/ Neuerungen die Microsoft einführt hinterher rennen. Wobei in letzten Jahren, da M$ sich an OS (Open Source) Projekten auch beteiligt stark verändert.
na, weil ich mich nur frage, über welches Protokoll sich der Mac dann zum Win-Rechner verbindet.
Wenn es nicht smb ist, was ist es dann?
 
Nach all diesen Test bleibt für mich das Fazit die MacOS Implementierung von SMB hat Bugs. In der gui wird einem das so gar nicht bewusst. Im Terminal sieht man es.

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.
 
Nach all diesen Test bleibt für mich das Fazit die MacOS Implementierung von SMB hat Bugs. In der gui wird einem das so gar nicht bewusst. Im Terminal sieht man es.

Vielleicht könnte jemand von omv oder diy NAS. mal einen Ordner im Finder, der Dateien enthält. auf einen Share am NAS konfigurieren. 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.
Also ich verstehe das nicht.
Aber wenn du mal genauer auflistest was ich tun soll, dann tue ich es.
 
na, weil ich mich nur frage, über welches Protokoll sich der Mac dann zum Win-Rechner verbindet.
Wenn es nicht smb ist, was ist es dann?
Dann hast Du Deine Frage falsch formuliert oder ich habe sie falsch verstanden.
Microsoft verwendet schon immer SMB.
Samba Projekt ist damals ins Leben gerufen worden um "etwas anderes" als Windows Server verwenden zu können um SMB Shares bereitzustellen. Die Probleme waren damals auch vorprogrammiert, denn vor Jahren hielt Microsoft absolut nichts von allem was nicht kommerziell war und Open Source war den richtiges Dorn im Auge. Das hat sich in den letzten Jahren stark verändert, da man eingesehen hat, dass diese Konstellation durchaus auch Vorteile und damit für M$ Geld bringt.
Dennoch ist M$ die Firma die am Ende Änderungen am SMB Protokoll absegnen muss. Zum Glück passiert es jetzt mit Vorlaufzeit und entsprechender Ankündigung, so dass Samba-Projekt sich darauf vorbereiten kann.
 
Also ich verstehe das nicht.
Aber wenn du mal genauer auflistest was ich tun soll, dann tue ich es.
kein Problem.

Erstelle in deinem Homeverzeichnis auf der lokalen Disk einen Ordner TempCopy. kopiere ein paar Dateien in diesen Ordner rein. dann kopierst du mit dem Finder diesen Ordner auf einen Share deines NAS Systems.

danach startest du ein Terminal und wechselst auf den Share wo du hinkopiert hast. bei mir wäre das /Volumes/xxx die anderen Befehle stehen im folgenden Codeteil:

Code:
xxx@imac-xxx ~ % cd /Volumes/xxx
xxx@imac-xxx xxx % ls -la
total 304
drwx------  1 xxx     staff  16384 11 Mai 17:11 .
drwxr-xr-x  4 root    wheel    128 11 Mai 17:10 ..
-rwx------@ 1 xxx     staff  14340  4 Apr 10:25 .DS_Store
-rwx------  1 xxx     staff     81 29 Dez 00:03 .vimrc
-rwx------  1 xxx     staff     18 29 Dez 00:03 .zshrc
drwx------  1 xxx     staff  16384 12 Jan 21:53 Bilder
drwx------  1 xxx     staff  16384 23 Feb 16:02 Dokumente
drwx------  1 xxx     staff  16384 12 Jan 21:52 Downloads
drwx------  1 xxx     staff  16384 12 Jan 21:52 Filme
drwx------  1 xxx     staff  16384  8 Jan 12:02 Musik
drwx------  1 xxx     staff  16384 31 Dez 01:27 root
drwx------@ 1 xxx     staff  16384 11 Mai 17:11 TempCopy
xxx@imac-xxx xxx % xattr -l TempCopy
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:
xxx@imac-xxx xxx % xattr -c TempCopy
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
 
kein Problem.

Erstelle in deinem Homeverzeichnis auf der lokalen Disk einen Ordner TempCopy. kopiere ein paar Dateien in diesen Ordner rein. dann kopierst du mit dem Finder diesen Ordner auf einen Share deines NAS Systems.
Done.
- Ordner TemCopy in meinem Home erstellt
- Dateien rein
- Share auf NAS gemountet
- mit Finder Dateien reinkopiert
Code:
MacBookPro:jt - /Users/jt
> ls -la
total 144
drwxr-x---+  41 jt    staff   1312 11 Mai 17:18 .
drwxr-xr-x    5 root  admin    160  7 Mai 10:01 ..
drwxr-xr-x@   3 jt    staff     96 16 Jan 13:07 .aspnet
....
drwx------   29 jt    staff    928 11 Mai 17:19 .zsh_sessions
-rw-r--r--@   1 jt    staff    460  4 Mai 18:28 .zshrc
drwx------@  16 jt    staff    512 10 Mai 10:09 Applications
drwxr-xr-x@   8 jt    staff    256  5 Mär 18:31 Backups
drwxrwxrwx   14 jt    staff    448  4 Mai 17:46 bin
drwx------@   9 jt    staff    288 11 Mai 15:02 Desktop
drwx------+  13 jt    staff    416  5 Mär 17:37 Documents
drwx------@  11 jt    staff    352 11 Mai 17:18 Downloads
drwx------@ 114 jt    staff   3648  8 Mär 14:39 Library
drwx------@  12 jt    staff    384 28 Mär 11:28 Movies
drwx------+   6 jt    staff    192 18 Dez 13:47 Music
drwx------+  13 jt    staff    416 18 Dez 18:01 Pictures
drwxr-xr-x+   5 jt    staff    160 25 Sep  2024 Public
drwxr-xr-x    6 jt    staff    192 11 Mai 17:18 TemCopy
drwxr-xr-x    3 jt    staff     96 23 Mär 18:57 tmp

Code:
MacBookPro:jt - /Users/jt/TemCopy
> ls -la
total 10448
drwxr-xr-x   6 jt  staff      192 11 Mai 17:18 .
drwxr-x---+ 41 jt  staff     1312 11 Mai 17:18 ..
-rw-r--r--@  1 jt  staff   269422 28 Dez 10:36 DIY-NAS-HW.jpg
-rw-r--r--@  1 jt  staff   312781 29 Dez 13:36 DIY-NAS-SW.jpg
-rw-r--r--@  1 jt  staff   277617 29 Mär 00:02 folder.jpg
-rw-r--r--@  1 jt  staff  4484807 11 Feb 09:51 i_wertpapiere.pdf

danach startest du ein Terminal und wechselst auf den Share wo du hinkopiert hast. bei mir wäre das /Volumes/xxx die anderen Befehle stehen im folgenden Codeteil:

Code:
xxx@imac-xxx ~ % cd /Volumes/xxx
xxx@imac-xxx xxx % ls -la
total 304
drwx------  1 xxx     staff  16384 11 Mai 17:11 .
drwxr-xr-x  4 root    wheel    128 11 Mai 17:10 ..
-rwx------@ 1 xxx     staff  14340  4 Apr 10:25 .DS_Store
-rwx------  1 xxx     staff     81 29 Dez 00:03 .vimrc
-rwx------  1 xxx     staff     18 29 Dez 00:03 .zshrc
drwx------  1 xxx     staff  16384 12 Jan 21:53 Bilder
drwx------  1 xxx     staff  16384 23 Feb 16:02 Dokumente
drwx------  1 xxx     staff  16384 12 Jan 21:52 Downloads
drwx------  1 xxx     staff  16384 12 Jan 21:52 Filme
drwx------  1 xxx     staff  16384  8 Jan 12:02 Musik
drwx------  1 xxx     staff  16384 31 Dez 01:27 root
drwx------@ 1 xxx     staff  16384 11 Mai 17:11 TempCopy
[/QUOTE]

[/QUOTE]

[QUOTE="MOM2006, post: 12578917, member: 186245"]
[CODE]MacBookPro:jt - /Volumes/dokumente
> ls -la
total 160
drwx------@ 1 jt    staff  16384 11 Mai 17:19 .
drwxr-xr-x  5 root  wheel    160 11 Mai 17:10 ..
-rw-r--r--  1 jt    staff  12292 13 Nov 18:54 .DS_Store
drwxr--r--  1 jt    staff  16384  3 Feb 03:00 .duplicacy
-rw-r--r--  1 jt    staff      0 23 Jul  2022 .localized
drwx------  1 jt    staff  16384  5 Mär 17:37 Documents
drwxr-xr-x  1 jt    staff  16384 11 Mai 17:18 TemCopy


xxx@imac-xxx xxx % xattr -l TempCopy
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:

Code:
MacBookPro:jt - /Volumes/dokumente
> xattr -l TemCopy
MacBookPro:jt - /Volumes/dokumente
>

xxx@imac-xxx xxx % xattr -c TempCopy
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
[/CODE]
Bei mir gibt es da nichts zu löschen
 
ok alles klar. in der Konstellation dritt das also nicht auf.

der output vom befehl mount im terminal liefert bei mir für den share


Code:
//xxx@diskstation/diskstation/private/xxx on /Volumes/xxx (smbfs, nodev, nosuid, mounted by xxx)

vielleicht hast du da noch andere optionen drinnen.
 
Zuletzt bearbeitet von einem Moderator:
ok alles klar. in der Konstellation dritt das also nicht auf.

der output vom befehl mount im terminal liefert bei mir für den share


//xxx@diskstation/diskstation/private/xxx on /Volumes/xxx (smbfs, nodev, nosuid, mounted by xxx)

vielleicht hast du da noch andere optionen drinnen.

Code:
//jt@omv.local./dokumente on /Volumes/dokumente (smbfs, nodev, nosuid, mounted by jt)
 
Zuletzt bearbeitet von einem Moderator:
Bitte auch für die „kleinen Code-Schnipsel“ die Code-Tags verwenden, da oft das @ drin sein kann, was im Editor geparst werden kann.
 
Auch wenn @lisanet es nicht wahrhaben will (kommt zumindest bei mir so an), ist es schon traurig, dass Apple hier "auch" eigene Suppe kocht. Das alleine ist schon eher schlecht. Viel schlechter finde ich aber die Tatsache (vielleicht habe ich es auch bis jetzt nur nicht gefunden), dass es von Apple selbst keine Dokumentation gibt wie die Konfiguration aussehen soll.

Ich muss nichts wahrhaben wollen.... Apple hat mit sambe rein gar nichts zu tun.

Und wie eine Konfiguration für macOS auszusehen hat, steht klar und deutlich in den manpages des samba Projektes. Man muss sie halt lesen.

Und wenn Synology, wie ich jetzt erfahren habe, eigene vfs Module entwickelt hat, die dann ausgerechnet mit denen des samba Projektes kollidieren, die für Kompatibilität mit macOS veorhanden sind... tja, dann wundert es mich gar nicht mehr, dass da halt nicht alles korrekt läuft.

Aber da ich hier im Forum regelmäßig von irgendwelchen Usern (es gibt wenige Ausnahmen) angemacht werde, weil ich nicht auf Apple schimpfe wenn es um smb geht, sondern auf die NAS-Hersteller verweise, sorry, aber da habe ich einfach keinen Bock mehr, hier im Forum Hilfe zur config von samba zu geben. Wie gesagt, es steht alles in den manpages. Und gepostet habe ich es auch schon. Und wie ich auch schon x mal erwähnt habe, ich habe sogar das maßgebende vfs Modul gepached um 2 kleine Unzulänglichkeiten auszubügeln. Das Ergebnis bei mir habe ich auch schon x mal genannt: Mein samba Server verhält sich so wie eine smb-Freigabe eines Macs. Daher: es liegt nicht an macOS, sondern an der config von samba und/oder (wegen der kleinen Unzulänglichkeiten) am maßgebenden vfs Modul.

Daher wie eingangs geschrieben: ich muss nichts wahrhaben wollen: es liegt nicht an macOS.
 
NAS-Hersteller optimieren ihre Konfiguration für Windows, was durchaus verständlich ist, da Windows einen drastisch höheren Marktanteil hat. Zudem ist es erklärtes Zeil des samb-Projektes Windows-Kompatibilität zu erreichen, was auch wunderbar gut gelingt. macOS wird dabei lediglich ein einem Modul angesprochen.

Mit Hilfe dieses Moduls und ein paar weiteren Einstellungen (die nicht den Standard-Einstellungen für Windows entsprechen) ist es dann möglich, dass sich ein samba-Server so verhält, wie ein smb-Freigabe, die ein Mac bereit stellt.

Sprich: es werden keine Apple-Double-Dateien angelegt, Zugriffsrechte werden nicht verändert, ACL werden nicht genutzt, keine unnötigen erweiterten Attribute erzeugt, etc. Ebenso, wie es auch eine smb-Freigabe eines Macs macht. Ob die beiden großen NAS-Hersteller das über ihre GUI anbieten weiß ich nicht, als ich noch ein QNAP hatte, war es dort nicht der Fall.

Da ich dann dort mit dem QNAP halt auch so einige der Probleme hatte, die hier im Forum immer wieder hoch kommen, die jahrelang mit einem einfachen samba-server eines Linux-Rechners nicht auftraten, habe ich eben festgestellt, dass es nicht an macOS liegt, sondern an der konkreten Konfiguration des samba-Server. Als Folge habe ich dann das QNAP verkauft und nutze seither eben ein System, dass es mir erlaubt, die samba-Konfiguration in allen Belangen selbst vorzuehmen. Seither kenne ich dies Probleme mit den oben erwähnten Punkten nicht mehr.

Und all das habe ich in etlichen meiner Postings shcon geschrieben. Es wird aber mindestens genauso oft von anderen Usern verneint, dass es nicht an der samba-Konfiration liegen würde, wenn Probleme auftreten, sondern an macOS. Tja, und mittlerweile bin ich es leid, mich immer wieder zu wiederholen und die Lösungen zu posten.

Wer tätstächlich ein Interesse an Lösungen hat und die samba-Konfiruation seines NAS selbst einstellen kann und weiß, wie das abseits der gUI senes NAS-Herstellers geht, der kann gerne einen Thread eröffnen und fragen. ich werde gerne helfen. Aber ich helfe nicht den dauernden "macOS ist Schuld"-Fans. Die sind mir zu wenig aufgeschlossen.
Du bist mit Sicherheit ein Spezi und steckts tief im Thema. Es ist auch ok zu dem MacOs zu stehen. Ich habe mit meinen QNAP NAS Servern keine Probleme mit SMB und auch sonst nicht. Meine verschiedenen Betriebssysteme MacOS, Windows, Linux können alle mit den NAS Servern arbeiten.
Es ist für dich als Spezi leicht die Samba Konfiguration mal eben "anzupassen". Die vielen Anwender die Apple System kaufen, weil sie einfach und bedienerfreundlich sind, sollen sich also alle in dem Thema einarbeiten nur weil "apple" sich nicht etwas "offener" zeigt? Alle anderen OS können das auch. Es ist keine Frage der Schuld, sondern lediglich eine Möglichkeit auch andere OS zu akzeptieren.
 
Wenn es, wie hier nur Synology wäre. Eine Freigabe in Windows 11 Pro konfiguriert, liefert das gleiche Phänomen beim Kopieren von einem Ordner mit Finder auf den Windows share. Interessanterweise werden erweiterte Attribute wohl richtig geschrieben und gelesen für Dateien. Im Windows gibt es auch keine appledouble files.

nur bei xattr -c auf das Verzeichnis zum löschen all dieser Attribute kommt eben der Fehler xattr: [Errno 20] Not a directory:

Konkret dabei geht es eben um die Finder Extended Attribute um einen Copy Job zu resumen oder neuzustarten.

Nur ob ich das Windows je austreiben könnte und dort ähnliche Module wie bei Samba hätte?
 
Ich muss nichts wahrhaben wollen
Natürlich nicht, ist ja Deine Entscheidung.
Apple hat mit sambe rein gar nichts zu tun.
So die Theorie, die Praxis sieht allerdings etwas anders aus.

Aber da ich hier im Forum regelmäßig von irgendwelchen Usern (es gibt wenige Ausnahmen) angemacht werde, weil ich nicht auf Apple schimpfe wenn es um smb geht
K.A warum Du auf immer auf Kritik so allergisch reagierst.
sondern auf die NAS-Hersteller verweise
Und hier sehen wir die Sache etwas anders. Du verweist auf NAS Hersteller, ich erwarte eher, dass hier die "Hilfestellung" von Apple kommt.
aber da habe ich einfach keinen Bock mehr, hier im Forum Hilfe zur config von samba zu geben.
Gezwungen ist keiner von uns etwas zu tun oder auch nicht.
Wie gesagt, es steht alles in den manpages. Und gepostet habe ich es auch schon. Und wie ich auch schon x mal erwähnt habe, ich habe sogar das maßgebende vfs Modul gepached um 2 kleine Unzulänglichkeiten auszubügeln.
Und was meinst Du von 1000 Leuten wie viele sind in der Lage die Manpages zu lesen und verstehen?
Es ist immer einfach zu sagen RTFM, nur das ist aus meiner Sicht genau so falsch wie immer etwas "blöd" fragen.

Und wie ich auch schon x mal erwähnt habe, ich habe sogar das maßgebende vfs Modul gepached um 2 kleine Unzulänglichkeiten auszubügeln.
Auf die Gefahr, dass Du es wieder in falschen Hals bekommst obwohl zumindest ich Dir nichts will. Wie wäre es, wenn Du es in dem weiter oben genannten Forum zusammenfasst? Damit wäre allen, also auch Dir geholfen. Man kann dann nämlich auf den "einen" Beitrag verweisen und nicht pauschal schreiben "steht irgendwo in tiefen des Forums".
Ich selbst habe m NAS (TrueNAS) so weit in Griff und bis auf die TM die ich "anders" austricksen musste läuft MacOS, Windows, FreeBSD wie auch Linux perfekt damit. Großteil der Leute so verstehe ich es hier, nutzen aber "fertige" Kisten von Synology, QNAP und wie die alle heißen. Für die ist es schon deutlich schwieriger, weil die meisten von denen entweder nicht wollen oder einfach nicht können da etwas an der Konfiguration "kompliziertes" machen.
 
@ObiTobi nach dem sich das Verhalten und der hier beschriebene Fehler auch Auftritt, wenn der SMB Server ein Windows 11 Pro ist, ist das sowieso weitreichender, denn im Windows sind mir keine solchen VFS Module bekannt. Insofern liegt es dann wohl doch in der Implementierung diverser Apple Komponenten, die dann Dinge machen mit denen sie späterhin nicht umgehen können.

Besagte erweiterte Attribute hier setzt der Finder beim Kopieren um eben bei einem Abbruch des Jobs diesen wieder fortsetzen könnte. Generell aber blöd, wenn dann vom Tool zum Löschen der Attribute in MacOS das Verzeichnis nicht als Verzeichnis erkannt wird oder eben so agiert, dass der Server den Fehler nicht ein Verzeichnis zurück gibt.

Das die Berechtigungen 700 sind, is halt so betrifft ja dann nur mal MacOS so. Alles andere wo der User dort keine Schreib oder Löschberechtigungen hat, wird ja korrekt umgesetzt. Theoretisch müsst man die 700 auch am Client mit Mount Optionen Anpassen können, wenn sie schon der Server nicht anders liefern kann.
 
Die vielen Anwender die Apple System kaufen, weil sie einfach und bedienerfreundlich sind, sollen sich also alle in dem Thema einarbeiten nur weil "apple" sich nicht etwas "offener" zeigt? Alle anderen OS können das auch. Es ist keine Frage der Schuld, sondern lediglich eine Möglichkeit auch andere OS zu akzeptieren.

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.
 
auf Windows Freigegebene Ressourcen agieren mit MacOS aber genau wie die QNAP, Synology Implementierungen, blos das es für Windows keine Module oder Config Möglichkeiten in dem Sinne gibt, damit MacOS Clients "richtig arbeiten".

Und wenn nun MacOS erweiterte Attribute auf Ordner schreibt, die dann aber nicht gelöscht werden können, weil Not a Directory als Fehler beim Aufruf von xattr Befehl kommt, dann muss entweder Apple oder Microsoft was ändern, weil es schlichtweg nicht miteinander kompatibel ist. In Samba gibt es halt Module mit denen man da korrigieren könnte. Nur QNAP sagt nein, Synology sagt nein, Microsoft sagt nein, vermutlich Ugreen wird auch nein sagen. Da bleibt dann nur noch der selbst gestrickte NAS Server auf einer, wie auch immer gearteten, Linux Ausprägung wo man mit smb.conf dem Verhalten gegen wirkt oder Apple bewegt sich. Was hilft es wenn der Finder resume Attribute setzt, wenn er dann damit weder resumen noch sonst was damit anfangen kann, weil intern ein Fehler kommt.

edit: und ja welche alternativen gibt es dann noch fernab der Cloud um Daten im Eigenen Netz für mehrere Clients zur Verfügung zu stellen? das eigene AFP haut ja apple demnächst auch weg.
 
edit: und ja welche alternativen gibt es dann noch fernab der Cloud um Daten im Eigenen Netz für mehrere Clients zur Verfügung zu stellen? das eigene AFP haut ja apple demnächst auch weg.
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 glaube, dass die Probleme in folgendem begründet sind
- 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
- diese Übersetzung macht der Samba-Server
- Dummerweise hat macOS nur einen Marktanteil von ca 10%
Also:
- die NAS Hersteller fokussieren sich auf Windows. Linux ist eh kein Problem, da die NAS in der Regel auf Linux basieren
- Microsoft hat sowieso kein Interesse ihren "SMB-Server" , oder wie sie ihn nennen, für Apple anzupassen oder konfigurierbar zu machen

Und wenn ich das technisch halbwegs verstanden habe, dann frage ich mich: wie soll denn Apple seinen smb-client anpassen, ohne dass die eigenen macOS Konzepte verloren gehen?
Natürlich könnten sie sagen: "vor der Übertragung per smb schmeissen wir alles über Bord, was nicht "Standard-Linux" oder "Standard-MS" ist ...
Ich denke aber nicht, dass Apple dies will, zumal es die passenden Möglichkeiten der Einstellungen im samba-server gibt.
 
auf Windows Freigegebene Ressourcen agieren mit MacOS aber genau wie die QNAP, Synology Implementierungen, blos das es für Windows keine Module oder Config Möglichkeiten in dem Sinne gibt, damit MacOS Clients "richtig arbeiten".

Und wenn nun MacOS erweiterte Attribute auf Ordner schreibt, die dann aber nicht gelöscht werden können, weil Not a Directory als Fehler beim Aufruf von xattr Befehl kommt, dann muss entweder Apple oder Microsoft was ändern, weil es schlichtweg nicht miteinander kompatibel ist. In Samba gibt es halt Module mit denen man da korrigieren könnte. Nur QNAP sagt nein, Synology sagt nein, Microsoft sagt nein, vermutlich Ugreen wird auch nein sagen. Da bleibt dann nur noch der selbst gestrickte NAS Server auf einer, wie auch immer gearteten, Linux Ausprägung wo man mit smb.conf dem Verhalten gegen wirkt oder Apple bewegt sich. Was hilft es wenn der Finder resume Attribute setzt, wenn er dann damit weder resumen noch sonst was damit anfangen kann, weil intern ein Fehler kommt.

edit: und ja welche alternativen gibt es dann noch fernab der Cloud um Daten im Eigenen Netz für mehrere Clients zur Verfügung zu stellen? das eigene AFP haut ja apple demnächst auch weg.

... tja, da du ja einer der beiden User bist: Ich lasse dich in deinem Glauben.
 
Zurück
Oben Unten