SMB (Samba) Server-Side Copy Support: Enabled for Mac OS?

TrueNAS General
, , ,
81

The other article seems spot on as well. Why would you pick iSCSI over SMB or NFS (with sync writes off) for editing on a NAS?

82

Nah, there was a description of the entire iSCSI stack.

83

Finally found it. Turned out to be an explanation of why latency matters for sync writes (and not the comparison between file and block storage types). Look at the paragraph Laaaaaaaaatency. Low is better.

84

Of course. And then you do NOT want sync writes for maximal performance, and certainly not for work which could always be redone like video editing.

85

Thanks for the articles. Always glad to learn more as I try to penetrate ZFS’ unknowable mysteries. :wink:

1 Like
86

For anyone looking to enable this, you should not modify /etc/smb4.conf directly, as these changes will not persist.

Instead, open a shell and type:

cli

Then

service smb update smb_options="fruit:copyfile = yes"

And restart the SMB service. You can cat /etc/smb4.conf to see if the option was added for you.

1 Like
87

That’s dangerous and could break your system. You should instead make a feature request for it to be an option that can be toggled in the GUI.

88

There is an existing one here

@winnielinnie

2 Likes
89

Sure. Until the feature is accepted, though, this is a workaround for those willing to take on the risks :slight_smile:

If some of you do have this option enabled in a production server, it’d be helpful to report your experience long-term in the feature request, whether it works flawlessly or fails spectacularly.

1 Like
90

I’ve updated the feature request with additional information from the Samba dev team regarding why the defaults on Mac OS are set as they are: Enable Mac SMB (Samba) Server-Side Copy Support by Default or Provide a Toggle in SMB Service Advanced Options - #9 by SinisterPisces

You can see the dev’s response and my original message here: https://lists.samba.org/archive/samba/2025-May/251551.html

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.

1 Like
91

Thanks for posting, that clarifies thing (including why there is a warning in the samba docs for enabling the feature).

I’d like to add something though. In my own testing, it very much looks like Samba actually utilises ZFS block-cloning in the file copy operation. Meaning the operation is instant, with no perceivable blocking delay nor I/O activity nor available space decreasing. This being the case doesn’t only change the situation wrt to the advise given by the Samba dev but of course would also be hugely beneficial to the truenas user.

Maybe if you’ve got the dialogue still open you could ask this as a follow-on (i.e. assuming ZFS as the underlying fs and block-cloning available, will Samba utilise it).

92

I’d like to add something though. In my own testing, it very much looks like Samba actually utilises ZFS block-cloning in the file copy operation. Meaning the operation is instant, with no perceivable blocking delay nor I/O activity nor available space decreasing. This being the case doesn’t only change the situation wrt to the advise given by the Samba dev but of course would also be hugely beneficial to the truenas user.

See here: Enable Mac SMB (Samba) Server-Side Copy Support by Default or Provide a Toggle in SMB Service Advanced Options - #7 by gabriel

When this feature is enabled on TrueNAS, it appears to use ZFS block cloning. So, yes; in a ZFS environment this might be perfectly fine for Mac clients, even if it’s not a safe defaulst for Samba itself because of how many file systems it runs on top of.

I don’t think the Samba dev team is in a position to give advice or condone use cases for specific filesystems. They can’t possibly test every Samba feature with every underlying filesystem (and every release of every underlying filesystem–ZFS gets a lot of patch releases) that Samba runs on.

I think iX would have to take on a lot more monitoring/testing work for Samba at each release if this was the default behavior for Mac clients. They’d have to decide if that’s something they’re feasibly able to do for every release at the testing stage. And realistically, it might not be.

Apple is in the best position to fix this problem permanently by redoing their SMB client implementation to behave like a a Samba client that SSC works with. Their non-standard implementation is the reason this doesn’t just work like it does for other clients.

93

SMB is a protocol, designed by IBM, not Microsoft. It was not intended to be a “purely Windows to Windows thing.” Microsoft became its primary proponent and user when it adopted it as Windows’ file and printer sharing system.

SAMBA is an implementation of SMB, not a re-implementation, and it is not a standard.

Microsoft publishes the defacto specification at:

[MS-SMB]: Server Message Block (SMB) Protocol

So SAMBA does not have to “keep up ever since, racing to implement new features and prevent breaks.” It just has to follow the spec. In the same way other vendors like Sun Microsystems and Apple did when they wrote their own implementations of SMB (not SAMBA).

Apple used to ship SAMBA, but they started shipping their own implementation of SMB (which appears to be based on Sun’s) after the SAMBA project poisoned itself with GPLv3.

Interoperability is tested and verified at events like Connectathon and Plugfests, not by slavishly reverse engineering or following any given vendor’s implementation.

94

I don’t think so actually. Should be able to solve with an automated test. If I understood correctly though, iX doesn’t include MacOS clients in their automated testing for some reason. Neither had they looked particularly deep into this particular case (see above discussions citing ”reasons”) even after raised here and in bug reports. I think the reality is MacOS is a low priority for iX.

95

Also not clear to me whether this behaviour from Apple is actually in violation of the protocol or not. One would have to look into specs, but presumably, if the protocol enables a server-side ”copy-file” operation (which it evidently does), why would this not be used if the client wants to… copy a file? And in addition - now that we’ve resolved it - that brings exactly all the benefits you’d expect since the whole operation happens atomically and super-quick thanks to zfs block cloning. So it would be determinental for truenas under those circumstances if Apple changed it to some quasi client side copy where the client breaks down the file in chunks before passing off each chunk for server side copy.