[Samba] Documentation/Feature Clarification Request: Server Side Copy and VFS_FRUIT
Ralph Boehme
slow at samba.org
Wed May 21 07:46:34 UTC 2025
There are two styles of SSC:
- the "normal" protocol style called copy-chunk, where the copy is
requested in IO ranges by the client and performed server-side
- the Apple way enabled by fruit:copyfile where the client requests the
*whole* file to be copied in one request to be performed by the server
The problem with the latter is that for large file the copy takes some
time and meanwhile the client is blocked waiting for IO to complete. If
the copy takes longer then the SMB request timeout time (iirc default
30s) the requests times out and the client will disconnect the connection.
My recommendation is to stay away from fruit:copyfile for these reasons.
Hth!
-slow
--
SerNet Samba Team Lead https://sernet.de/
Samba Team Member https://samba.org/
Samba Support and Dev https://samba.plus/services/
On 5/20/25 6:17 PM, John T Davis via samba wrote:
> Hello,
>
> I’m running TrueNAS 24.10.2.2, which uses Samba 4.20.5-truenas. I have a mixture of Mac, Linux, and Windows SMB clients in my network that talk to the TrueNAS server over SMB.
>
> Apologies in advance for the slightly long-winded setup to my question; I wanted to explain how I got here.
>
> I’d like to be able to use Server-Side Copy (SSC) (https://wiki.samba.org/index.php/Server-Side_Copy) with my Mac clients to mange files on the TrueNAS server. As noted on that wiki page, “Note - not enabled for OS X (Macs) unless server Samba includes vfs_fruit module and fruit:copyfile = yes in smb.conf.”
>
> iX Systems (the company that develops and ships TrueNAS) does not add this flag to their default SMB configuration file. While I was trying to figure out why, I came across this warning from the current VFS_FRUIT man page in TrueNAS.
>
> "fruit:copyfile = yes | no
> A global option whether to enable OS X specific copychunk ioctl that requests a copy of a whole file along with all attached metadata.
> WARNING: the copyfile request is blocking the client while the server does the copy."
>
> One of the iX devs explained on their forum that this is relevant to SSC because when a SSC operation is in progress, TrueNAS’s Samba server is acting as both the client and the server, which makes sense.
>
> After talking with the iX devs and users on their forum, along with some members of the MacSysAdmin subreddit, I’ve realized that no one seems to know exactly what “blocking the client” means in this context—though I’m guessing it has something to do with Mac OS’s SMBX implementation not doing SSC the way the Samba server expects.
>
> In testing after adding the "fruit:copyfile = yes” line to the SMB config on TrueNAS, SSC appears to work just fine without any obvious issues on a Mac—but that doesn’t mean there’s not a problem, just that we don’t understand how to trigger it.
>
> I’ve spent about 4-6 hours on various forums and reading documentation, and am still pretty confused about what’s going on here.
>
> Request:
>
> I'm trying to track down the potential performance and other implications in the real world for having SSC enabled for Mac clients, but I haven't been able to find anything concrete yet. So, I have a couple of questions and suggestions for updates to the Samba documentation.
> The warning exists in the man page, but not the official Samba docs (e.g., the Wiki).
> Is it possible that the warning no longer applies, but the man page was never updated?
> If so, could the man page be updated to remove this? This warning existing is one reason that the feature is not enabled by default in TrueNAS’s Samba build.
> If the underlying issue that led to the warning still exists, would it be possible to update the wiki documentation to include the warning and also to explain a bit more about what “blocking the client” means in this context?
> For SSC operations, one client is the Samba server itself. Does the entire Samba server experience an I/O lock when an SSC operation is initiated on a Mac? Or is it the actual Mac client that can’t do additional SMB operations until the SSC is completed? Or both?
> More generally, what does this “blocking” look like to a human user and/or automated scheduled tasks? What problems can it cause? There’s a big difference between locking up the entire Samba server itself, and the Mac client that initiated the SSC request just having to sit there and wait to do more SMB things until the copy is done.
>
> Thanks for your help.
>
> -- -- --
> John T Davis
> johntdavis at johntdavis.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba/attachments/20250521/87cd0625/OpenPGP_signature.sig>
More information about the samba
mailing list