[TrueNAS SCALE 24.04] How Best to Rsync Data from One Dataset to Another from Web Console?

Software & Web Applications
1

Hello,

I’ve got a TrueNAS SCALE 24.04 server set up, and I’ve run into an odd challenge.

I have a single, monolithic EVAC dataset that contains a folder tree from my old NAS, and I’d like to create new datasets for various different folders in EVAC. (That is, there’s a whole directory of archived backup files, that belong in a BACKUP-ARCHIVES dataset.)

Since EVAC is a giant, monolithic dataset that contains folders that should have been (but are not) their own datasets, I can’t just use replication to get out of this problem.

EVAC is owned by a different user and group than any of the target datasets where I want to move the data.

So, from the TrueNAS CLI, as either admin or root, I tried this:
rsync -hav --progress /path/to/EvacDataset/folderToMove /path/to/NewDataset1/

Except, even as admin or root (via sudo su - as admin, I get a flood of permission denied errors that pretty much kill the entire transfer. I suspect that the rsync process doesn’t have the right privileges to sync files between different datasets that each have different owners and groups.

I can mount EVAC and each target dataset via SMB on a remote machine, and then rsync between those mounts, but that is just mind-numbingly slow. Like, 5-30 MB/s at best when trying to transfer gigabytes of data at a time, slow. I’ll do it if I have to, but I should be able to move the data entirely on the server.

What do I need to do to get rsync working entirely on the server? I’ve thought about trying to use SSH with rsync (e.g., by using ssh into localhost to define the source and target) but that still seems more complicated than this should be.

I’d appreciate any suggestions.

2

I just did a test running as root copying from one dataset to another using:

rsync -r --progress --stats /mnt/pool/dataset1 /mnt/pool/dataset2

I am using TrueNAS Scale 24.04 and I did not get any permissions issues. I have had to do this many times, not sure what would cause that.

1 Like
3

Thanks! Glad to hear it worked for you; it seemed very bizarre to me that it wouldn’t be just that easy.

Is there a reason you didn’t use the -a flag? Is that less likely to work?

EDIT: Is it possible that I’m running into trouble because the owners of dataset1 and dataset2 are different? They don’t share any users with modify access between them except admin and root, though I’d think those would be enough … especially when running rsync as root.

4

The root user should be able to override any permissions and then change them as needed once the transfer is done.

1 Like
5

Thanks again.

I’ve been reading the rsync man page again, and I noticed that -a, which I’d been using up to this point to try to preserve the file attributes (creation/modify dates, mostly) since these are archives of old backups I’m trying to move, doesn’t automatically preserve hardlinks.

Mac OS loves hardlinks, and since this is a 1:1 backup of a Mac OS file system, I’m wondering if failing to preserve the hardlinks was my problem when trying to use the -a flag.

I’ll need to experiment a bit more.

6

@LTS_Tom Sorry to double-post. I wanted to add a note to follow up on the -a issue. Adding the -a option definitely breaks the sync. It errors out on almost every file, and in my test case only transferred ~10 MiB of ~50 GiB.

I read the manual a bit more and saw that -a attempts to preserve file permissions. Given how different the permissions were on (1) the Mac where these files came from, (2) the ext4-based QNAP where they were stored before getting copied over to the TrueNAS via SMB the first time, and (3) the TrueNAS dataset where I’m trying to put them, the trainwreck makes more sense.

I think it ends up throwing a bunch of permissions errors because it’s attempting to preserve Mac OS and or SMB file permissions (somehow?) into a ZFS file system that uses an entirely different permissions structure and can’t just magically convert them.

Since I still wanted to use -a to preserve as much metadata as I could, as well as -H in case I needed it for Mac OS hardlinks, I tried this:

rsync -hav -H --no-perms --progress --stats --exclude=.DS_Store

It seems to have worked. :slight_smile:

Number of files: 171,055 (reg: 123,979, dir: 47,076)
Number of created files: 171,055 (reg: 123,979, dir: 47,076)
Number of deleted files: 0
Number of regular files transferred: 123,979
Total file size: 58.25G bytes
Total transferred file size: 58.25G bytes
Literal data: 58.25G bytes
Matched data: 0 bytes
File list size: 9.37M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 58.28G
Total bytes received: 2.60M

sent 58.28G bytes  received 2.60M bytes  146.99M bytes/sec
total size is 58.25G  speedup is 1.00

Comparing that to the source, it appears to have copied everything (I assume the numbers are different due to a bit of overhead, or one of them being in GB and the other being in GiB, or something).

The source:

admin@vectorsigma[...Evac/BackupArchives/crashplanArchives]$ sudo du -sh Dorothy\ I 

47G     Dorothy I
1 Like
7

I don’t think I can edit my last post, as it’s been too long…

I was trolling the TrueNAS SCALE documentation trying to get a better understanding of the ACL options while setting up a dataset, and accidentally ended up in the Permissions/ACL documentation for CORE, at Permissions | TrueNAS Documentation Hub.

I’m glad I did, as it contains this text on ACL types and their relation to how SMB works, which is not in the documentation for SCALE, as far as I can tell:

Access Control Lists
An Access Control List (ACL) is a set of account permissions associated with a dataset and applied to directories or files within that dataset. ACLs are typically used to manage user interactions with shared datasets and are created when a dataset is added to a pool.

When creating a dataset, you can choose how the ACL can be modified by selecting an ACL Mode:

  • Passthrough only updates ACL entries (ACEs) that are related to the file or directory mode.
  • Restricted does not allow chmod to make changes to files or directories with a non-trivial ACL. An ACL is trivial if it can be fully expressed as a file mode without losing any access rules. Setting the ACL Mode to Restricted is typically used to optimize a dataset for SMB sharing, but can require further optimizations. For example, configuring an rsync task with this dataset could require adding --no-perms as an extra option for the task.

Emphasis added to the last sentence there. If I’d found this right off, it would’ve saved me about half a day of troubleshooting (and I probably wouldn’t have posted this thread).

This was the exact issue I was experiencing with rsync on a share configured with the SMB preset: rsync failed until --no-perms was included in the command.

I need to print out this chart, but since SMB is the only one that uses Restricted mode, I think it’s the only one that needs the no-perms argument for rsync:

image
image1392×462 40.2 KB

Now I’m a bit paranoid about how much useful information is in the CORE documentation that I’m not seeing because I’m using the SCALE docs… I’ll have to start checking them both. I’m not going to assume that they’ll have information parity someday.