On 7/19/07, Abdul Khan <[EMAIL PROTECTED]> 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;
[EMAIL PROTECTED] 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;
[EMAIL PROTECTED] admin]# cat /etc/group | grep vchk*
vchkpw:x:89:
[EMAIL PROTECTED] 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
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
