# su -c amanda id
uid=33(amanda) gid=6(disk) groups=6(disk)
# ls -l /dev/sda2
brw-rw----    1 root     disk       8,   2 Aug 24  2000 /dev/sda2
# ls -ln /dev/sda2
brw-rw----    1 0        6          8,   2 Aug 24  2000 /dev/sda2
# grep disk /etc/group
disk:x:6:root,rwk,amanda
# grep amanda /etc/passwd
amanda:x:33:6:Amanda user:/var/lib/amanda:/bin/bash

Also, I can run dump manually (on the client) as the amanda user and it
runs with no problem:

# sys su amanda -c '/sbin/dump 0Ssf 1048576 - /dev/sda2'
9334784

What do you make of it?

> The only *problem* is that dump can't open /dev/sda2 for reading.  Try:
> 
>       su -c amanda id
>
> If that doesn't tell you that amanda is in whatever group owns the disk,
> that's your problem, and you need to verify that the (numeric) group id
> used in /etc/passwd is the group that owns the disk.


> [EMAIL PROTECTED] wrote:
> > 
> > I installed advfs.diff on the client (wookie) and reran the test dump
> > but the sendsize*dump file still says:
> > 
> > ******************************************************************************
> > sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002
> > /usr/local/libexec/sendsize: version 2.4.2p2
> > calculating for amname '/boot', dirname '/boot'
> > sendsize: getting size via dump for /boot level 0
> > sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2"
> > running /usr/local/libexec/killpgrp
> >   DUMP: Warning: unable to translate LABEL=/
> >   DUMP: Warning: unable to translate LABEL=/boot
> > /dev/sda2: Permission denied while opening filesystem
> > .....
> > (no size line match in above dump output)
> > .....
> > asking killpgrp to terminate
> > sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002
> > ******************************************************************************
> 
> The only *problem* is that dump can't open /dev/sda2 for reading.  Try:
> 
>       su -c amanda id
> 
> If that doesn't tell you that amanda is in whatever group owns the disk,
> that's your problem, and you need to verify that the (numeric) group id
> used in /etc/passwd is the group that owns the disk.
> 
>       Marty
> --
> Marty Shannon, RHCE, Independent Computing Consultant
> mailto:[EMAIL PROTECTED]
> 

Reply via email to