BUG #4883: tar xf fails on NFS4 mounts

Are you running the extraction as root user?

As far as I can find, there is no explicit recommendation in the
installation instructions that you not do the build as root.
Perhaps we should add one.

regards, tom lane

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
with tar...

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
make -C doc all
make[1]: 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:
Invalid argument
/bin/tar: Error exit delayed from previous errors
make[1]: *** [manl/.timestamp] Error 2
make[1]: Leaving directory `/nfs/fsp1/web/postgresql-8.3.7/doc'
make: *** [all] Error 2
#

Hmm, that is *not* about unpacking the source tarball as I first thought
--- it's about unpacking the documentation sub-tarballs. Which is
something that people are quite likely to try to do as root,
particularly for the html tarball which is unpacked only in the install
step. Maybe putting "o" into the options in doc/Makefile is a good
idea. I'm wondering why we've not had complaints before, though.

BTW, why are there uses of both "tar" and "$(TAR)" in there?

regards, tom lane

I wonder why we have tarballs inside of tarballs. Why not just have
the files directly in a subdirectory of the install tarball already?
On a local filesystem tar will happily restore the user even if
there's no userid 258 in /etc/passwd. Presumably the file we
eventually install does get the right owner along the way anyways.

That's been complained about before, but getting rid of it is a larger
change than I care to undertake right now.

regards, tom lane

Oh, yeah I see that now it uses both. I sent a report to the tar group,
maybe its something they can fix. I got that error when both unpacking the
source tarball and within the doc directory.

Everything seems to work fine by hand, chown, chgrp, etc..Maybe its a system
call issue with tar, though it all worked fine in NFSv3 which does not use
an ID mapper daemon. I guess not too many people are using NFSv4 (I had to
specify nfs4 in fstab, its turned off by default in Ubuntu 9.04 jaunty).
Maybe I should go back to 3...

The only downside with adding o to tar that I can see is if it isn't
supported by a non-GNU version of tar.

It's required by the Single Unix Spec
http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html
(although that specifically disallows the ordering "oxf" that you
suggest) and I see it in tar on HPUX 10.20, which ought to be about
ancient enough for anybody.

regards, tom lane

My old BSD has:

-o Write very old style tar archive, omitting the storage of direc-
tories.

Yeah, and we later found out that it was horribly broken in GNU tar
1.14, which is still out there. So it got reverted.

I'm currently thinking that the best solution is to dodge the problem
entirely by getting rid of the sub-tarballs. There's no very good
reason why we don't ship those generated doc files "loose" in the
tarball. The man files are already extracted into man1/ and man7/
as the first step of using them, so we should just make that be the
shipped state of the tree. The .html files could similarly be dumped
into an html/ subdirectory after they're created, instead of being
wrapped up in a tarball.

regards, tom lane

On solaris 9 and 10 at least, tar -o means set ownership of extracted
files to the runner and not the uid in the tar, which I assume is what
we want here.

Note, this is on Solaris /usr/bin/tar

I'd suggest that if this works on...

A) solaris 8+
B) hp-ux
C) AIX 5.x+
D) Free/Net/OpenBSD

it would be safe for 'unix' systems, as there really aren't many other
flavors of 'unix' in common use anymore.

But it doesn't, hence this thread.

I meant rather, hence the other thread, where we had to revert this.

I think that thread was on -packagers rather than any public list.
For the record: Dave Page reported that the initial wrap of 8.4.0
failed to build on OS X 10.4. Investigation disclosed that its
version of tar was misinterpreting the "o" switch, and that this
wasn't Apple's fault but rather a bug common to all GNU tar 1.14.x
versions (up to x=91 IIRC). Given the lack of prior complaints
and the likelihood that 1.14.x is still in use elsewhere,
we decided to revert to the old coding for 8.4.

regards, tom lane