files permission and hidden files are not rsync properly

[Matt McCutchen]

On 7/19/07, Abdul Khan <akhan at systems.fleetwoodmetal.com> wrote:
>  > In the future and if you need more help on this issue than the below,
> > please send the exact rsync command you used!
>
>  Here is the command that I ran from the destinition machine which is also
> running the rsync daemon or the rsync server;
>
> [root at mail admin]# rsync --verbose --progress --stats --recursive
> /home/vpopmail/ 192.167.1.61::email_backup/
>
> they are not symlinks as log mentioned they are hidden files (or dot
> files),

"Hidden file" is not a file type.  On Unix-like systems, the concept
of hidden-ness does not exist at the filesystem level or in most
filesystem tools (e.g., rsync).  That a file whose name begins with a
dot is considered hidden is merely a convention among the user
interfaces of most file listers/browsers and a few other tools.

> so is there any thing specific that I have to add in the command
> to copy those as well?

As per the above, dot files are nothing out of the ordinary to rsync
and no special option is needed to make rsync copy them.

Please send the "ls -la" output showing the dot files so I can see
what their file type is (as indicated by the first character of each
line of the  listing).

>  > By default, rsync preserves owners and groups by name if possible or
> > otherwise by number. That means if the destination machine lacks a
> > "vpopmail" user and a "vchkpw" group, rsync sets the same numerical
> > IDs on the destination as on the source. If those IDs represent
> > "nobody" and "nobody" on the destination, the files get that
> > ownership. Creating "vpopmail" and "vchkpw" on the destination
> > machine should fix the problem.
>
>  The destination machine is actually the mirror of the source so both
> mochines are identical and both "vpopmail" user and "vchkpw" group do
> exist on the destinition.
>
> here is the evidence of "vpopmail" and "vchpkw" on the destinition;
>
> [root at mail admin]# cat /etc/group | grep vchk*
> vchkpw:x:89:
> [root at mail admin]# cat /etc/passwd | grep vpopmail
> vpopmail:x:89:89::/home/vpopmail:/bin/bash

I just realized a much more likely cause of the problem.  If the rsync
daemon on the destination is started as "root", by default it changes
IDs to "nobody:nobody" before accessing the module and thus loses the
power to set the owners of received files arbitrarily (in this case,
to "vpopmail:vchkpw").  To make the daemon stay as root so it can
chown the  files, explicitly say "uid = root" and "gid = root" in the
rsyncd.conf .

Matt