Hello,
(full disclosure: I had AI write this for me as I first tried getting solutions from a LLM and it gave up on me. I am seriously frustrated.)
I am experiencing a severe and persistent write performance bottleneck with my TrueNAS SCALE 25.04.1 server when using a M4 based macOS client. I have methodically tested every component and have concluded this is a software issue, likely related to how Samba/VFS is handling the macOS workload. I am hoping the community or developers can provide insight.
The Problem:
Sequential SMB writes from my Apple M4 Max client to the TrueNAS server are capped at ~500 MB/s.
This cap persists even when SMB Multichannel is proven to be active across two 10GbE links. The total throughput does not increase; the two channels simply share the ~500 MB/s load.
Sequential reads from the server are perfect, consistently saturating the 10GbE link at ~1.17 GB/s.
Crucially, Windows clients do not have this issue and achieve expected line-rate write speeds.
This definitively points to a bottleneck in how the server processes SMB write requests specifically from a macOS client.
System Hardware:
Server: [AMD EPYC 9124], [128GB DDR5 ECC RAM]
Storage Pool: 8 x [Samsung 870 Pro 4TB] SATA SSDs in a 4-way striped mirror configuration.
Client: Apple Mac Studio (M4 Max), macOS [15.5 Sequoia]
Networking:
Server and Client both have dual 10GbE NICs.
Connected via a 10GbE switch.
Evidence of a Healthy System (The Proof):
I have conducted extensive testing to rule out hardware, network, and basic configuration issues.
Perfect Network Throughput: iperf3 tests show the network is flawless.
Single Stream (iperf3 -P 1): 9.41 Gbit/s
Multi-Stream (iperf3 -P 4): 9.42 Gbit/s
This proves the client, server, NICs, drivers, and cabling are all capable of full 10GbE performance.
SMB Multichannel is Active but Ineffective: Using netstat on the Mac, I have confirmed that during a single file copy, traffic is actively being sent over both 10GbE interfaces simultaneously. However, the total write speed remains capped at ~500 MB/s. This proves the bottleneck is not link bandwidth but server-side processing.
Storage Pool is Not the Bottleneck: Reads are consistently >1 GB/s, and the pool consists of 8 high-speed SSDs.
Exhaustive Tuning Attempts:
I have systematically applied every known performance tuning parameter with no change to the ~500 MB/s write speed cap. This includes:
ZFS Dataset Settings:
sync=disabled
compression=off
recordsize=1M
Global Sambasmb.confParameters (viasmb_options**):**
server signing = disabled
strict sync = no
aio write size = 1
aio write behind = true (This most aggressive setting also had no effect).
VFSfruitOptimizations:
Attempted to set fruit:metadata = netatalk and fruit:copyfile = yes.
Discovered that the TrueNAS middleware creates conflicting vfs objects definitions and blacklists the vfs objects parameter from being changed in smb_options, making it impossible to resolve this conflict.
TCP/IP Stack Tuning:
Disabled TCP Delayed ACK on the macOS client.
Increased TCP memory buffers on the TrueNAS server.
Core Question for the Community:
Given that the hardware and network are perfect, and that Windows clients perform as expected, what in the TrueNAS SCALE/Samba software stack could be causing such a drastic, unresolvable processing bottleneck specifically for macOS SMB writes?
The evidence suggests an inefficiency in how the smbd process or its VFS modules (specifically vfs_fruit) handle the macOS SMB3 dialect, which even Multichannel cannot overcome because the bottleneck is per-stream processing, and the server’s total processing capacity for this workload is capped.
Has anyone with a similar high-performance setup encountered and solved this? Is this a known limitation or a bug in this version of SCALE?
I am using a measly M1 studio and I get 800 MB/s to/from my non super server via SMB. I have tuned nothing on the Mac. Don’t believe I tuned anything on Truenas either, I did check "
Enable Apple SMB2/3 Protocol Extensions". Going to SSD of course. 10G network. So, probably pretty much my limit on said network (no attempt to limit other processes doing I/O on the pool, a live test), not multichannel.
So, I don’t have any suggestion for you except WiFi. You are on Sequoia like me.
Do you have wifi disabled on the Mac? It seems to like to send traffic via wifi and not 10G if it is on, fixable via nsmb.conf on the Mac
How are you testing? I am using the free Blackmagic Disk Speed Test program and selecting the SSD Samba share. I have also monitored system activity app network tab which shows somewhat higher numbers presumably overhead.
I am on Electric Eel though, wouldn’t think (hope) that makes a huge difference.
I am using Amorphous Disk Mark to benchmark but I will try Blackmagic.
I have both 10gb ethernet connections before Wifi in the service order but sure, I can try disabling it. I’ll try anything at this point.
I’m curious to hear what you find. Do post back. I’m surprised mine is faster. Service order doesn’t matter for SMB, seems to ignore it without a client config. Seems stupid!
NOTE: I am not talking at all about Finder or directory listings, talking about your specific question on transfer speed if I read it right. Finder is a whole other issue I am not talking about for my suggestions. That mine is faster than yours on a slower machine on each end is wrong!
IMHO this is a known limitation of macOS.
SMB support has always been very, very bad. Like really bad.
Which seems odd, when you consider how Apple dropped AFP to replace it with SMB but at the same time did not bother to do it right
That is why I think 500MB/s does not sound bad but pretty good for a mac.
One workaround would be to use a local APFS SSD over TB/USB4, at least for your working data. I know this isn’t great and not what you want to hear.
Some people online suggest to run this to disable signing: echo “signing_required=no” >> /etc/nsmb.conf
and then reboot.
Other say it is dangerous to do so.
I don’t think it is dangerous if you only use it locally on your network, but DYOR.
Either way, can you check your single core CPU usage when writing? Wonder if for whatever reason macOS creates more CPU load than Windows.
I hope this is just a test setup and not in production? Because if I were you, I would start over again, just to be sure to not have some strange leftover settings. Like disabling compression instead of using lz4 is probably almost never a good idea.
macOS clients may face SMB write bottlenecks due to SMB implementation limits. Try disabling SMB signing, using SMB v2, or testing with alternative protocols like NFS or AFP.
Discovered that the TrueNAS middleware creates conflicting vfs objects definitions and blacklists the vfs objects parameter from being changed in smb_options, making it impossible to resolve this conflict.
Was this an LLM suggestion? We have a literal checkbox in the UI under services->SMB to enable support for the SMB apple protocol extensions (vfs_fruit), but they have nothing to do with file writes. vfs objects changes are blacklisted for a good reason
Have you achieved wire speed write performance from the mac in question to any SMB server?
Your logic in the first paragraph is flawed:
the hardware and network are perfect
that Windows clients perform as expected
The expected conclusion is an issue with the macOS SMB client. The fact that Windows clients perform as expected indicate that the SMB server can handle the write load.
Have you tried opening a support ticket with Apple?
To clarify: I am a home user so calling this a “production” environment is a bit of an overstatement. This is mostly about my own OCD saying, "Sure it’s good enough but why isn’t it “perfect”. And yea, I know the adage about perfect being the enemy of good…
I am thinking that the one constant that I didn’t consider (and PK1048 mentioned) was the Mac itself. I am new to MacOS (the last Mac I owned was back in the late 1980s). So perhaps my next step will be trying my daughter’s Mac laptop on the same network and see if she gets the same performance. If it is the same, back to the drawing board. If it is more in line with what I would like to expect, maybe then it is something to ask Apple about. Now all I need to do is get her to remember to bring her laptop on her next visit!
I do have somewhere, an older MacBook that was her old one. I could try that and, now that I think about it here, I could even connect it via the same 10gb thunderbolt adaptor I was using to facilitate SMB Multichannel. That means no extra cabling or adaptors.
Stay tuned…
If your daughter’s mac is running the same OS version as yours, I would expect the same SMB write behavior. That still points at the Apple SMB code.
If we assume the Microsoft SMB client is the reference standard (and that is not a terrible assumption), then if that client works correctly with TrueNAS, and the macOS client does not, it is not reasonable to expect TrueNAS to identify and specially handle the non-standard SMB client request from macOS. It is much more reasonable to expect Apple to fix their SMB client code to behave in a standard manner. But that means telling Apple their SMB client code is broken.
So, did you run the tests with wifi disabled and BlackMagic? What were the results? I’d prefer you run it without your extra 10G adapter too so we can compare my system to yours better and rule out the extra adapter so we are testing the same thing. From what I see, there is no performance difference on my systems between Windows and Mac despite what others have said. There are browsing (finder) differences for sure, but that’s not what you are asking. As I had documented and mentioned, mine is as fast as my 10G connection allows given other activity ongoing. And it’s a Mac, and it’s a Studio.
If someone commenting actually has a Mac and a studio, a SSD SMB share, and 10G lan, please run your own tests and report.
Okay here’s the update. I plugged the 10gbe thunderbolt adapter that I had been using for SMB Multichannel into my daughter’s old laptop (Intel based MacBook Pro).
Read speeds jumped to over 600mb/s which is better than my M4 based Mac Studio that doesn’t break 500! So what have we learned?
It’s not Truenas
It’s not the Truenas hardware
It’s not the adaptor
It’s not the network
I can only conclude it has something to do with how the Mac is configured? Any thoughts? As I said, I’m pretty new to Macs. Or should I repost this debacle to a Mac group?
I experienced the EXACT same issue and because of it i’m switching back to core 13.
However, i was doing the transfers from win10/11, so it’s not a mac limitation… it’s an issue with Scale 25.04 (and maybe the others before it for that matter).
simple nas based upon a supermicro x11ssh-f
32gigs ram
xeon e3-1240L
intel x710-da2 nic (10Gb), flashed to the latest intel firmware
lsi based 9400-i16, also with the latest LSI IT firmware.
6x4TB SSD’s in raidz2
no extra services or apps, etc… it was a basic install, setup a dataset and started moving large files across the wire… reads saturated the line, writes maxed out at around 465Mb/s…
meanwhile, core 13 on an i3-7100t (only 2 cores, 4threads), same motherboard/hardware had no problem whatsoever saturating the line both ways. and this is over a DAC (connecting the windows10 box directly to the truenas box), so there’s no switch to get in the way. CPU spiked to ~70% a times, but it moved the very same files both ways at line rate without any issue.
i went through all the settings but nothing changed enough to where it was worth mentioning.
Even if the version of macOS is the same, the ARM (M-series) code will be different than the X86_64 (Intel) based code. So, I still suspect macOS (and I’m a daily macOS user).
Is her mac running a different release of macOS? There have been performance regressions in the past.
Sorry, I have to try black magic yet (that’s for tomorrow).
I got the same results with and without the additional 10gb ethernet adaptor.
My daughter’s old MacBook using that adaptor was much faster than my Mac Studio with and without multichannel.
Turning wifi on or off made no difference.
