Sequoia 15.2 Probleme mit smb shares auf synology nas

[MOM2006]

achja ganz wertfrei

einziges Issue das ich habe, ich kann Kopierjobs im Finder nicht abbrechen, das wird ignoriert, vermutlich wegen dem Problem mit den erweiterten Attributen.

Sequoia - MacOS 15.5 - Kann Kopiervorgang nicht abbrechen | MacUser.de Community ob der Themensteller das gleiche Problem hatte, die Jobs haben sich nicht abbrechen lassen. Selbst testen werde ich nicht wie smb von sequoia zu sequoia sich hier verhält.

 

[ObiTobi]

Dann lies mal hier:

Bist Du sicher, dass Du mein Zitat und Beitrag gelesen hast? Es ging nämlich um etwas anderes

 

[jteschner]

hast du die externen platten als RAID konfiguriert wegen Ausfallssicherheit?

Nein. Die beiden ssd sind mit mergerfs gebündelt und ich mache ein automatisches tägliches rsync Backup auf meine alte Synology.
Bei notwendigem Austausch einer der beiden ssd spiele ich einfach per rsync zurück.
mergerfs ist für mich eine der genialsten Sachen überhaupt, um verschiedenste Platten flexibelst zusammenzuschalten und ist bei omv als Plugin verfügbar

 

[jteschner]

Bist Du sicher, dass Du mein Zitat und Beitrag gelesen hast? Es ging nämlich um etwas anderes

Eigentlich schon. Du hast mich in #88 zitiert (catia), und u.a. kommentiert, dass das sinnlos ist aber dass du nicht extra nachgelesen hast, und ich habe dir die passende man-page zum nachlesen geschickt.
Wenn ich da was misverstanden habe, dann belassen wir es dabei.

 

[ObiTobi]

Du hast mich in #88 zitiert (catia), und u.a. kommentiert,

Ja und um dieses Modul ging es mir nicht um das von Dir verlinkte fruit. Vielleicht stehe ich aber gerade auf dem Schlauch.
Fruit habe ich natürlich auch in meiner Konfiguration, Catia nicht.

 

[jteschner]

Ja und um dieses Modul ging es mir nicht um das von Dir verlinkte fruit. Vielleicht stehe ich aber gerade auf dem Schlauch.
Fruit habe ich natürlich auch in meiner Konfiguration, Catia nicht.

OK. Und ich habe nur mal von einer "Wissenden" erfahren, dass u.a. folgende Zeile bei den Shares konfiguriert sein sollte/muss:

vfs objects = catia fruit streams_xattr

So habe ich das dann auch gemacht.

Und so steht es auch bei den "Examples" in der entsprechenden und von mir verlinkten man page. In der "Description" steht, warum.
Aber alles gut. Wenn es bei uns beiden funktioniert ...

 

[MOM2006]

ich bin ja nicht so. share ohne erweiterte Dateiberechtigungen erstellt. der user, der den share mounted darf alles im filesystem.

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
    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


[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


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

Wieder einen Ordner vom lokalen Mac der keine erweiterten Finder Attribute hat auf den share kopiert. Das Ergebnis genau gleich wie mit Erweiterten Attributen.

xxx@imac-xxx Test % mount
...
//xxx@diskstation._smb._tcp.local/Test on /Volumes/Test (smbfs, nodev, nosuid, mounted by xxx)
xxx@imac-xxx Test % pwd
/Volumes/Test
xxx@imac-xxx Test % ls -la
total 2892288
drwx------  1 xxx     staff      16384 14 Mai 20:37 .
drwxr-xr-x  4 root    wheel        128 14 Mai 20:17 ..
-rwx------@ 1 xxx     staff       8196 14 Mai 20:18 .DS_Store
drwx------  1 xxx     staff      16384 14 Mai 20:37 #recycle
...
drwx------@ 1 xxx     staff      16384 14 Mai 20:18 TempCopy
xxx@imac-xxx Test % xattr -l TempCopy
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:
xxx@imac-xxx Test % 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 Test %

Ist ja nicht so, dass ich nicht kooperativ und lernwillig wäre. Nur ohne ACLs das gleiche Thema. Könnte es nicht der Fall sein, dass das xattr von Sequoia generell ein Problem hat und bei löschen von Attributen bei Verzeichnissen auf SMB Shares den Errorno 20 bringt? Ich wüsste jetzt nicht wie ich das ausschliessen kann bzw. ob das jemand anderer fernab von einer Synology dementsprechend testen könnte.

Ich habe mittlerweile auch kein Problem mein Share Design von einem auf mehrere umzustellen und dementsprechend nur mit einfachen Berechtigungen zu arbeiten.

Das exakt gleiche Problem habe ich, wenn ich anstatt der Synology auf einen Windows Share das gleiche probiere. Nur auf die schnelle einen Linux Server mit samba bekomme ich, mangels hardware, hier nicht so schnell installiert.

 

[pepe_mac]

Auch mit Linux Server mit Samba ist vermutlich nicht sicher gestellt, das alles einwandfrei funktioniert. macOs ist aus Unix entstanden und je nach dem welches Linux man nimmt, könnte es funktionieren oder nicht. Ich habe einfach versucht Lösungen /workarounds für mich zu finden und dann kann ich damit leben. Allerdings nutze ich QNAP und nicht Synology NAS Server.

 

[lisanet]

Könnte es nicht der Fall sein, dass das xattr von Sequoia generell ein Problem hat und bei löschen von Attributen bei Verzeichnissen auf SMB Shares den Errorno 20 bringt?

Nein, es ist kein Problem von macOS Sequoia. Auch nicht von Sonoma oder Ventura oder ....

Wie du weißt und ich schon mehrmals erwähnte, betreibe ich ein NAS auf Basis von Debian 12, Samba 4.17, openmediavault als NAS-Software mit einer für macOS optimierten smb.conf und einem gepachten vfs Modul

>cd /Volumes/Voyager/Test
Seven:xxx - /Volumes/Voyager/Test
>ll -@
total 424
-rw-r--r--@ 1 xxx  staff  212291 12 Mai 12:08 Samba, ACL und macOS.pdf
    com.apple.quarantine        22
    com.apple.macl        72
    com.apple.provenance        11
    com.apple.lastuseddate#PS        16
Seven:xxx - /Volumes/Voyager/Test
>xattr -c "Samba, ACL und macOS.pdf"
Seven:xxx - /Volumes/Voyager/Test
>ll -@
total 416
-rw-r--r--  1 xxx  staff  212291 12 Mai 12:08 Samba, ACL und macOS.pdf

Auch bei Kopieren des Ordners Test vom Desktop auf das Share erhalte ich keine der von dir erwähnten erw. Attribute.

ls -l ~/Desktop
total 184
drwxr-xr-x  3 xxxx  staff     96 15 Mai 00:33 Test
Seven:xxxx - /Volumes/Voyager
>cd /Volumes/Voyager
Seven:xxxx - /Volumes/Voyager
>ls -l
total 160
drwxr-xr-x  1 xxxx  staff  16384 15 Mai 00:40 Test

Du erkennst auch sicher, dass sich die Unix-Rechte zwischen denen auf dem Desktop und denen des Shares nicht unterscheiden. Ich kann sogar die Rechte vom Mac aus auf dem Share ändern und ohne das Samba dies in Linux-Dateisystem-ACL übersetzt und speichert. Das ist die Folge meiner optimierten smb.conf (Rechte-Änderung) und des gepachten vfs Moduls (keine Linux-Dateisystem-ACL).

Daher eben meine dir bekannte Aussage: es liegt nicht an macOS, sondern am NAS.

 

[lisanet]

Auch mit Linux Server mit Samba ist vermutlich nicht sicher gestellt, das alles einwandfrei funktioniert.

Doch. Siehe mein Posting von soeben #109

macOs ist aus Unix entstanden und je nach dem welches Linux man nimmt, könnte es funktionieren oder nicht.

Es liegt an der Konfiguration des Samba-Server, der unter Linux läuft. Linux hat gegenüber anderen unixoiden Betriebssystemen, dass es kein NFSv4 ACL abbildet, sondern einen seit etlicher Zeit zurückgezogenen Entwurf eines Standards. Eigentlich alle andern unixoiden Betriebssysteme wie u.a. BSD-Varianten und auch Windows und faktisch auch macOS nutzen den Standard NFSv4 ACL. macOS übrigens schon seit den ersten Tagen von Mac OS X

 

[ObiTobi]

Ist ja nicht so, dass ich nicht kooperativ und lernwillig wäre. Nur ohne ACLs das gleiche Thema.

Wenn ich mich nicht verguckt habe, hast Du "vorne" einige Steps übersprungen. Wenn z.B in der globaler Konfiguration etwas fehlt "fruit"? kannst Du (Vermutung) Deine Shares definieren wie Du auch lustig bist. Du schleppst dann die Nachteile/ nicht komplette/optimale Konfiguration für jeden Share mit

 

[MOM2006]

Wenn ich mich nicht verguckt habe, hast Du "vorne" einige Steps übersprungen. Wenn z.B in der globaler Konfiguration etwas fehlt "fruit"? kannst Du (Vermutung) Deine Shares definieren wie Du auch lustig bist. Du schleppst dann die Nachteile/ nicht komplette/optimale Konfiguration für jeden Share mit

ich weiss. die config jetzt wurde schnell mal per gui klicken erzeugt.

 

[jteschner]

Nebenbei:
bei mir sieht es mit Debian 12 und OMV7 als NAS-SW ähnlich aus wie bei @lisanet , ausser -
- ich nutze kein gepatchtes vfs Modul
- die erzeugten Rechte auf dem NAS sind nicht ganz exakt dieselben wie auf dem Mac - die Gruppe bekommt in der Regel noch w Rechte hinzu. Also aus 0644 wird 0664 . Wahrscheinlich bin ich zu blöd die passenden Masken/Modes zu setzen ... oder ich durchblicke das Konzept nicht ganz ... oder beides.

Ansonsten: keine ACLs auf dem NAS nutzen und auch die smb-Shares sind ohne ACLs konfiguriert. Und natürlich alle notwendigen fruit-Parameter in smb.conf gesetzt.

 

[MOM2006]

gut muss ein OMV7 her.

hardware plan wäre AS5402T | 2.5 GbE NAS | ASUSTOR NAS oder 2-Bay NAS Speicher für Zuhause und Büro | 4K-Medienserver – UGREEN NAS DE beide sind gemäß hersteller info oder user infos mit OMV7 betreibbar. Ich würde das Original OS belassen wo es ist und auf ein externes USB3 medium OMV7 installieren. Ich gehe davon aus, dass die NICs abwärtskompatibel sind und auch auf 1Gb/s Switch betreibbar und konfigurierbar sind.

Im NAS Selbst kommen entweder 2x4TB SATA HDDs als RAID1 in Frage oder 2x4TB SSDs auch als RAID1.

Alternative
UGREEN Hochleistungs-NAS | 4-Bay-NAS-Speicher – UGREEN NAS DE mit jeweils 3 Disken im RAID5 Verbund mit der Annahme das RAID im Betrieb um eine weitere Disk bei Bedarf erweitern zu können.

Die Frage ist halt ob bei den Geräten der RAM mit 4GB bzw. 8GB ausreichend ist oder mehr rein sollte. Im Prinzip wird nur ein SMB Server gebraucht ohne Streaming Sachen oder ähnlichem.

 

[jteschner]

Die Frage ist halt ob bei den Geräten der RAM mit 4GB bzw. 8GB ausreichend ist oder mehr rein sollte. Im Prinzip wird nur ein SMB Server gebraucht ohne Streaming Sachen oder ähnlichem.

Mein RPi hat 4GB RAM und nutzt davon um die 30%
Und da sind sogar zwei Docker Apps dabei und ein plexmediaserver.
Transcoding von Video-Sachen würde allerdings mehr CPU und RAM als das benötigen.

Und beachten: OMV läuft nur auf headless Installationen - also Debian ohne GUI

 

[MOM2006]

Mein RPi hat 4GB RAM und nutzt davon um die 30%
Und da sind sogar zwei Docker Apps dabei und ein plexmediaserver.
Transcoding von Video-Sachen würde allerdings mehr CPU und RAM als das benötigen.

Und beachten: OMV läuft nur auf headless Installationen - also Debian ohne GUI

davon ging ich aus. ich brauch unter linux keine gui. in der firma haben wir unsere Debian Server alle von minimalem netinstall iso weg installiert.

 

[wegus]

Da Synologies in der Regel 4GB RAM haben gehe ich davon aus, dass das auch für OMV reicht.

Für die Leute, die die Daten nur auf dem NAS haben wollen ist es sicher keine Option. Aber ich habe einen Folder quasi im rsync Betrieb um ihn zwischen mehreren Rechnern via NAS synchron halten zu können. Dafür gibt es bei Synology den Drive-Server und für jedes OS welches das nutzt einen Drive-Client. Dann hat man aber immer eine lokale Kopie des Verzeichnisses auf der Platte. In meinem Fall genau das was ich für den einen Ordner möchte. Da kommt man dann eben nicht in die SMB Problematik. Für die meisten, die große Datenbestände auslagern wollen, ist das aber sicher keine Option. Aber vielleicht hilft es dem einen oder anderen ja zu wissen, dass auch das geht.

 

[lisanet]

- die erzeugten Rechte auf dem NAS sind nicht ganz exakt dieselben wie auf dem Mac - die Gruppe bekommt in der Regel noch w Rechte hinzu. Also aus 0644 wird 0664 . Wahrscheinlich bin ich zu blöd die passenden Masken/Modes zu setzen ... oder ich durchblicke das Konzept nicht ganz ... oder beides.

am Modul liegt es definitiv nicht. Mit fruit:nfs:aces=yes wird erlaubt, dass der Mac die Rechte ändern kann. Da wird dann die Standard umask genutzt. Die ist standardmäßig 022, was zu 644 führt (= full - umask).

Mach mal im Terminal umask Was gibt das?

Dass es an einer Kobination von mask/mode in der smb.conf liegt kann ich mir nicht vorstellen. Eventuell noch an inherit permissions. Aber auch das habe ich noch nicht erlebt und kann es mir auch aufgrund der Wirkungsweise von nfs_aces auch gar nicht vorstellen. Andere Tools wie Finder können das anders machen und die Rechte nicht verändern oder anders ändern, so dass auch event. dann mask/mode/inherit zum Tragen kommt.

 

[tehabe]

Wenn ich diese Diskussion so lese, wird es wohl besser sein, sich von seinem Synology NAS zu verabschieden, um etwas zu nehmen, wo man mehr Kontrolle über die Konfiguration von SAMBA und auch anderen Diensten hat.

Wobei dies natürlich nicht alle Probleme löst, Apple hat bei macOS sich ja irgendwie überlegt, statt mit NFC mit NFD Unicode zu normalisieren*. Und dies kann zu vielen, vielen Problemen führen.

* bei der Einführung von APFS wollten sie davon weg aber einige Entwickler haben sich dagegen erfolgreich gewehrt und so bleibt es uns erhalten.

 

[jteschner]

am Modul liegt es definitiv nicht. Mit fruit:nfs:aces=yes wird erlaubt, dass der Mac die Rechte ändern kann. Da wird dann die Standard umask genutzt. Die ist standardmäßig 022, was zu 644 führt (= full - umask).

Mach mal im Terminal umask Was gibt das?

jt@omv:~ $ umask
0022

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

Das es an einer Kobination von mask/mode in der smb.conf liegt kann ich mir nicht vorstellen. Eventuell noch an inherit permissions. Aber auch das habe ich noch nicht erlebt und kann es mir auch aufgrund der Wirkungsweise von nfs_aces auch gar nicht vorstellen.

"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.