Rsync Permission Issues

Matt McCutchen hashproduct+rsync at gmail.com
Fri Feb 16 22:35:19 GMT 2007


On 2/16/07, Chris Nighswonger <cnighswonger at foundations.edu> wrote:
> It did turn out to be a permissions issue, but on the client
> directory. Take a look at my last reply to the list for my full
> explaination of what I found out. I cannot explain why, maybe someone
> with more experience can.

To finish off your nice explanation, I'd like to add why bad
permissions on the *client* caused errors on the *server*.

Since you did not use --perms, rsync sets the permissions on a newly
created server file to the bitwise "AND" of the corresponding client
file's permissions and the default permissions on the server, which
are usually determined by the rsync daemon's umask.  Thus, if a client
directory missing "x" permission is newly copied to the server, the
server directory will always be missing "x" permission.  If the server
process is not running as root, it would then get an error when it
tries to access things inside the directory.  If you ran rsync as root
on the client, that would explain why there were no errors on the
client.

Developer's note: rsync forces "w" permission on for the owner of a
directory while receiving files into that directory (line 1829 of
generator.c in the current CVS rsync) and then turns off the
permission later if it should be off.  One could argue that rsync
should also force "x" permission on.  On the other hand, if a
directory owner is missing "x" permission, that is usually a mistake
that the user will eventually have to fix anyway, so rsync might as
well call it to his/her attention.

Matt


More information about the rsync mailing list