Hello,
I noticed that running rsync with a command such as:
rsync -a source host::module/deep/path
...doesn't create the directory "deep" if it doesn't exists, whereas the
command:
rsync -a source host::module/singlefolder
*does* create "singlefolder". Is it the wanted behaviour? I tried to
modi
I just thought of something else that I should have thought of earlier:
if you're using a chroot=yes setup for an rsync daemon, you must put the
appropriate files into the chroot area for rsync to do any mapping of
UIDs and GIDs (as explained in the man rsyncd.conf manpage). For
instance, create a
How can I check whether rsync uses /etc/nsswitch.conf or not?
I'd suggest finding a Linux forum to ask that question (and first
googling to see if the answer is already out there). I'd also suggest
creating a simple test program that just tries to lookup "testuser"
using getpwnam() (you could eas
1. The receiving rsync isn't linked with the right library for
getpwent() to find the name on that Linux system.
This could indeed be the case, but I don't know how to check/solve this.
I'm using nsswitch with winbind...
/etc/nsswitch.conf:
passwd: compat winbind
group: compat wi
Lookup of `testuser' failed
Exactly as I expected. As long as there are no weird non-visible
characters in that name (which I assume there are not), then you just
need to figure out how to get the "testuser" into your defined users on
the Linux box. (Try running something like "groups testuser"
Does the client side send 11385 or "testuser"? Or both?
It sends both (it sends a mapping table of UID/name pairs before it
sends the UIDs attached to the file-info). The fact that your server
got the name but didn't change the UID to the right value indicates to
me that the getpwnam() call didn'
All I get running with - is the gid...
That is because rsync doesn't believe that it is root. I think I should
modify rsync so that it outputs the uid when it is the sender even when
it is not root.
What your output doesn't show is what the receiver thinks the uid is
(which will show if it be
testuser:x:1:1:testuser:/home/DOMAIN/testuser:/bin/false
[...]
DOMAIN\testuser:x:1:1:testuser:/home/DOMAIN/testuser:/bin/false
I'd suggest running with expanded levels of -v until you see what user &
group names are getting sent. I'd bet that the two strings don't match
(as they d
Why does the rsync running on the client must be root ? It just has
to send the name of the owner of the file to the server which will
chown it.
I misread it as the receiver at first glance, thus the confusion.
You're right that the sender doesn't need to be root. However, this
topic split into
On Thu, Sep 09, 2004 at 11:46:48AM +0200, Essyug wrote:
Why does the rsync running on the client must be root ? It just has to
send the name of the owner of the file to the server which will chown
it.
I misread it as the receiver at first glance, thus the confusion.
You're right that the s
Rsync seems to work as if I had used the --numeric-ids
If rsync doesn't find a username match, it will fall-back to using the
ID directly, so I would assume that the problem is that the ID names on
your cygwin system aren't matching the ID names on your linux system
(and perhaps they aren't what y
My test directory on W2k and all its content are owned by
DOMAIN\testuser, which is a domain administrator.
Rsync only tries to change file ownership if it thinks that it is
running as root, and that test is currently a simple comparison of the
effective UID against 0. You might try outputting t
Hello,
I'm setting up a Linux backup server for Windows Workstations, using
rsync-2.6.3pre1+acl on the server and cygwin rsync-2.6.2-2 on the
Workstations. At this point, I don't care about perserving the acls ; I
only want to preserve the ownership of the files. My server is running
in daemon mode
13 matches
Mail list logo
