Hello, I’ve been using Scale for a couple of years and there is one issue that keeps bugging me. I have one share that consists of several underlying ZFS Volumes. Whenever I move a file from one volume to another I always get the error “The operation couldn’t be completed. Cross-device link”. I understand the error, but a simple copy-then-delete could solve this.
(I cannot include links)
After searching a while I found about about vfs_crossrename (Samba vfs_crossrename.8.html) and I tried to put the settings into the “Auxiliary Parameters” of my share like so:
I restarted SMB service and reconnected the SMB share, but it is not working.
I also found this link: (I cannot put links) from github freenas/freenas-docs userguide/sharing.rst, its probably old as it FreeNAS and it describes a setting for VFS Objects and the crossrename option. However I cannot find this in Scale.
I couldn’t find a solution so would appreciate your help!! By the way I am using MacOS Sonoma M2 client with Scale (up-to-date).
It’s not a hard and fast rule but it’s often recommended to have one dataset per share and not nest datasets within a single share as a dataset is essentially and independent filesystem.
Most of my shares have one underlying dataset but since I have many datasets (20 or so) it is sometimes easy to manage them all at once through a single share.
What I did was just create an extra share and then set the Path to /mnt/tank which is the root of my zpool where all the datasets live. This works great for managing all at once without having to mount many shares. (I’ve been doing it this way forever, even in the era of W95/NT4, damn I feel old now)
The problem is when it comes to the move operations as I described in the original post. When I want to move files which live on one dataset to a location on another dataset within that same share, I always have to do a copy and then a delete.
The samba option vfs_crossrename is exactly to solve that problem:
The vfs_crossrename VFS module allows server side rename operations even if source and target are on different physical devices. A "move" in Explorer is usually a rename operation if it is inside of a single share or device. Usually such a rename operation returns NT_STATUS_NOT_SAME_DEVICE and the client has to move the file by manual copy and delete operations. If the rename by copy is done by the server this can be much more efficient. vfs_crossrename tries to do this server-side cross-device rename operation.
However I can’t seem to figure out how to turn that on in TrueNAS.
My version is: TrueNAS-SCALE-22.02.4. Running MacOS Sonoma 14.7.2
This is to be expected. When you move data between datasets you are essentially moving data between two independent filesystems. Almost like two different traditional servers. This is one reason why it’s recommended to have one share per dataset.
Finally it’s never a good idea to share the root dataset and instead best to create at least one dataset off that before you share out.
Did you read my post? I do have datasets within the pool, a bunch actually. I also already told that I understand the error, and there is a Samba option to circumvent. Sorry to sound critical but you’ve not been paying attention.
It’s sounds like you are sharing out the root dataset of your storage pool is this correct? If so thats not a good idea.
Secondly that samba setting you are taking about I’m guessing doesn’t appreciate that you are using zfs and trying to span datasets (independent filesystems).
I just tried this out on my TrueNAS Core 13.3-U1 server, and it works as expected, and it’s very fast.
I made an SMB share with the Default preset that points to my root dataset path.
I “cut” and “pasted” a 2-GiB movie file from one folder to another, where it has to cross filesystem boundaries between separate datasets.
The operation completely successfully and very quickly, plus it did not have to go through my network.
I used Windows 10 Explorer. No additional options or parameters were specified.
EDIT: Block-cloning was not used. Not only is block-cloning unsupported across encrypted datasets, but I confirmed that no additional BCLONEUSED appeared on my pool’s property.
Ok my reaction wasn’t meant to offend. Forums usually frustrate me and I usually try to avoid them. I’m sure it is a common thing. Ok thanks for trying to help anyway let’s try to work with it.
Is that your opinion or can you please give me an objective reason why it is a bad idea?
I don’t think that is true. I believe that setting is exactly for that reason. I will quite again from the Samba manual page:
The vfs_crossrename VFS module allows server side rename operations even if source and target are on different physical devices. A “move” in Explorer is usually a rename operation if it is inside of a single share or device. Usually such a rename operation returns NT_STATUS_NOT_SAME_DEVICE and the client has to move the file by manual copy and delete operations. If the rename by copy is done by the server this can be much more efficient. vfs_crossrename tries to do this server-side cross-device rename operation.
End quote.
Please don’t be offended if I say: but you are saying “I’m guessing”. Well let’s not guess and read the manual quote that I pasted above.
Also I did not ask for your guesses. I was asking: how I can put that setting into TrueNAS Scale. Then I can check for myself if it does what I want or not.
I appreciate you trying to help but help is not giving guesses and saying things are a bad idea without reason. It trying to understand the problem and coming up with possible solutions.
I’m still on 24.04.2.5, run MacOS Sequoia 15.3.1, but do not share the root.
I can do a copy between two datasets on the same pool mounted as two shares just fine.
Thanks for trying. This seems to be exactly what I want to accomplish. I tried it with a Windows client and it did not work for me either. You are using Core so there may be a difference there.
