FAQ

BUG #4883: tar xf fails on NFS4 mounts

Alfred Monticello
Jun 25, 2009 at 9:04 pm
The following bug has been logged online:

Bug reference: 4883
Logged by: Alfred Monticello
Email address: ajmcello78@gmail.com
PostgreSQL version: All
Operating system: Linux
Description: tar xf fails on NFS4 mounts
Details:

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 UID
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.
reply

Search Discussions

14 responses

  • Peter Eisentraut at Jun 25, 2009 at 9:29 pm

    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 UID
    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?
  • Tom Lane at Jun 25, 2009 at 10:20 pm

    Peter Eisentraut writes:
    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
  • Ajmcello at Jun 26, 2009 at 12:32 am

    On Thu, Jun 25, 2009 at 2:29 PM, Peter Eisentraut 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 UID
    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
    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
    #
  • Tom Lane at Jun 26, 2009 at 12:44 am

    ajmcello writes:
    # 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
    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
  • Greg Stark at Jun 26, 2009 at 1:20 am

    On Fri, Jun 26, 2009 at 1:44 AM, Tom Lanewrote:
    Maybe putting "o" into the options in doc/Makefile is a good
    idea.
    I wonder why we have tarballs inside of tarballs. Why not just have
    the files directly in a subdirectory of the install tarball already?
    I'm wondering why we've not had complaints before, though.
    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.
  • Tom Lane at Jun 26, 2009 at 1:22 am

    Greg Stark writes:
    On Fri, Jun 26, 2009 at 1:44 AM, Tom Lanewrote:
    Maybe putting "o" into the options in doc/Makefile is a good
    idea.
    I wonder why we have tarballs inside of tarballs.
    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
  • Ajmcello at Jun 26, 2009 at 1:21 am

    On Thu, Jun 25, 2009 at 5:44 PM, Tom Lane wrote:

    ajmcello <ajmcello78@gmail.com> writes:
    # 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
    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


    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.
  • Tom Lane at Jun 26, 2009 at 1:28 am

    ajmcello writes:
    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
  • Bruce Momjian at Jul 1, 2009 at 11:16 pm

    Tom Lane wrote:
    ajmcello <ajmcello78@gmail.com> writes:
    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.
    My old BSD has:

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

    --
    Bruce Momjian <bruce@momjian.us> http://momjian.us
    EnterpriseDB http://enterprisedb.com

    + If your life is a hard drive, Christ can be your backup. +
  • Tom Lane at Jul 1, 2009 at 11:21 pm

    Bruce Momjian writes:
    Tom Lane wrote:
    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.
    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
  • John R Pierce at Jul 1, 2009 at 11:46 pm

    ajmcello wrote:
    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.

    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.
  • Peter Eisentraut at Jul 2, 2009 at 6:57 am

    On Thursday 02 July 2009 02:45:24 John R Pierce wrote:
    ajmcello wrote:
    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.
    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.
  • Peter Eisentraut at Jul 2, 2009 at 6:59 am

    On Thursday 02 July 2009 09:56:35 Peter Eisentraut wrote:
    On Thursday 02 July 2009 02:45:24 John R Pierce wrote:
    ajmcello wrote:
    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.
    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.
  • Tom Lane at Jul 2, 2009 at 1:52 pm

    Peter Eisentraut writes:
    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

Related Discussions