Did it make any difference after applying the option fruit:copyfile = yes option? You probably have to restart the SMB service for it to take effect.
@swc-phil could you make this change on the share level and try again?
Sorry for asking for another test; Iâm not in a position to log in and adjust my shares right now.
Could you test this by adjusting the advanced parameters on a couple of shares and try again after restarting SMB?
Your Mac and Windows machines should get similar results.
If they do, please post those results here and Iâll use them to file the bug report.
I donât think setting per share is going to be much use.
Global options / âThe following options must be set in the global smb.conf section and wonât take effect when set per share.â, here
1 Like
The Additional Parameters String option is blocked for me for some reason. Even with stopped service. And even for a new share. Tried to pick different presets. Tested in 2 browsers. The only option Iâve recently changed is Multichannel option. Tried to untick it, but nothing has changed. Didnât reboot though.
Tbh, I donât even understand what we are trying to test. Samba doc explicitly states that option must be present. sudo testparm -s showed the option is not present. Are we questioning the samba docs or what 
?
âŚAh.
Thanks for pointing that out. Iâll include it in the Bug Report when I file it today.
Is this of any help?
It shows how to edit the aux params in the CLI.
Iâll have to test and see if this works, but it shouldnât be necessary. If itâs per-share, it wouldnât help. As @rungekutta , this fruit parameter has to be set globally.
@kris or @HoneyBadger stated on the podcast a few weeks ago that unless youâre using zpool to check status or one of the IO testing tools, youâre not really meant to have to dip into the CLI for normal operations.
Iâm pretty confident this is intended to work the same way no matter whether your client is a Windows machine or a Mac. (Linux is dependent on the kernel and other bits on the client, apparently; the SAMBA doesnât take a clear stance on it which makes me think itâs up to the user to make sure their particular Linux does the thing.)
@swc-phil At this point, we know it isnât working on a Mac from your testing. Everything else is just extra information we can submit with the bug report to help make it easier to handle.
It think weâve got what we need to file the report now.
1 Like
Unfortunately Apple didnât write MacOS to use the industry-standard methods of server-side SMB copy. The SMB server has to advertise itself (globally) as being a MacOS SMB server and supporting their specific IO/FSCTLs.
The problem is that enabling with vfs_fruit and fruit:copyfile=yes as documented in thread may also cause unwanted behavior:
WARNING: the copyfile request is blocking the client while the server does the copy.
In this case, âclientâ is the smbd client process on the server.
Itâs being looked at, but this is more complicated than just âflip the switch and magically works.â
2 Likes
Thanks for the info on this. Honestly, I suspected there was a blocking issue keeping this from being toggled on in the server configuration, but I was hoping it was just a case of a harmless line missing from smb4.conf. Bummer.
Is there a JIRA ticket we can track? Iâm assuming it wouldnât be helpful to file a new bug report at this point if yâall are already poking at it.
What does it mean to be âblockingâ the client (smbd). Does that mean the entire SMB service daemon just locks up and stops being able to respond to other requests while itâs doing the operation(s) requested by the Mac?
(Honestly, Iâm really getting sick of running into oddities with how Mac OS handles SMB and NFS and iSCSI versus everything else. Alas. Being better than Windows does not make it good, and I canât switch to Linux because of work requirements. I barely manage to make a Mac work for ⌠work ⌠and still need a Windows VM.)
Donât understand this comment. Smbd is the server daemon, no? Surely the âclientâ here refers to the Mac client? I donât see any other client or server that the Samba docs could be referring to in this context.
Since itâs transferring from SMB Share A to SMB Share B server-side, I assumed Share A is making client-calls to send data to Share B, which is receiving them by using server calls.
I stumbled across this blog about someone going through the same thing a few months ago:
He also ran some illustrative tests and finishes off with saying that he was going to contact iXâŚ
I wonder whether you need a Mac VM when you make Windows work for work 
Given my usual urge to snap Windows laptops in half after using them for 10 minutes ⌠probably not. 
EDIT: OTOH, I probably will end up using Linux or Windows in a VM to do mass file management on the server.
@swc-phil , what version of TrueNAS are you running?
Over on the feature request I posted ( Enable Mac SMB (Samba) Server-Side Copy Support by Default or Provide a Toggle in SMB Service Advanced Options - #2 by Captain_Morgan ), @Captain_Morgan mentioned that Fast Copy for SMB hads additional work done on it.
Please test with Fangtooth⌠25.04. Fast copy for SMB got some extra love.
The question is whether MacOS is doing something very different. You might also need to test with the their latest version.
Also, which version of Mac OS are you running?
Sounds like iX hasnât tested this on Mac at all.