That’s what it sounds like, the fruit:copyfile = yes flag would need to be in 25.04’s smb4.conffile.
Mentioned up-thread that enabling this flag causes a blocking issue with the smbd daemon on the TrueNAS server.
Right now, I don’t have a way to test if this works with Fangtooth and the latest Mac OS.
I’m not sure where that leaves us if it still doesn’t work. After decades of Apple not implementing standard SMB, I’m not sure that submitting a bug report to them will get much action.
Maybe we need to ask the SAMBA team what the status of a possible fix is?
As a Mac owner, it’s really, really frustrating to run into things like this. This is the second time since I’ve started working with TrueNAS that I’ve run into a Mac-specific blocking issue (iSCSI isn’t supported out of the box on MacOS). NFS is a pain, too; it requires starting the connection using some non-default flags on the Mac side.
rsync works great but it’s a lot easier to do it wrong if you don’t know what you’re doing than just dragging a file from one share to another in a Finder window.
SMB is the closest thing we have as Mac users to something that just works.
This has been frustrating, but at least explains the less-than-expected performance I’ve noticed in the past.
I’m not looking to blame iX or Apple or the SAMBA team, but I’m not a developer and can’t attempt to fix it myself. For the moment it seems like we might actually be stuck.
Why would we be stuck? Samba supports this out of the box but it’s not enabled per default, like some other MacOS-specific extension. TrueNAS hasn’t enabled it, but perhaps that’s the solution, and that’s that. Nice of Samba to point out in their docs that the copy operation is synchronous i.e. blocking on the client while the server does the copy, but that seems undramatic and even logical to me. Unless someone would like to explain what the issue would be.
To me this seems like an oversight in TrueNAS and something that simply hasn’t been tested until it was highlighted here and in blogs like cited above. Happy to be corrected of course.
I’m guessing here, but I’m assuming that blocking smbd on the TrueNAS server blocks it for every active connection. Am I misinterpreting that?
Imagine you’re in a huge environment with a ton of users all with mounted shares, and suddenly everyone’s mounted SMB shares lock up because That One Mac Guy is reorganizing his files across a couple of mounted folders.
Worse, automated processes that connect to SMB to do mission critical things are going to start failing, and not all of them are going to handle that gracefully, which could lead to data loss/data being in an unknown, inconsistent state.
If that’s what we’re talking about when we’re talking about locking smbd, then I understand why that setting is off by default. Slow transfers for the Mac Guy are preferable to unpredictably locking up the entire SMB service because The Mac Guy got overambitious.
If that’s what’s happening, I can absolutely see that setting being on by default being too risky for a business environment, even if it’s probably okay for a smaller office/home install. Or maybe not okay: If your Mac’s Time Machine backs up over SMB to the TrueNAS server once an hour, and that takes 30 minutes, is the entire SMB service on TrueNAS locked up for half the day?
I have no idea at this point what the implications are of blocking the smbdclient process on the server actually are. My guessing tends towards the worst case scenario, and the SAMBA docs on this are pretty vague.
So, the question I have now is what exactly would lock up?
That is some fairly wild interpretation of that note in the samba docs and I don’t believe how it works. Samba normally forks off multiple smbd processes and can handle concurrency just fine, even if doing something blocking for one client. TrueNAS would have to do something very funky here in that case. I didn’t understand @HoneyBadger’s comment above and asked, maybe he or someone else from iX can come back and provide some more colour as to where the complexity lies.
Unless otherwise stated, you have to assume SAMBA works with multiple file systems and MUST block other accesses to the same files.
If one client copies data and another reads or writes data… there could be massive inconsistency. COPY needs to be an atomic operation.
With a slow file system, the copy can take a long time as there may be real copies been made. The blocking could be significant.
With ZFS, the fast copy is metadata-only and so doesn’t take very long for even GBytes. However, reading and writing to that file must be blocked until completed.
I’m not really sure how enforcing copying an entire file over the network (instead of server-side copy) mitigates possible inconsistency… But I’m not a specialist.
Just found out yesterday, the Linux client runs into this problem too. In Garuda if I copy and paste stuff from one server location to another, oh boy watch that wifi transfer go. But flip over to windows doing the exact same operation and it’s between 600MB-1G per second, obviously just watching the server move stuff internally and we’re in the bleachers watching the show.
Is there a client-side option that enables this in filers like Dolphin or does it go deeper?
Still don’t get it. For example, why can not a server-side copy enforce file locks as well then? It feels clownish that SMB was designed in a way that copied data must traverse the network in the first place.
@Captain_Morgan Thanks for taking the time to explain in so much depth how (and why) this works the way it does.
It’s certainly aggravating that MacOS can’t do this right, but unless the changes in Fangtooth magically improve things, that’s a bug Apple needs to address.
At this point I’m not sure they care about doing that, but I’ve got some ideas for how to approach it from that side of things. … I’ll report back if I actually get anywhere on that end.
Do you think it’s worth filing a bug report with the SAMBA team? That note about locks has been in their docs since at least 2017, so it’s not like they don’t know this is a thing.
@winnielinnie Thanks for the info on getting this working with Dolphin (the KDE file manager) actually implements this correctly. From the SMB doc on server-side copy, it’s very much up to the individual Linux distro to call the correct functions at the right moment.
It’s less than ideal that it only works if you mount the share a certain way, but … alas. Linux®.
I don’t think its a bug… its just a warning that server side copy is not magic. If you copy 1TB, it might take some time. ZFS is faster, but SAMBA does not assume ZFS.
Its not a bug until its been tested When there is a way to replicate, we can see if its a configuration issue, a bug, or it works.
Thanks - so can you explain again why Samba’s implementation of server-side copy for MacOS would not work, or be dangerous, in TrueNAS? Is there a real identified issue here, or just the case that you haven’t tested it and want to ensure it doesn’t break anything?
I also still don’t get this discussion about smbd being the ”client” in this scenario or whether someone believes the locking to be global for all clients across all files (can’t be the case), or all clients for that particular file (logical and would ensure integrity) or just that particular client while the server-side copy is ongoing (but not for other clients).
There were some comments above to the tune of “we are looking at it but it’s complicated and not just the case of flicking a switch”. So with greatest respect, you are not being very clear. What is it that you want someone to test? Whether SMB server-side copy with MacOS clients actually works at all, or not? (The Samba documentation would suggest not, with the current config, as would testimonials here and in blogs linked above.) Whether you already know that it doesn’t, and rather whether that configuration switch resolves it? Or whether it causes other unforeseen issues?
When there is a way to replicate, we can see if its a configuration issue, a bug, or it works.