On Tue, Jul 23, 2002 at 12:10:25PM -0400, Dave Belfer-Shevett wrote: > ERROR: tub: [could not access /dev/rdsk/c0t0d0s1 (/dev/dsk/c0t0d0s1): > Permission denied] > ERROR: tub: [can not read/write /etc/dumpdates: Permission denied]
> Question: appartently amanda is simply trying to run 'dump', but can't > because it doesn't have root access. Well duh, its logging in as > 'operator'. Is there some setuid stuff i'm missing somewhere, so that the > amanda app can actually run dump and updated /etc/dumpdates? No. The conventional way is to give amanda group read on /dev/rdsk/c0t0d0s1, and group write on /etc/dumpdates, like: % groups amanda amanda : sys % ls -lLg /dev/rdsk/c0t0d0s0 /etc/dumpdates crw-r----- 1 root sys 32, 0 Aug 28 2000 /dev/rdsk/c0t0d0s0 -rw-rw-r-- 1 root sys 1440 Jul 23 03:42 /etc/dumpdates > amcheck-server: slot 1: date 20020723 label qbn-backup01 (active tape) > Second - the message is saying there's a labelled tape in the drive > (qbn-backup01) which I created with 'amlabel'. But it seems to think > that's not a writable tape, its expecting a new one. Can I tell amanda > "no, that's your tape. Go toss data on it!" or am I misunderstanding how > tape labelling / allocation work? Amanda believes you wrote to that tape, on July 23, 2002. Are you sure you didn't? If you're still just playing and don't care about the data currently on qbn-backup01, you can 'amrmtape tub qbn-backup01' and start over, or 'amlabel -f tub qbn-backup02' it and have amanda pretend it's a new tape. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA (fax)1.503.466.9472
