rsync -a from PC to SCALE NFSv3 share doesn't preserve user:group

[SnoppyFloppy]

Hi

I want to reformat my PC so I want to rsync all users ~/home to a newly created dataset/NFS(v3) share on my Scale server but even when using the -a flag, the user:group is overwritten in the process.

If i run rsync as myself, files that are owned by anyone else will get user:group overwritten with me as owner and group on scale. If i run rsync as root files will be owned by nobody:nogroup.

The dataset doesn't have any ACL defined and have 777 permissions (for the test) and I've tried both setting myself (same uid, gid and name as on my PC) and root as owner and in both tests. Further more, "Apply Permissions Recursively" in unchecked.

For the NFS share all of the 4 the map all users as..., map root as..., etc. have been left blank.

Any ideas what I am doing wrong?

 

[anodos]

Hi

I want to reformat my PC so I want to rsync all users ~/home to a newly created dataset/NFS(v3) share on my Scale server but even when using the -a flag, the user:group is overwritten in the process.

If i run rsync as myself, files that are owned by anyone else will get user:group overwritten with me as owner and group on scale. If i run rsync as root files will be owned by nobody:nogroup.

The dataset doesn't have any ACL defined and have 777 permissions (for the test) and I've tried both setting myself (same uid, gid and name as on my PC) and root as owner and in both tests. Further more, "Apply Permissions Recursively" in unchecked.

For the NFS share all of the 4 the map all users as..., map root as..., etc. have been left blank.

Any ideas what I am doing wrong?

In the root case, root is getting squashed by default to nobody:nogroup. That's expected behavior and a security feature. If you want uid 0 on client to be uid 0 on server, then you should maproot to root.

That said, I don't understand rsync usage here. Why don't you just tar up the home directory and copy over to the NFS export, then copy back / untar when you're done?

 

[SnoppyFloppy]

In the root case, root is getting squashed by default to nobody:nogroup. That's expected behavior and a security feature. If you want uid 0 on client to be uid 0 on server, then you should maproot to root.

That said, I don't understand rsync usage here. Why don't you just tar up the home directory and copy over to the NFS export, then copy back / untar when you're done?

The root part makes sense. It was not that I wanted root as owner, just trial and error.

Regarding why rsync, I was just using the tool I know and have good experience with. And I thought it was good for this use case because of the -a feature/flag.

That said, do you understand why rsync doesn't preserve owner:group with -a?

 

[anodos]

That said, do you understand why rsync doesn't preserve owner:group with -a?

The user doing rsync isn't super-user on the remote server.

Code:

smbuser@TN3:/tmp$ touch foo
smbuser@TN3:/tmp$ chown nobody foo
chown: changing ownership of 'foo': Operation not permitted

This is how permissions work on Unix.

 

[SnoppyFloppy]

The user doing rsync isn't super-user on the remote server.

Okay nice to know. I didn't know that my users privileges on the server had any relevance when "just" rsync'ing files to a nfs share. Can I solve this by adding the server user to a certain group?