Steven, Of course, the destination side must have enough rights to achieve what I need, and an rsyncd running as root:root surely have all the necessary rights. So using --perms with this daemon must have been sufficient. But not, it is simply not true, because the daemon has a built-in "assumption" which overkills it. I know rsync sends its command line parameters to the daemon, so rsyncd could have been able to handle the case, but instead of recognizing the flag it simply makes that assumption.
I think all the permission/ownership handling is complicated (unaccountable, puzzling, peculiar) and the usage is confusing and annoying, it should be reworked in a much more consistent way: 1. use exactly the same options on both sides 2. specify which attributes to transfer (keep) and which ones to set explicitly (including permissions, ownership, time and probably acl also) 3. define defaults 4. define a precedence (like: source filesystem, sender config, receiver config, receiver user rights, defaults) 5. describe actions taken in case of insufficient rights (just another example: client side -E, server side incoming chmod u+x,g-x and outgoing chmod u+x,g-x: what is the expected result when sending or receiving files?) Using aliases these can be mapped to the actual flags - for backward compatibility Andras -----Original Message----- From: rsync-boun...@lists.samba.org [mailto:rsync-boun...@lists.samba.org] On Behalf Of Steven Levine Sent: Thursday, August 09, 2012 21:37 To: rsync@lists.samba.org Subject: RE: cannot rsync when source directory lacks write permission In <64fab8215d47a944abdf7de50a3406a219c2dac...@esesscms0353.eemea.ericsson.se>, on 08/09/12 at 07:54 AM, András Porjesz <andras.porj...@ericsson.com> said: Hi, >Thanks, it looks ok, just it is not documented anywhere: >From the ryncd.conf man page uid This parameter specifies the user name or user ID that file transfers to and from that module should take place as when the daemon was run as root. In combination with the gid parameter this determines what file permissions are available. The default is uid -2, which is normally the user nobody. >it overwrites >the -perms flag on the other side. Not really. Se below. >So read documentation, it is >definitely against it: "In summary: to give destination files (both old >and new) the source permissions, use --perms." I assume you are referring to the rsync man page which says -p, --perms This option causes the receiving rsync to set the destination permissions to be the same as the source permissions. (See also the --chmod option for a way to modify what rsync considers to be the source permissions.) What it does not say is that the receiving side needs sufficient permissions to be able to change the permissions. I guess the man page authors assumed that someone running rsync on *ix would understand this implicitly. Running the receiving side as root is one option for ensuring that the receiver can change permissions. There are others that are more secure. Running the receiver as the default nobody user does not turn off --perms, it simply ensures that the attempt to change permissions is very likely to fail. One way to make it not fail is to have the module root owned by nobody. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" <stev...@earthlink.net> eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com ---------------------------------------------------------------------- -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
