Sun-Managers,
*** Here's the original posting ***
I've come across an interesting (?) NFS problem that someone might be
able to help with. We have the ever-present multi-vendor network with
Sun's, HP's, SGI's, IBM's, and DEC's. One of my users wishes to read a
Sun tar tape. He puts the tape into a tape drive on the Sun called tapehost
and rlogins over there. His home directory is on an HP, but the automounter
takes care of that for him.
He types tar xvf /dev/rst8 to extract the files. On the tape is a nested
directory structure, which is, of course, owned by the user of the original
files. The first directory comes off of the tape, but its owner is set
to the "original" owner. This results in the rest of the tar failing, since
my user doesn't have write access into that directory. Note that the user
is *not* root (this causes problems of its own I won't go into and I'm sure
are obvious to readers of this group).
Some more info: the tar *does* work when the directory that the files
are being written to comes from a Sun, RS/6000, or DS3100 NFS server.
It does *not* work when it's from an HP (HP-UX7.x) or SGI machine.
Yep, rsh tapehost dd if=/dev/rst8 bs=20b | tar xvfb - 20
does work from the HP machine (no B option). However, I'm curious why the
tar command on the Sun machines tries to create files with the owner set
from the tape rather than the user running the program. Is this fixed,
by chance, with the Jumbo NFS patch I keep hearing about? Or is this (another!)
problem with HP's NFS (SGI's too, but there's is not quite as brain-dead).
*** End of the original posting ***
Several of you suggested using the "o" option to tar. However, I may not have
made it clear in my original posting that the tar is being done *on* a Sun
machine (where the tape drive is). While HP-UX will use the "o" option
during the read to explicitly tar the files off with the owner being the
user running the program, the Sun "o" option appears to *only* be used
for writing ... but, of course, customers have usually allready written
their tapes by time we get 'em. BTW, using the "m" option doesn't help except
to get rid of the error message: tar: can't set time on tmp: Not owner
One person was concerned about tar being setuid. This is not being done,
and it was rightfully pointed out that it should *not* be the case. I assume
readers of this group are aware of the *serious* security implications of that.
Several suggested setting umask to 000. While this does *not* help when the
tape directory protections are 755 (usually the case), it would help when
they are 775 (my umask is 022). BTW, setting the set-gid bit on the directory
did not make a difference in either case.
It was pointed out that GNU tar doesn't have this problem.
Finally, several of you correctly pointed out that this was due to a clash
between the BSD and SysV handling of chown. SysV machines (HP & SGI) allow
anyone to chown, BSD machines restrict this command to root. So the files
are tar'ed off, and somewhere in the NFS protocal (I could use some help here)
a chown is executed which succeeds (on the first directory!). Unfortunately,
when the first files under that directory are tar'ed off, the Sun machine
realizes that it does *not* have write permission in the directory, and
says no can do. I should (!) have realized this at the time of my post,
but my only excuse is that it was late.
So ... there is *no* graceful solution. However, one can execute the rsh
command as mentioned above, or, of course, simply tar off the files onto
a Sun directory (/tmp *depending* on its size and tape size), and then
copy them over. Copying them over is not trivial on the Sun side, because
one runs into the same problem (cp -r is *not* a good solution!).
My approach is to tar off the tape, then create a "tar-file", and
then (on the HP side) tar from that file. I.e.:
Sunhost> mkdir /tmp/unique ; cd /tmp/unique ; tar xf /dev/rst8
Sunhost> cd /tmp ; tar cf unique2 unique
HPhost> tar xf unique2 (may have to copy over, since if you are using tmpfs,
it doesn't mix too well with NFS).
BTW, tar also failed when the NFS directory was coming from an HP730
running HP-UX8.01. I understand that HP-UX8.x supports disk quotas, and
has changed the chown stuff (otherwise: "disk quota exceeded? - chown root *").
I suspect that when the *real* release of HP-UX comes out for the 700's,
this problem may go away. FYI: I also understand that IRIS4.0 supports
disk quotas, so I suspect a similiar fix.
At the risk of offending some of you, can I make one suggestion to
responders of posts (but by no means stop responding!). Pls specify if you
"think" somethings works rather "know" it does. For example, it was very
tersely pointed out "Use the 'o' option - see tar (1)", which does *not* work.
Now, after saying the above, can someone help me with an easy request that
I just don't have the TFM for. I am interested in presenting a paper at the
Sun User's Group Meeting in December (I've attended two of these - good time!).
Subject would be a case study of how a somewhat complex /usr/local
file-server approach is used in a multi-vendor environment to easily
allow local customization to occur and be maintained over the differing
platforms in a C++ software development shop (the concepts apply
more globably than just that, but this is a pretty intense one! :-)
This isn't leading edge-stuff, but rather application of software engineering
to support "real-world" work today.
Can someone pls point me in the right direction for who handles abstracts
in this area ... or (hopefully not) tell me it's too late.
Thanx again Sun-Managers for the interesting responses to a real-world problem.
Alek Komarnitsky 303-449-0649
Software Tools Manager, Spatial Technology, Inc. 2425 55th Street, Bldg A
alek@spatial.com Boulder, CO 80301-5704
Here is the list of responders - mucho thanx!
Joerg.Lehners@arbi.Informatik.Uni-Oldenburg.DE
Joerg Lehners <Joerg.Lehners@arbi.informatik.uni-oldenburg.de>
"John R Ruckstuhl Jr" <ruck@alpha.ee.ufl.edu>
hans@ph.tn.tudelft.nl (Hans Buurman)
Chip Christian <chip@allegra.att.com>
jfy@cis.ksu.edu (Joseph F. Young)
Sheryl Coppenger <sheryl@gwusun.gwu.edu>
Mike Raffety <miker@sbcoc.com>
deltam!flyer!mark@uunet.UU.NET (mark galbraith)
tim@ben.dciem.dnd.ca (Tim Pointing)
mikulska@ece.UCSD.EDU (Margaret Mikulska)
ico.isc.com!suntalk!jtsv16.jts.com!gerry@Canada.Sun.COM (G. Roderick Singleton)
Calum Mackay <calum.mackay@mrc-apu.cam.ac.uk>
cxh@franz.com (Chris Hylands)
pkn@cs.utexas.edu
Denis Laplante <laplante@ocgy.ubc.ca>
diekema@jdbbs.mi.org (Jon Diekema)
I misplaced the identity of: "[Sorry about that soap-box incident ;-]"
Ummm, someone feeling guily when as a kid they put extra weights into their
soap-box derby car! :-) (seriosely, I don't know what this is in regard too)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT