Thanks so what I can see from that Jira ticket is that “fruit:copyfile=yes” does indeed seem to do what it’s supposed to, i.e. enable server-side copy in Samba (SMB) for MacOS clients, and it would be a good idea to enable it.
Then a remaining question whether that in turn would do its copy via block cloning in ZFS, which would make it even quicker.
My read of the ticket is that it won’t use block cloning… which is why we are reluctant to use or recommend it.
Why? In what way is client-side copy (the file uneccessarily traversing the network twice) better?
Thanks for the ticket link. Sorry for the confusion on my end; I actually searched Jira but didn’t realize I should be looking for “block cloning,” since I thought that was an optional ZFS feature that didn’t activate unless I requested it. (I also missed the 23.10 release, so never read the release notes. Oops.)
Before this conversation I didn’t realize there were any file operations that took advantage of block cloning by default. I thought I had to explicitly enable deduplication to use it. That’s really svelte. 
(I assume that after the copy operation using block cloning, if the original is deleted then the copy automatically starts occupying real space on the pool and continues to exist without a hitch.)
If I wanted to file a bug report with Apple, what would I need to ask them to do, specifically? From the Jira ticket, @awalkerix states, “As of last time I checked MacOS still does not implement the SMB IOCTL for block cloning.”
Is there something more specific I could point the engineers at when I file the bug report? Does that specific IOCTL have a name in the SAMBA standard?
The big difference is the client would know exactly how much of the copy had succeeded in the event of a failure. The operation would be atomic and so less chance of corruption.
When I copy a file from one directory of smb share to another directory of this very share via win11 explorer, it gives me a progress bar. So the client knows at least approximately how much of the copy had succeeded (in the event of failure). I don’t understand how can it help, though (in the event of failure).
So. Several minutes over the network copy operation is atomic. Yet the local few-seconds “cp” operation is somehow not atomic. If that is really the case, I’m calling it a day clownish once more.
And I didn’t understand what kind of corruption you meant.
A well designed file system should consider any copy an atomic operation: either it succeeds or it fails, full stop. ZFS, as a copy on write system, works this way by default. (Other file systems don’t always consider copies atomic, and having used those they provide an interesting experience that I do not always enjoy.)
Corruption in this context would occur when, for example, something somehow goes wrong with the transfer but the operation is not atomic. It might appear to the user that the file copy completed, as there’s a file of some kind in the destination directory, but it’s not a 1:1 copy. The data is now corrupted. Worse, it may have been corrupted silently and without warning. If you then lose the original copy, you’re really in trouble and better hope there’s a backup.
Worse, since TrueNAS implements this feature using ZFS block cloning, there’s an entire extra layer of how/if ZFS handles that failure, and whether SAMBA and ZFS communicate correctly about that failure to present the true state of the filesystem to the user.
SAMBA is old. It’s an open source re-implmentation of Microsoft’s SMB protocol to provide compatibility to non-Windows systems. (Windows has native SMB. It doesn’t need SAMBA.)
SAMBA was originally based on a very early version of Windows’ SMB file sharing protocol that existed before I learned the word lumbago, which was definitely not robust, and was intended by Microsoft to be a purely Windows-to-Windows thing. SAMBA has had to keep up ever since, racing to implement new features and prevent breaks. And when Apple implemented SMB, it didn’t (and still doesn’t, apparently) follow the SAMBA standard to the extent that SAMBA has to employ a whole subset of settings to try to accommodate for that.
(I’m giving Apple the benefit of the doubt and assuming there was a defensible reason not to 1:1 implement the SAMBA protocol at the time, and how that’s become technical debt that’s calcified into Mac OS.)
I feel like we might be going around in circles a bit at this point.
Hopefully, soon we can determine the current behavior under Fangtooth as-per iX’s request, and then go from there.
although then
So after a few laps we seem to have arrived at
iX agrees that server-side copy for MacOS clients via SMB is not enabled therefore is not supported in TrueNAS
iX agrees that server-side copy can be enabled with the aforementioned config switch in Samba
It seems clear that this implementation in Samba does not use block cloning
iX is reluctant to enable it, citing risk of data corruption
Is that why this thread is then marked “solved”, i.e. don’t expect to see this Samba feature enabled in TrueNAS anytime soon?
I don’t agree with the conclusion but at least that would bring some clarity into the matter.
It was marked solved because I have arthritis and had a muscle spasm, apparently. -_-
Fixed that.
Good attempt but conflating a few concepts (this has nothing to do with copy-on-write), and if anything, I don’t see how client-side-copy (shuffling the data twice across the network) would in any way be more robust or atomic than performing the entire operation server-side, in one place, with direct access to the underlying file system. The argument seems a bit handwavy. But I agree, we have probably reached the end of the road, after a long thread. 
Just dropping a note here to make sure I don’t lose track of this.
Two things I want to do next on the Mac client, before installing Fangtooth.
If the issue is that the version of SAMBA in Mac OS is wonky, there might be a newer/less weird version in Homebrew. That’s worth looking into.
MacOS replaced Samba with its own proprietary SMB stack quite some time ago (certainly before MacOS 14). But of course, you could try to actually install Samba and use it as a client and see how far that gets you.
But of course, you could try to actually install Samba and use it as a client and see how far that gets you.
I realize you’re frustrated, but respectfully, your tone is starting to feel really hostile with everyone in this thread.
I started out wanting this to work as an academic excercise, based on the idea that Windows and Mac clients should perform the same over SMB. I had no idea of the rabbit hole I was jumping down due to Apple’s unique implementation of SMB itself.
If Server-Side Copy never works as the default on Mac OS, it won’t change any of my existing, functional workflows. You can even enable it in TrueNAS now using a post-boot script so it works on Mac OS all the time.
This seems like a neat technical problem to explore. It shouldn’t be something that becomes upsetting.
Here’s SAMBA in the homebrew package manager, if you’re curious.
The immediate issue I see w/r/t TrueNAS is that the TrueNAS default config assumes that you’re running Mac OS’ built in SMB implementation, and implements certain fixes/special settings for that environment.
It’s not clear to me what the result would be for TrueNAS if a Mac client was running SAMBA from Homebrew. Ideally, TrueNAS would just treat it like connecting to a Linux client running that version of SAMBA.
So, I take it back. I think testing Fangtooth with the stock Mac OS 15 config before trying to install and use SMB from Homebrew is the way to go.
(For the record, I can see how that would come across as snide or sarcastic - wasn’t actually the intention at all. But I do think we’ve exhausted the topic now, until iX decides what they want to do, so last post from me on this. Have a nice evening all.)
I agree with all (or mb almost all) points brought by @rungekutta. So I won’t repeat them myself.
In my opinion, truenas should/must bring this option to the GUI. If truenas devs are sure it could bring some troubles, then the option just warns that “During the new moon, having this option enabled, with 666 users present on the system, you can corrupt your files. And somehow you can’t corrupt them with full over-the-network transfer. Sign with your blood to proceed.”
Just out of curiosity, I’ve mounted Win11 smb share to my Mac. The copy of the ~1.8GB file from one directory to another took about 5 seconds. Over ~140Mbps wifi. With no traffic spike present (in Stats). Seems like server-side copy works fine out of the box in Mac Sequoia → Win11 environments.
Awesome result. That was from one mounted share to another?
No. Different directories in the same share. Tested with different shares now – it didn’t work (I mean, the transfer was slow).
IIRC, this scenario didn’t even work with Win to Win machines. I tested it about a decade ago, though, so things could have changed.
And I’ve done with the tests. TBH, I don’t even care that much about whether this feature will be implemented or not. The product owner should care.
IMO, the average user doesn’t need it. HOWEVER, trying to only please an average user is a path to nowhere (not sure if the meaning is preserved in English). For one, take a look at the best second best selling Microsoft product – the office. An average user doesn’t give a flying duck about macros. And they didn’t even heard of integrated WebDAV support – Web WHAT?! Yet the features like those make the product really outstanding.
I have never ran a business myself, so I could be totally wrong.
Upthread, it’s confirmed working from Share A to Share B both mounted on a Windows client, as well as a Linux client using Dolphin and mounting the shares the correct way.
I would love for this feature to work. I learned how to use rsync on my Mac to move files across shares because trying to do it with a pair of mounted SMB shares was a performance nightmare.
This should work. But, at the same time, I completely understand TrueNAS’s development team favoring consistent but less good thoroughput and lack of undesirable smbd locking over a speed increase with potentially unpredictable side effects.
Mac OS doesn’t follow standard implementation for SAMBA, requires a bunch of non-standard CLI flags to get NFS shares mounted that mean you’ve got do it from the CLI, and doesn’t even ship with an iSCSI initiator even though one of their main audiences is video editors and editing off your NAS is a thing. You’ve got to pay $300 for third party software for iSCSI.
Even Time Machine does strange things over SMB.
Apple hasn’t prioritized getting network file sharing working smoothly or up to modern standards for years.
This isn’t just a TrueNAS thing, and until more testing is done, it’s not clear to me what if anything iX can do to address weaknesses in Apple’s SMB implementation.
And as previously mentioned, if you want to assume the risk of using this feature, the flag can be manually enabled automatically on boot on TrueNAS, and then you get the Server-Side Copy on Mac OS.
Dats unfortunate.
I’m not an expert, but I do believe you don’t need a block device over the network for the video editing. AFAIK you don’t even really need a block device over the network for anything but virtual disks for VMs.
@jgreco (wait, where is he?) had a great article about file-level access vs block-level access on the old forum. Resource - Why iSCSI often requires more resources for the same result | TrueNAS Community. Not sure if this is it – I remember more in-depth explanations of why block-level access is slower/has bigger latency.
Maybe you mean this article from jgreco
