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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Todd Kover Sent: Thursday, February 24, 2005 12:37 PM To: [email protected] 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
