It was a quiet weekend -- Glad to see this list popping again. A set-up problem that I sent last week is still with me, i.e amcheck reports "permission denied" for the disks in disklist (client and server are the same). Since last posting, I've tried changing disklist to specify local disk access:
raleigh.cpt.afip.org /gilmore nocomp-root -1 local raleigh.cpt.afip.org /dev/dsk/dks0d4s3 nocomp-root -1 local I also tried recompile/reinstall (both as root) with FORCE_USERID=no set in config.site file. Neither trick fixed the problem, i.e: raleigh 37% amcheck -c config_orig Amanda Backup Client Hosts Check -------------------------------- ERROR: raleigh.cpt.afip.org: [could not access /dev/rdsk/dks0d4s3 (/dev/dsk/dks0d4s3): Permission denied] ERROR: raleigh.cpt.afip.org: [could not access /dev/rdsk/dks0d4s2 (/gilmore): Permission denied] Client check: 1 host checked in 20.043 seconds, 2 problems found (brought to you by Amanda 2.4.2p2) raleigh 38% I see no clear evidence that amandad is the problem -- there have been up to seven instances of it listed in a single ps -elf request, and there is no "server timeout" notice when I run both client and server amcheck. This still smells like an Irix suid problem, but I don't know how to get at it. The only suid-oriented tweak we've made to the OS was in fixing a well known security hole (-s bit set on file suid_exec) that shipped with previous versions of Irix. Current version (6.5) does not even have that file. Still hoping that someone can post the solution, or maybe point to info on how Amanda uses suid so I can track it down more easily. Thanks. R. Becker On Fri, 24 May 2002, Robert L. Becker wrote: > I checked the permissions at the level of the mount point and the block > device file. Indeed, the block device was more restricted (600) than the > mount point (755). So, as a test, I set permissions at both entries to 777 > and retried amcheck. No effect. The client check still flags an error: > > Amanda Backup Client Hosts Check > -------------------------------- > ERROR: raleigh: [could not access /dev/rdsk/dks0d4s3 (/whitmore): > Permission denied] > > > I wonder if this is a remote host (any client) access problem, though I've > tried to cover this in ~amanda/.amandahosts: > > raleigh 10% cat ~amanda/.amandahosts > raleigh.cpt.afip.org amanda > raleigh amanda > > I also wonder if current absence of an amandad process (according to ps > -elf) is a clue -- though I have made the recommended entries in > /etc/services and /etc/inetd.conf files and saw that as many as two > amandad processes showed in the ps listing when I stopped/restarted the > network after editing those files. Looking for suggestions still... > > R. Becker > > > On Fri, 24 May 2002, fil krohnengold wrote: > > > At Fri, 24 May 2002 14:44:04 EDT, [EMAIL PROTECTED] wrote... > > : Here's a permissions problem that I don't understand, reported by > > : amcheck. Client and server are the same host (raleigh): > > : > > [...] > > : Amanda Backup Client Hosts Check > > : -------------------------------- > > : ERROR: raleigh: [could not access /dev/rdsk/dks0d4s3 (/whitmore): > > : Permission denied] > > [...] > > : > > : Amanda is installed as user amanda in group sys. Far as I can tell, the > > : file systems should be ok for amanda to read. For example: > > : > > : raleigh 2% ls -l / | grep whit > > : drwxr-xr-x 3 root sys 24 May 15 08:02 whitmore > > > > Significant permissions are set on the raw disk device - under > > solaris it looks like this (excuse the long lines): > > > > blinky:~> df -k . > > Filesystem kbytes used avail capacity Mounted on > > /dev/dsk/c0t0d0s4 6705645 1676432 4962157 26% /local > > blinky:~> ls -l /dev/dsk/c0t0d0s4 > > lrwxrwxrwx 1 root root 46 Dec 30 16:41 /dev/dsk/c0t0d0s4 -> >../../devices/pci@1f,0/pci@1,1/ide@3/dad@0,0:e > > blinky:~> ls -l /devices/pci@1f,0/pci@1,1/ide@3/dad@0,0:e > > brw-rw---- 1 root sys 65, 4 Jan 9 19:03 >/devices/pci@1f,0/pci@1,1/ide@3/dad@0,0:e > > > > Check to see what the permissions are on /dev/rdsk/dks0d4s3, > > etc.. That may be your problem. > > > > -fil > > -- > > fil krohnengold > > systems administrator - IT > > american museum of natural history > > [EMAIL PROTECTED] > > > > Robert L. Becker, Jr. > Col, USAF, MC > Department of Cellular Pathology > Armed Forces Institute of Pathology > Washington, DC 20306-6000 > 301-319-0300 > > Robert L. Becker, Jr. Col, USAF, MC Department of Cellular Pathology Armed Forces Institute of Pathology Washington, DC 20306-6000 301-319-0300