# RSync defunct: invalid user nobody

## Dragonlord

Suddenly this week my Gentoo Portage Server stopped working. Whenever I try to sync using a client I get the following:

 *Quote:*   

> # emerge --sync
> 
> >>> Starting rsync with rsync://192.168.1.10:880/portage...
> 
> >>> Checking server timestamp ...
> ...

 

And so forth. The rsyncd.conf contains still the same as it did before:

 *Quote:*   

> pid file = /var/run/rsyncd.pid
> 
> max connections = 5
> 
> use chroot = yes
> ...

 

I also tried "-2" but nothing works. Nobody does exist and is as it should be

 *Quote:*   

> uid=65534(nobody) gid=65534(nobody) Gruppen=65534(nobody)

 

What's going on? Why can rsync "suddenly" no more work with UID? Some code changes or something else going on? Since I can't sync anymore my clients right now and this is annoying.

Concerning infos:

net-misc/rsync-3.0.5  USE="iconv -acl -ipv6 -static -xattr -xinetd"

Linux server 2.6.20-hardened-r5 #6 SMP Thu Aug 2 16:24:16 CEST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ AuthenticAMD GNU/Linux

----------

## linear

Okay,

I see that you have "use chroot = yes", and from the 'man rsyncd.conf' documentation:

```
              When "use chroot" is false or the inside-chroot path is not "/",

              rsync will: (1) munge symlinks by default for  security  reasons

              (see  "munge  symlinks"  for a way to turn this off, but only if

              you trust your users), (2) substitute leading slashes  in  abso-

              lute  paths  with  the  module's  path  (so that options such as

              --backup-dir, --compare-dest, etc. interpret an absolute path as

              rooted  in the module's "path" dir), and (3) trim ".." path ele-

              ments from args if rsync believes they would escape  the  module

              hierarchy.   The  default  for  "use chroot" is true, and is the

              safer choice (especially if the module is not read-only).

              When this parameter is enabled, rsync will not  attempt  to  map

              users  and  groups by name (by default), but instead copy IDs as

              though --numeric-ids had been specified.   In  order  to  enable

              name-mapping, rsync needs to be able to use the standard library

              functions for looking up names and IDs (i.e.  getpwuid() ,  get-

              grgid()  , getpwname() , and getgrnam() ).  This means the rsync

              process in the chroot hierarchy will need to have access to  the

              resources   used   by  these  library  functions  (traditionally

              /etc/passwd  and  /etc/group,  but  perhaps  additional  dynamic

              libraries as well).
```

So, if I read this correctly, if you do not have an /etc/passwd and an /etc/group within the chroot module's filesystem, it will not be able to figure out who nobody:nobody is.   Also, I wonder if the order of the configurations within the rsyncd.conf is significant...  I noticed in the example within the man page that they put the "uid = nobody' and 'gid = nobody' before the 'use chroot = yes'.  

```
       A more sophisticated example would be:

       uid = nobody

       gid = nobody

       use chroot = yes

       max connections = 4

       syslog facility = local5

       pid file = /var/run/rsyncd.pid

       [ftp]

               path = /var/ftp/./pub

               comment = whole ftp area (approx 6.1 GB)

       [sambaftp]

               path = /var/ftp/./pub/samba

               comment = Samba ftp area (approx 300 MB)

       [rsyncftp]

               path = /var/ftp/./pub/rsync

               comment = rsync ftp area (approx 6 MB)

        <snip>
```

Not sure if that is pertinent to this issue, but it would be something to check.

HTH.

----------

## Dragonlord

It seems to work with directly using the UID of nobody. Strange thing though since nobody has / as home so it should have access to everything it needs to figure out the UID from the username.

----------

## linear

Yes... and there is the rub.

Nobody can have a home of '/', but where is your chroot starting?  Is '/' the root of the overall chroot filesystem?  Or are you chrooting to another location like /usr/portage or /pub/portage or something like that?

If I understand it correctly, what the manual was saying is; If you are setting up a chroot and the root of the rsync chroot is *not* '/', then you will have issues mapping names to UIDs, *unless* you have something set up within the chroot to help with the mapping.  By default, it will look for /etc/passwd and /etc/group to help with the mapping and may need some other dynamic libraries as well.

HTH.

----------

## curmudgeon

I am having this problem now:

```

# SYNC=rsync://server/gentoo-portage/ emerge --sync

>>> Starting rsync with rsync://192.168.0.1/gentoo-portage/...

>>> Checking server timestamp ...

@ERROR: invalid uid nobody

rsync error: error starting client-server protocol (code 5) at main.c(1516) [Receiver=3.0.9]

>>> Retrying...

!!! Exhausted addresses for server

```

This clearly began after the upgrade (on the server side) of glibc from 2.13-r4 to 2.14.1-r3.

The client has no problem syncing with rsync.gentoo.org.

Any thoughts?

----------

## curmudgeon

Rebuilding rsync solves the problem. That should be noted somewhere.

----------

## gbetous

Hi !

Thanks for the tip !!!

I rebuild both on client and server side, and restarted rsyncd on server. Then it works fine.

----------

## curmudgeon

Seems the developers know about it (but it won't get fixed until glibc 2.15.

https://bugs.gentoo.org/show_bug.cgi?id=414843

----------

## figueroa

I just got bit by this. I maintain a local repository to support several local Gentoo machines. I found this thread, rebuilt rsync and restarted rsyncd on the server only and all is well again.

----------

## jlpoole

 *figueroa wrote:*   

> I just got bit by this. I maintain a local repository to support several local Gentoo machines. I found this thread, rebuilt rsync and restarted rsyncd on the server only and all is well again.

 

Thank you, figueroa. Like you, I have one Gentoo server that serves several local Gentoo servers with the portage snapshot.

I have an older server that had this problem too.  I rebuilt rsync. Tried and got the same error message.  I then restarted the rsync daemon on the very new server and then tried again to emerge --sync from the old server and it worked, too.

I'm guessing that the rsync daemon caches values that get reset on "restart" of the daemon.

----------

## pascuol

Same error after upgrade of glibc to : sys-libs/glibc-2.28-r6

restart of rsyncd on server side was enough

 :Cool: 

----------

## twalter

Add another to the list.  Weird how it's the first time after all these years.

----------

## figueroa

Still not fixed, nor any warnings, x86 server updated to sys-libs/glibc-2.32-r2 three days ago. Rebuilding rsync on the server and restarting rsyncd is still the fix.

----------

## hardly

+1 

Thanks for the cool thread guys. Still relevant!

----------

## r7l

Ran into this issue just now. Rebuilding Rsync did fix the issues as said years ago. Seems still relevant. Thanks

----------

## freke

 *r7l wrote:*   

> Ran into this issue just now. Rebuilding Rsync did fix the issues as said years ago. Seems still relevant. Thanks

 

Recently updated sys-libs/glibc?

https://forums.gentoo.org/viewtopic-t-1147884.html

----------

## r7l

You're correct. Must have missed that message. Thanks allot!

----------

