I do need -R since I cascade different directories. Without the -R, the destination backup would be a mess! Regarding the source trailing slash, it has NO impact on server1 permissions/uid:gid if I have the -R option set. Without the -R option however, server1 permissions/uid:gid change indeed (as you announced).
Sure, I understand you need -R. I was not questioning that at all... Just highlighted the impact of using -R vs not using it on the permissions on folder server1/ (as well as when having a trailing /).
nixjps wrote:BTW, unless I'm wrong it's better to not use trailing slash in source path when you want to sync a tree.
As I did yot see any change in behavior on the destination side, I decided to leave the trailing slash in the source to show that it's a directory and not a file I rsync. But if you tell me that functionality changes due to this, I will delete it of course.
Well, for sure it has an impact. Unless i'm wrong, in source, a trailing slash tells rsync to sync the content of folder (and sub folder with -r) , when no trailing slash and source is a folder, rsync syncs folder (and sub folder with -r).
Actually, with -R, it may seem it has not significant impact on the tree in target (though we can see perms of server1 are handled slightly differently)
To be honest, I remember from old days that it had some undesired effects but I do not recall exactly which side effects.... Just googled.... See http://defindit.com/readme_files/rsync_backup.html
(see comment ion point 1 and point 2b)...
nixjps wrote:I suggest you run both "non -R" command with -by adding one or two additonal "v" on your option and compare result.
I didn't even know rsync would take more than 1 -v
Yep... ;-D the more v you have the more verbose is the output ;-D
You mean I should add the optiions -b and -y?
er.... no, no.... my bad.... I must have started writing "with -vvv" then change my mind to "by adding" and forgot to clean up the sentence ;-O...
I was suggesting you run the commands on both rsync client and add a few additional 'v' to increase "debug" output.
So rsync -avrR could be -vvv -arR...
Knowing that they do have different client rsync version, comparing "-v" results could be interesting...
However, I made a couple of tests yesterday using two different versions of rsync on client side and did not notice differences in behavior as far as server side (synology) is concerned. May be you testbed is different.
Bottom line ... we're down to the permission of the destination server1 created by rsync. uid:gid are now correct. So we are getting closer every day.
Permissions on destination folder/file is preserved when the folder/file is in the tree to copy.
The destination folder (QQQ:server1 and QQQ:server2) when it's not part of the tree is created with default system permissions.
(BTW, in rsync 3.0.9, before creating the top level destination directory, program saves umask value, sets umask to 0, creates the directory and sets back umask to original value. In more recent version it simply creates directory with default permission 0777, so process umask value is used)....)
On synology, it seems that that when using -R, the target directory inherits the default ACL permissions with or without trailing / in source. Same behavior when not using -R and no trailing / in source. When using -R and a trailing / in source, ACL is cleared and default 0777 permission is used. Makes sense to me as I believe its in fact driven by the client. See later why.
Remains however the question about why rsync adds ACL permissions to server1.
Actually, I believe that what is happening is not that rsync adds ACL permissions.... What happens is that it uses mkdir(3) with mode 0777 to create folder 'server?', that folder being in one that has ACL ans inheritance set.... So folder 'server?' inherits....
Question is in fact why does this not happen when we use -R and and a trailing / in source?.... I suspect that if we paused or killed the transfer just after creation, we would see that 'server?' inherits ACL....
When we wait until end of transmission permissions, ownership and group membership are set according to source (assuming -pog and user is root). As we are using a trailing slash, a chmod(3) is done on folder 'server1' with the permissions of source './'.... That clears ACLs.
I may be wrong, but this must be close to what is going on....
... later ...
Code: Select all
root@nas:/volume1# cd abc/
root@nas:/volume1/abc# mkdir dir1
root@nas:/volume1/abc# ls -l
d---------+ 1 root root 0 Sep 6 18:28 dir1
drwxrwxrwx+ 1 root root 8 Sep 4 17:10 @eaDir
root@nas:/volume1/abc# cd ..
root@nas:/volume1# mkdir def
root@nas:/volume1# cd def
root@nas:/volume1/def# mkdir dir2
root@nas:/volume1/def# ls -l
drwxr-xr-x 1 root root 0 Sep 6 18:28 dir2
root@nas:/volume1/def# ls -l ..
d---------+ 1 root root 20 Sep 6 18:28 abc
drwxr-xr-x 1 root root 8 Sep 6 18:28 def
Directory abc was created via DSM. ACLs!
Directory dir1 was created inside abc via shell/mkdir. ACLs!
Directory def was created via DSM. ACLs!
Directory dir2 was created inside def via shell/mkdir. No ACLs!
Wild idea ... could it be that, due to the fact that directory abc was initially created via DSM, this makes that server1 also has ACLs while using the -R option?
Not so wild.... Yes.... Correct.
BTW, you wrote "Directory def was created via DSM
. ACLs!". I believe you meant with "shell/mkdir"... At least this is what the quote shows... that is.... abc, created with DSM, has ACL, so dir1 gets it too. While def created from shell in /volume1 has no ACL, hence dir2 has none too.
However this doesn't explain why server2 doesn't have ACLs with the -R option.
I would suggest you redo the test to make sure that behaviour is not as discussed above.