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