Hello,
Is Server-Side Copy enabled by default in TrueNAS for Mac OS clients?
Looking at the SAMBA wiki ( Server-Side Copy - SambaWiki ), it indicates that is not enabled for OS X (Macs) unless server Samba includes vfs_fruit module and fruit:copyfile = yes in smb.conf.
It looks like it’s not enabled, from what I can see–unless I don’t know what I’m looking for (which is always possible).
Here’s what I think is my smb.conf. The vfs_fruit module is obviously enabled, but I don’t see anything that looks like fruit:copyfile = yes
vectorsigma /etc% cat smb4.conf
#
# SMB.CONF(5) The configuration file for the Samba suite
#
[global]
disable spoolss = True
dns proxy = False
load printers = False
max log size = 5120
printcap = /dev/null
bind interfaces only = True
fruit:nfs_aces = False
fruit:zero_file_id = False
rpc_daemon:mdssd = disabled
rpc_server:mdssvc = disabled
restrict anonymous = 2
winbind request timeout = 2
passdb backend = tdbsam:/var/run/samba-cache/private/passdb.tdb
workgroup = FINCHISLAND
netbios name = VECTORSIGMA
netbios aliases =
guest account = nobody
obey pam restrictions = False
create mask = 0664
directory mask = 0775
ntlm auth = False
server multichannel support = False
unix charset = UTF-8
local master = True
server string = VectorSigma TrueNAS Server
log level = 1
logging = file
server smb encrypt = default
interfaces = 10.10.200.2 127.0.0.1
idmap config * : backend = tdb
idmap config * : range = 90000001 - 100000000
registry shares = True
include = registry
Likewise, the SMB configuration shown via testparm doesn’t appear to have the necessary fruit:copyfile = yes flag, either.
vectorsigma ~% sudo testparm -s
Load smb config files from /etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)
Server role: ROLE_STANDALONE
# Global parameters
[global]
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
interfaces = 10.10.200.2 127.0.0.1
load printers = No
logging = file
max log size = 5120
passdb backend = tdbsam:/var/run/samba-cache/private/passdb.tdb
printcap name = /dev/null
registry shares = Yes
restrict anonymous = 2
server multi channel support = No
server string = VectorSigma TrueNAS Server
winbind request timeout = 2
workgroup = FINCHISLAND
idmap config * : range = 90000001 - 100000000
rpc_server:mdssvc = disabled
rpc_daemon:mdssd = disabled
fruit:zero_file_id = False
fruit:nfs_aces = False
idmap config * : backend = tdb
create mask = 0664
directory mask = 0775
You can specify “Additional Parameters String” under the advanced options of the smb share. That should alter the share setting. Never did it myself, but I’m also new to truenas.
1 Like
Thanks! Looks like that would do it, though I’d prefer a service-level setting.
I’ve got 3 Macs on my network that use SMB. I’d prefer this always be on instead of tracked per share.
EDIT:
I’ll try to submit a feature request for this and link it back here.
Feature request posted:
I’d appreciate any comments/suggestions to improve the request or the proposed implementation.
3 Likes
I think there’s a popularity contest for feature requests. If this is nailed down, you need to rally support and toss in the link for more people to boost it up. I’m not a mac dude but I see the utility here, I’d give it my axe.
I posted the feature request link directly above. You can upvote there if you think it sounds useful. 
1 Like
Voted. I’m a little obtuse because that post was 50% links 
I’ve gone to advanced settings, and the additional parameters is greyed out so you can’t add anything. Am I missing something obvious?
Is this on a share? What version of TrueNAS are you on?
When I pulled up a share to look at it, the entire field was blank, and I could type in it.
25.4.0. Yes it’s a share.
According to the SMB documentation, fruit:copyfile is a global option and needs to be set at that level. I don’t think TrueNAS allows you to do that?
In some truenas videos I saw aux params for the smb service. So there was a global setting. Aaaaaaand it’s gone!
1 Like
Are you positive that server-side copy isn’t available to MacOS clients?
I mean, have you verified that it doesn’t work?
1 Like
The documentation says it’s disabled by default, so needs ”fruit:copyfile = yes” in global settings.
I understand. The samba.org docs says that, but has anyone here tested how it works in TrueNAS? iX sometimes makes changes to defaults and such and it’s good to verify if there is an issue or not.
I understand. The samba.org docs says that, but has anyone here tested how it works in TrueNAS? iX sometimes makes changes to defaults and such and it’s good to verify if there is an issue or not.
@neofusion where would those changes be? As far as I know, there’s only one global config file for SMB, located at /etc/smb4.conf (which is already a different name and location than is expected by the SAMBA/Debian docs, so I think iX has customized the global settings.
I’ve done large file transfers before between mounted shares, and the speed meter I was using appeared to show equal downloads and uploads (data had to come in to my local client before going out again to the new location on the NAS).
I’ll confirm that with a test later today. If someone else could run a test to confirm, that’d be excellent.
My smb4.conf is in the first post in this thread, as is the output of testparm -s for global settings. There’s no mention of fruit:copyfile anywhere. I’m not sure how server-side MacOS copies could be enabled if the SMB service itself doesn’t think that it’s enabled.
Due to the difference between “this variable is not set in the place I expected, it has to be a bug” vs. “the recorded transfer speed is lower than expected, is this feature actually enabled?” I wanted to make sure you had observed an actual issue.
It looks like you have.
What version of MacOS and did you do that copy using Finder drag/drop?
To me this sounds more like a bug than a feature request, but maybe iX thinks diferently.
1 Like
I hate to file a bug and a feature request, but that’s probably what I’ll end up doing.
I can’t even tell for sure whether it’s enabled or not, which definitely seems like a bug.
Mac OS Sequoia 15.4.1, drag and drop.
I’ve also done copies via rsync, but those don’t use SMB so that doesn’t really help.
This is very frustrating.
Just tried to copy a ~2GB file from one share to another share directory of the same share.
This took 2-3 minutes. MacOS stats showed network usage of 80-140Mbps (which is typical speed for my wifi). My pool is definitely more performant than 140Mbps of sequential write (I think even cheap thumb drive would exceed it). Share preset – default share parameters.
Tried to copy a file about the same size using Win11 explorer. It showed 300-900MBps (note the upper case B this time) and took several seconds. That’s definitely faster than my 1GbE connection on Win11 machine. Btw task manager showed no increased network traffic (just few kbps).
I think that it proves server-side copy doesn’t work on MacOS out of the box.
4 Likes
Thanks!
That confirms it’s not enabled for MacOS.
This has to be a bug, right? iX wouldn’t leave Mac OS slower on SMB on purpose.
1 Like
