Re: Amanda - unable to create temporary directory

Hi All,

I've been experiencing the same error messages with Amanda
2.5.2-20080523
running Solaris 10 125100-07 when I backup *any slice* with using a
non-root
user id.

A quick search on SunSolve threw up the following bug report :

Bug ID: 4961690
Synopsis: roll_log()/make_mp() misuses mktemp(), causing spurious failures of 
fsck, ufsdump
State: 5-Cause Known
Description: 
See comments.
    Date Modified: 2004-06-11 05:50:40 GMT+00:00

http://sunsolve.sun.com/search/document.do?assetkey=1-1-4961690-1

(Note : Above link will require a SunSolve account)

>>From what I can gather reading the Bug Report the issue lies with the
permissions that ufsdump is using when creating a temporary mount point
(probably for creating the file index).

The directories in question :

        /tmp/.rlg.*
        /var/tmp/.rlg.*
        /.rlg.*

are created with mode 000 and the *real* user id and not the
effective (root) uid. The 000 mode means that non-root users
cannot access the created directory which causes ufsdump to
try and create the directory under the next directory in it's
prefered list until it fails 

Maybe the issue that Benjamin is seeing is due to the failure of
ufsdump to create a temporary mount point when request a Level 2
dump. As ufsdump cannot mount the filesystem to create a list
of modified files to dump, maybe ufsdump 'fallbacks' to a simpler
Level 0 dump?? Just conjection of course...  

Regards,

Nick Smith

p.s. Are users seeing lots of .rlg.* directories created -
     I am only seeing this on my 2.5.2 test installation but
     not on my 2.5.0p2 production servers also running the
     same version and patch level of Solaris??

Benjamin Lewis wrote:

> Peter Kunst wrote:
> 
> > I have one Solaris9 client with the same issues here:
> >
> > ? Unable to create temporary directory in any of the directories
> listed
> > below:
> > ? /tmp/
> > ? /var/tmp/
> > ? /
> >
> > when using ufsdump. When switching this client (one DLE only) from
> ufsdump
> > to gtar, this message disappears.
> >
> > The strange thing about this client is, even if amstatus tells me
> it's a
> > level 1, it does a level 0 (~50GB every day). Regardless if using
> ufsdump
> > or gtar. And yes, this box is synced using ntp, living in the
> correct
> > century :o)
> >
> > ufsdump is suid root, /tmp, /var/tmp and / have the correct
> permissions.
> 
> I think these are symptoms of trying to use ufsdump on a sub-directory
> that is not a mountpoint. ufsdump can do that, but will only do level
> 0
> dumps and will complain about it. Here's a very recent example:
> 
> /-- xxx.xxx.xxx.xxx /var/log lev 2 STRANGE
> *** sendbackup: start [xxx.xxx.xxx.xxx:/var/log level 2]
> sendbackup: info BACKUP=/usr/sbin/ufsdump
> sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
> sendbackup: info end
> ? Unable to create temporary directory in any of the directories
> listed
> below:
> ? /tmp/
> ? /var/tmp/
> ? /
> ? Please correct this problem and rerun the program.
> | DUMP: Date of this level 0 dump: Mon May 28 12:19:34 2007
> | DUMP: Date of last level 0 dump: the epoch
> *** | DUMP: Dumping /dev/md/rdsk/d11 (xxx.xxx.xxx.xxx:/var) to
> standard output.
> | DUMP: Mapping (Pass I) [regular files]
> | DUMP: Mapping (Pass II) [directories]
> | DUMP: Writing 32 Kilobyte records
> | DUMP: Estimated 389356 blocks (190.12MB) on 0.00 tapes.
> | DUMP: Dumping (Pass III) [directories]
> | DUMP: Dumping (Pass IV) [regular files]
> | DUMP: 389310 blocks (190.09MB) on 1 volume at 5749 KB/sec
> | DUMP: DUMP IS DONE
> sendbackup: size 194655
> sendbackup: end
> \--------
> 
> I prefixed the critical lines with "***". Notice how the message from
> ufsdump says that it's dumping /var at level 0 but Amanda asked for
> /var/log at level 2.
> 
> % df /var/log | awk '{print $1}'
> /var
> 
> -Ben
> 
> --
> Benjamin Lewis, CISSP <bhlewis@...>
> Security Analyst, Identity and Access Management
> IT Networks & Security
> Purdue University
>