"John R. Jackson" wrote:
>
> >I checked the /etc/passwd and /etc/group files which had user/group
> >nobody with the id of 4294967294. After I changed that ...
>
> Ummm, you changed the gid and uid of "nobody"? That was probably kind
> of rash. There are things floating around that know about
>I checked the /etc/passwd and /etc/group files which had user/group
>nobody with the id of 4294967294. After I changed that ...
Ummm, you changed the gid and uid of "nobody"? That was probably kind
of rash. There are things floating around that know about that and
expect a specific value. Li
Thanks to both John and Jonathan!!!
I checked the /etc/passwd and /etc/group files which had user/group
nobody with the id of 4294967294. After I changed that, I ran amdump
and still got the same error. I found a directory with the uid/gid as
4294967294. When I changed that, no more errors!
>Anyone know what's going on with runtar?
Runtar is a simple wrapper around GNU tar. It's only point in life is
to be setuid-root so it can pass that privilege on to GNU tar. It's
GNU tar that's having trouble with the unsigned long uid_t on AIX.
Actually, that's not even quite true. The ta
Hi Terry,
I have seen this problem with Unix computers running either Samba,
Appletalk sharing, or PCNFS. Something, possibly a misconfigured Samba,
is probably using that UID as the "nobody" UID. If you're not using
Samba for anything and it's just installed and "turned on" I think it
would be
I ran amanda last night and received the below report. The client with
the error (hendrix) is an AIX machine running amanda v2.4.2p1. I tried
checking out the UID's in /usr but didn't find anything out of the
ordinary.
I've also included sendback.debug and sendsize.debug to see the actual
comm