On Mon, 4 Oct 2004 at 11:31am, Brian Cuttler wrote

> Environment: amanda 2.4.4p2 client being installed on 2.4.9-31

Whatever version of RH that is, the kernel is rather out of data (which 
means probably a lot of other packages as well).  I'd upgrade it ASAP.

> Server (on Solaris) has been running for years, client is new.
> 
> Symptom:
>  Amanda Backup Client Hosts Check
> --------------------------------
> ERROR: mssarc: [could not access /dev/sda12 (/iarc/vol): Permission denied]
> Client check: 10 hosts checked in 5.252 seconds, 1 problem found
> 
> [root@mssarc amanda]# more /etc/xinetd.d/amanda
> service amanda
> {
>         disable         = no
>         socket_type     = dgram
>         protocol        = udp
>         wait            = yes
>         user            = amanda
>         group           = disk 
>         server          = /usr/local/libexec/amandad
> }

> Amanda user is local to linux system. Tried amanda in various groups,
> ie group 0, disk (3), sys (6) to no avail. /usr/local/libexec/ binaries
> seem to be installed correct, suid bit set on rundump (root:sys).
> 
> [root@mssarc amanda]# ls -las /dev/sda12
>    0 brw-rw----    1 root     disk       8,  12 Aug 30  2001 /dev/sda12
> 
> I'm not seeing where the problem lies, is there something special about
> linux installs, something else special about linux installs ?

What is the primary group membership of the amanda user, and what are the 
secondaries?  I'm guessing that amanda is in the sys group primarily (that 
would match your ownership on /usr/local/libexec/rundump).  If that's the 
case, I think the "group" option in your xinetd entry needs to match that.  
Then add "groups = yes" to pull in the secondary memberships.

Myself, I always make amanda's primary group disk for just this reason.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University