SMB unter MacOS langsam

Hallo und Willkommen!

Letztendlich nur eine Bestätigung deiner Feststellung:

1. SMB und macOS...eine leidliche Geschichte seit einigen Versionen. Deine Tipps haben bei mir, auch schon bei einer Synology DS, nichts gebracht.

2. die Zähigkeit liegt IMHO (leider) auf der Mac Seite. Wenn's mal wieder klemmt, war nach einem Reboot*, bspw. derselbe "Datenverschub" im LAN wieder super (*das man "genötigt" ist, bei macOS sowas überhaupt zu machen... )

3. Wenn's denn läuft, aktuell eine Verbesserung

4. den Cache würde ich mir schenken, lieber RAM bis zum "Anschlag".

Mal andere Protokolle (WebDAV, ssh...) zum gegen-Check ausprobieren?

Schau mal, ob solche "Tweaks" überhaupt einen Reboot überleben, bevor du dir darüber Gedanken machst.
Viele Konfigurationen stellt UGOS beim Booten neu zusammen.

Verzeichnisse mit einer grossen Anzahl von Files sind ein echtes Problem in MacOS. Bei Apple Support gibt es folgenden Tip (SMB-Browsingverhalten in macOS)

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Quote from ACiAtuRA

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Also, ich bin ja auch so ein Leid geprüfter, Spielen wir das Spiel doch mal durch. Diese Einstellung betrifft ja die Ansicht Metadaten

Bei 20.000 Dateien mit der Größe von fünf Megabyte bringt dieser Befehl einen Vorteil auf einem modernen M4 Mac Mini zum NAS von gerade einmal 250 Millisekunden beim ersten öffnen des Ordners, kumuliert kann das bei tausenden frisch geöffneten Ordnern Sekunden bis 6 vielleicht 10 Sekunden bringen – aber nur verteilt über viele Ordner-Öffnungen, nicht auf einen einzelnen Klick. Eher nicht so dolle

Kann auch jeder selbst empirisch auf seinem System testen (per smbutil statshares + fs_usage)

Quote from muelli75

Am Share mit den Problemen ist unter /etc/samba/smbshare.conf die parameterzeile:
vfs objects = catia fruit full_audit recycle streams_xattr ug_xattr_filter

muelli75 Das hier ist dein Wunder Punkt. Du hast dein Problem faktisch schon richtig identifiziert. Und willst nun eine Go-Mitteilung.

fruit & streams_xattr Damit hast du faktisch doppelte SMB-Zugriffe ug_xattr_filter (Ugreen Patch) hat ein Problem arbeitet nicht synchron. Habe ich bei meiner Recherche rausbekommen ist wohl bekannt. Sag mal, ist dir der Papierkorb ist wichtig? Ich denke schon, es ist ja bei dir eine produktive Umgebung.

Ich würde sagen vfs objects = catia fruit recycle

Alles andere ist überflüssig. Der größte Bremser hier ist full_audit weil er jede Operation loggt

Parameter anpassen:

   fruit:metadata = stream verhindert doppelte Extended-Attribute (statt xattr) → jeder Datei-Zugriff nur ein Metadaten-Roundtrip
  fruit:resource = stream 2 – 4 × schnelleres Verzeichnislisting bei vielen kleinen Dateen
  fruit:aapl = yes aktiviert Apple-optimierte Antworten; Finder ruft weniger stat -Calls ab
  fruit:posix_rename = yes
  fruit:zero_file_id = yes
aio read size = 1 aktiviert asynchrones I/O auch bei kleinen Dateien
aio write size = 1 10 – 30 % schneller bei vielen kleinen Schreib-/Lesevorgängen
  recycle:repository = .recycle
  recycle:keeptree = yes
  recycle:versions = yes
  recycle:touch = yes
  recycle:maxsize = 0
  recycle:exclude = *.tmp,*.temp,*.o,*.obj,~$*
  recycle:exclude_dir = /tmp,/temp
  recycle:noversions = *.bak,*.old
  recycle:directory_mode = 0770

Prüfen danach: sudo testparm -s

Aufgepasst --> Die UGREEN-Weboberfläche schreibt beim Erstellen/Löschen von Shares diese Datei neu. Mach dir nach jeder! Änderung ein Backup !

Meine persönliche Meinung, was am meisten Speed bringt, ist Fruit:metadata, fruit:resource & aio read/write size

Anderer Suchansatz, besseres Ergebnis. Bisher gab es immer nur die "üblichen Verdächtigen" (smb.conf & Co.), jetzt bin auf einen anderen Parameter - mit Begründung - gestoßen (Quelle).

Entscheidender Punkt:

Quote

Eine weitere Möglichkeit besteht darin, die Art und Weise zu ändern, wie macOS die Netzwerkverbindung auf Kernel-Ebene handhabt. Samba (SMB) ist ein sehr kommunikatives Protokoll und sendet während seiner Ausführung viel TCP-Datenverkehr über das Netzwerk. Irgendwann in der Vergangenheit hat Apple beschlossen, eine Einstellung namens „delayed ACK” (verzögertes ACK) im Kernel-Netzwerk standardmäßig zu aktivieren. Dadurch wartet das System einige Pakete ab, bevor es ein TCP-ACK-Paket an die Quelle zurücksendet. Zu Zeiten von 10/100-Ethernet, Wireless B und DSL war dies sinnvoll, da dadurch Pakete im Netzwerk eingespart werden konnten. Da heute 1-Gigabit-Glasfaseranschlüsse für Privathaushalte verfügbar sind und Multi-Gigabit-Netzwerke immer günstiger werden, ist dies nicht mehr wirklich notwendig. Es kann auch zu Problemen mit der SMB-Leistung führen, da der SMB-Server in der Regel auf ACK-Pakete wartet, bevor er weitere Daten sendet. Durch Deaktivieren dieser Option wird der Engpass beseitigt.

Um zu testen, ob dies in Ihrer Umgebung hilft, können Sie diesen Befehl im Terminal ausführen, wodurch verzögertes ACK bis zum nächsten Neustart deaktiviert wird:

sudo sysctl net.inet.tcp.delayed_ack=0

Wenn dies Ihre Leistung verbessert, sollten Sie diese Einstellung dauerhaft übernehmen. Am einfachsten ist es, einen LaunchDaemon auf Ihrem System zu installieren, der beim Start Ihres Computers ausgeführt wird. Öffnen Sie eine neue LaunchDaemon-Konfiguration für sysctl (sudo vim /Library/LaunchDaemons/com.startup.sysctl.plist) und fügen Sie folgenden Inhalt ein:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.startup.sysctl</string>
    <key>LaunchOnlyOnce</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/sysctl</string>
        <string>net.inet.tcp.delayed_ack=0</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Quote

Dadurch wird ein LaunchDaemon erstellt, der einmal beim Systemstart ausgeführt wird und verzögerte ACK-Bestätigungen deaktiviert. Wenn Sie dies rückgängig machen möchten, löschen Sie die LaunchDaemon-Datei und starten Sie den Computer neu.

========

Ausprobiert und zur gefühlsmäßigen Visualisierung (830MB File) über WLAN gestartet. Ich fand's gut. 😆

DXP2800 --> 2.5G LAN --> FB7690 (2.5G Port) --> WiFi6 --> MacBook

Screen-Video in Echtzeit Dropbox-Link (*.mov, 1,3MB)

Ich hab ein ähnliches Problem. Transfer von 5GB von macOS zur DXP2800 ~3 Minuten. Gleiches file zur Synology DS718+ ~1 Minute. Bin am Testen ob ich meine Syno ersetze und eigentlich begeistert von den Möglichkeiten, allerdings ist das hier ein Todeskriterium.

Da es von macOS zur Syno einwandfrei funktioniert sind Änderungen am macOS Client keine Option. Die DXP muss hier was anders machen.

Ich komme von einer DS716+II (8GB) und die DXP kann definitiv nix dafür. Da haben wir uns "drüben" schon ausgetauscht (Bsp.).

Für die obige "Testumgebung" habe ich den SMB-Cache gelöscht, usw., um eine "saubere" Ausgangslage zu schaffen. Mit ProtogonosTipps kam ich leider nicht weiter, aber die aktuellen Erkenntnisse haben sich wirklich deutlich nach oben unterschieden.

Verstehe dann aber die Abweichung trotzdem irgendwie nicht. Wenn du sagst es liegt nicht an der DXP, wieso habe ich unter der Syno bessere Werte? Klar, dort gibt es ggf. Optimierungen. Ich bin aktuell auch noch komplett auf Standard und habe bisher nix an den smb Settings der DXP geändert.

Quote from muelli75

ACK-Tweak nur mehr beim Handling mit vielen kleinen Dateien.

...sowohl als auch. Gerade lief das TM-Backup und auch hier "rödelte" es eindeutig schneller. Da sich grundsätzlich eine identische Datenmenge ändert, bekommt ein Gefühl dafür.

chaos2oo2 soweit vom Umfang möglich, sind die SMB-Einstellungen von DS und DXP identisch.

Ich möchte das Thema hier nicht kapern, habe aber seit langem ein Problem im Zusammenspiel vom Mac mit einem QNAP und einem UGREEN - NAS. Vielleicht hat dort auch noch jemand eine Idee. Ich habe auf dem Mac zwei Benutzerkonten. Wenn der Mac frisch gestartet wird und ich mich einlogge, dann benutze ich AutoMounter (oder CoonectMeNow V4), um 4 Ordner auf dem Mac einzubinden. Das klappt auch soweit so gut. Wenn ich mich nun den Benutzer abmelde und ich mit dem anderen Benutzer anmelde, dann ist es eine 50/50 - Chance, ob die Ordner eingebunden werden oder nicht. Die beiden Tools (natürlich nicht parallel genutzt) sehen das NAS, aber das einbinden klappt nicht wegen Zeitüberschreitung. Dann bleibt mir nur den Mac neu zu starten, da auch ein manuelles Verbinden nicht geht. Das Problem habe ich schon seit 3 oder 4 MacOS - (Haupt-) Versionen und ich habe am Anfang gedacht, dass es ein Problem von QNAP ist. Da aber das gleiche Problem auch beim UGREEN auftritt, muss es wohl am Mac liegen.

Kennt jemand das Problem und weiss sogar eine Lösung?

Es wäre besser hierfür einen eigenen neuen Thread zu eröffnen, da es doch ein ganz anderes Thema ist.

[OT] Tranel schau mal hier

Hi

Danke. Im Prinzip machen das ja die Apps schon, die ich nutze bzw. genutzt habe. Das Problem ist einfach, dass anscheinend die Kommunikation zwischen MacOS und den NAS zur Anmeldung nicht sauber läuft. Der Mac sieht ja das NAS, aber kann sich dann nicht verbinden.

Dann prüfe mal die Anmeldeoptionen/Userdaten. Aber bitte für den weiteren Verlauf einen neuen Thread aufmachen, mit jeder weiteren Antwort driften wir vom Thema ab.

PS: ggf. an Mike0185 oder Willi wenden, die verschieben die zugehörigen Posts passend

--> Am Besten einen neuen Thread im passenden Forum eröffnen.

*kw* ich bin mit meinem MacBook Pro (M3 Pro) auf macOS 15.7.1 unterwegs. Mittlerweile ist die Verbindung zu meinem DXP2800 eigentlich identisch wie zu meiner alten Syno: ~106 MB/s.

Das Einzige was ich gemacht habe, da mir die ganzen .DS_Store Files auf dem Netzlaufwerk sowieso auf den Zeiger gegangen sind, war

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

Neustart des Macbook, neustart des NAS.