On Thu, Jun 25, 2009 at 2:29 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On Friday 26 June 2009 00:04:02 Alfred Monticello wrote:
> > in doc/Makefile, tar is run to extract an archive with xf options. Needs
> > oxf to map to owner of person running tar, otherwise Invalid Argument
> > occurs and the Makefile errors out.
> > A better solution might be to compact postgres as UID/GID 0 instead of
> > 258 which does not exist on my system.
> > Problem only occurs when mounting NFSv4 from a Solaris box using ZFS.
> > Client is Ubuntu Jaunty. Tar tries to preserve UID 258 but errors out
> > because it doesn't exist.
> Are you running the extraction as root user?
Yes. I am user root. It is an interesting problem. Tar fails because it
tries to preserve ownership and group.
However over an NFSv4 and ZFS, the NFS client where I am working on tries to
remap unknown usernames and groups to nobody.nogroup, which tar does not
seem to like. I tried GNU version 1.22 and it also failed the same way. I
can manually run chown or chgrp to an unknown UID and GID, and they will get
mapped as nobody.nogroup. So I guess the source of the problem really lies
I'm working on a new server and am building a several of source packages.
Postgres and Apache httpd are the only two out of about 25 that have had
this problem. Postgres had a problem as soon as I unpacked it with tar, it
complained about UID 258. All the other packages I have unpacked with tar
unpacked with 0 as the UID and GID.
make -C doc all
make: Entering directory `/nfs/fsp1/web/postgresql-8.3.7/doc'
gzip -d -c man.tar.gz | /bin/tar xf -
/bin/tar: man1/clusterdb.1: Cannot change ownership to uid 258, gid 258:
/bin/tar: Error exit delayed from previous errors
make: *** [manl/.timestamp] Error 2
make: Leaving directory `/nfs/fsp1/web/postgresql-8.3.7/doc'
make: *** [all] Error 2
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2009-06-26 00:44:40|
|Subject: Re: BUG #4883: tar xf fails on NFS4 mounts |
|Previous:||From: Tom Lane||Date: 2009-06-26 00:25:59|
|Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |