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
>
> [EMAIL PROTECTED] 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).
>
> [EMAIL PROTECTED] 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
