Thanks Andy, for pointing that out. So it seems to be a "feature" of how
rsync handles permissions.
I've been fiddling around with those rsync options, but I couldn't get
it right. That's not a biggy though, I'll take an other approach: use
rsync to copy the data over and afterwards correct the ACLs on the
target by running commands like:
"find <location> type -f -exec /usr/bin/chmod <file-ACLs> && find
<location> type -d -exec /usr/bin/chmod <dir-ACLs> && chmod
<file-and-dir-ACLs>"
That will get me where I want to be.
@Paul: both sides are indeed ZFS, but send/receive in this case is not
an option, as I'm trying to split a large dataset (with a number of
toplevel subdirectories) into multiple smaller datasets (one per
toplevel subdir). But the above strategy will get me there, it just
requires one extra step.
Cheers,
Andries
On 2018-03-09 9:59, Andy Fiddaman wrote:
On Thu, 8 Mar 2018, Paul B. Henson wrote:
; > From: Andries Annema
; > Sent: Thursday, March 8, 2018 8:06 AM
; >
; > But the issue seems unresolved when:
; >
; > - using rsync to copy stuff over from one dataset to another.
;
; I don't think rsync understands ZFS ACLs? So it is most likely trying to
duplicate the mode bits while copying, using chmod...
rsync explicity does do that, it tries to make the permissions on the target
file match the source, including ACLs where it can (I'm also not sure if it
supports NFSv4 ACLs).
From the man page:
To give new files the destination-default permissions,
make sure that the --perms option is off and use
--chmod=ugo=rwX (which ensures that all non-masked bits get
enabled).
So, give this a go:
rsync -a --no-p --no-g --chmod=ugo=rwX src/ dst/
The extra options need to come after -a.
Regards,
Andy
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
