Thanks for the help,

At this point it seems that the best way for us is to switch from ufsdump to
gnutar.
But before doing so - what will happen with the backups that I did so far?
(I backed our data on a tape drive).
Does ufsdump and gnutar stores the data the same way? (Does ufsdump level
0,1... is identical to gnutar level 0,1...) Or does it store the data on a
different format?
Does Gnutar is going to store the data twice or is it going to overwrite the
data that was stored by ufsdump?

Any other concerns that I should keep in mind before switching from ufsdump
to gnutar?

Thanks,
gil

-----Original Message-----
From: owner-amanda-users AT amanda DOT org
[mailto:owner-amanda-users AT amanda DOT org]On Behalf Of Todd Kover
Sent: Thursday, February 24, 2005 12:37 PM
To: amanda-users AT amanda DOT org
Subject: Re: Amanda - unable to create temporary directory



Jon LaBadie said:

 > On my system /usr/sbin/ufsdump is a symbolic link to
/usr/lib/fs/ufs/ufsdump.
 > The latter program is root-owned, set-uid.  Perhaps yours has been
altered.
 >
 > $ ls -l /usr/lib/fs/ufs/ufsdump
 > -r-sr-xr-x  1 root  bin   83820 Apr 12  2004 /usr/lib/fs/ufs/ufsdump

We actually strip the setuid bit on ufsdump and this seems to work in
most circumstances.

We had this problem every night on one specific solaris 9 system, and
no other sol9 or sol8 systems (and our amanda client is installed via a
package, so it's the same across all machines).  The solaris boxes are
also installed from the same jumpstart images, so they should all behave
the same.

This error comes from ufsdump, and near as I've been able to tell,
ufsdump is creating a directory named something like '.rlg.zyaaGR in
each of /tmp and /var/tmp (and failing to be able to in / since it's not
running as root, the jibberish after .rlg. changes with each run).  This
directory is called with mode 000 and then ufsdump attempts to create a
file in it, which fails and generates that error message.

I wasn't able to get ufsdump to behave better (nor did I look for
a patch or try to reset ufsdump to being setuid again) but on that
specific system we had amanda incorrectly configured to backup something
other than the mountpoint of the filesystem, but something inside the
filesystem (that is, instead of /export/home it was /export/home/foo/bar
where the filesystem was mounted on /export/home).

Switching this to the mountpoint made the error go away.  There may be
some limitations in ufsdump that cause you only be able to use ufsdump
this way if you're root (though sounsd lke a bug).

If you're doing this, and doing it on purpose, I'd suggest using gnutar
instead of dump since incremental dumps don't work right except on
filesystem boundaries.

If you're not doing this and actually backing up a mountpoint, then
maybe the above info will help track it down. (perhaps the setuid bit,
as Jon suggests).

-Todd