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
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.
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.ā
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.
Iām using 24.10.2.1. And I donāt plan to upgrade to 25.04 (yet). Mb next month when the 25.04.1 will become available. Mac is 15.4.1.
Its a great example of where Community testing is needed.
WE can automate testing of linux clients using standard protocols.
When it comes to the matrix of testing each client OS and each feature⦠its not automated. We rely on the Community to test and report.
We do have basic testing of Windows and Macs⦠but not feature-level testing and OS version testing. That matrix is enormous and changes for every update they do.
@Captain_Morgan Thanks for explaining that in a bit more detail. ![]()
Iām definitely excited to see if 25.04 fixes this, but Iām not quite ready to upgrade TrueNAS yet. Iām in the middle of a data migration and redoing my snapshot schedule; I want to get that done first.
After that, Iāll upgrade the system and come back to test this if no one else gets to it first. ![]()
From what @HoneyBadger said above, it sounds like the implementaiton issues on the Mac side would still remain, unless 25.04 mitigates those somehow?
Fairly strong case in neofusionās linked post above that āFast File Copyā as iX calls it, is actually not switched on for MacOS clients but can be enabled with a one-line configuration change in Samba.