cannot rsync when source directory lacks write permission

[András Porjesz]

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-bounces at lists.samba.org [mailto:rsync-bounces at lists.samba.org] On Behalf Of Steven Levine
Sent: Thursday, August 09, 2012 21:37
To: rsync at lists.samba.org
Subject: RE: cannot rsync when source directory lacks write permission

In
<64FAB8215D47A944ABDF7DE50A3406A219C2DAC909 at ESESSCMS0353.eemea.ericsson.se>,
on 08/09/12
   at 07:54 AM, András Porjesz <andras.porjesz at 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" <steve53 at 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