Dustin J. Mitchell wrote:
That error is coming from client-src/sendbackup.c:
821 access_result = access(device, amode);
822 access_type = "access";
823
824 if(access_result == -1) {
825 err = vstralloc("could not ", access_type, " ", qdevice,
826 " (", qdisk, "): ", strerror(errno), NULL);
827 }
where 'amode' is R_OK. You can simulate this with:
perl -MPOSIX -e 'print "yes\n" if POSIX::access("/", &POSIX::R_OK)'
Dustin
OK. But it's how we get to that code that seems to be the issue.
Yoshihiro Ishikawa wrote:
Hi Chris,
Can the below URL help you?
http://wiki.zmanda.com/index.php/Why_does_amcheck_fail_while_amdump_succeeds%3F
Yoshihiro
On Tue, Apr 15, 2008 at 7:14 AM, Chris Hoogendyk
<hoogendyk AT bio.umass DOT edu> wrote:
Well, I have to confess I'm puzzled by this one.
I added a couple of partitions to the disklist on my backup server,
expecting it to be a totally routine thing. However, I got "permission
denied" from amcheck when it tried to access these partitions (on another
server). I have scads of partitions on that server already getting backed
up. What's more, amdump was perfectly successful in backing these up. But,
amcheck keeps complaining. This has been going on for about 2 weeks.
I've checked permissions, and even umounted the partitions and checked the
underlying permissions of the mount point. I can't see that there is
anything unique about them compared to other partitions. I have permissions
all over the map, with different faculty and labs having ownership and
varying requirements for access and security. There are at least a couple of
others where root is neither owner nor a member of the group owner and other
permissions are 0. The underlying mount points are typically root:other with
755.
So, what, exactly is it that amcheck is doing that makes it different from
amdump and might make it complain in some way?
I've put the contents of the email message from amcheck and the debug file
from the client server at the end of this message.
The only "clue" I have is probably just a red herring. My boss had been
browsing through, tightening up some security stuff and changed the root
umask to 077 a few weeks back. That may have been before he added this
drive. But, if that had changed anything, I should be able to see it in the
permissions now. I don't. And, amdump doesn't seem to either.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
---------------------------
|email message from amcheck|
---------------------------
<with some headers removed>
Return-Path: <amanda AT mormyrid.bio.mor DOT nsm>
Received: from mormyrid.bio.mor.nsm (mormyrid.bio.mor.nsm [172.30.52.128])
by marlin.bio.umass.edu (8.14.2/8.14.2) with ESMTP id
m3EJ2nJO000578;
Mon, 14 Apr 2008 15:02:49 -0400 (EDT)
Date: Mon, 14 Apr 2008 15:02:49 -0400 (EDT)
From: Amanda Backup User <amanda AT mormyrid.bio.mor DOT nsm>
Message-Id: <200804141902.m3EJ2nNg020387 AT mormyrid.bio.mor DOT nsm>
Subject: UMassBiology AMANDA PROBLEM: FIX BEFORE RUN, IF POSSIBLE
X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.0
(marlin.bio.umass.edu [172.30.55.19]); Mon, 14 Apr 2008 15:02:49 -0400 (EDT)
X-Scanned-By: MIMEDefang 2.54 on 172.30.55.19
Amanda Tape Server Host Check
-----------------------------
Holding disk /var/spool/amanda/disk2: 122227093 KB disk space available,
using 111741333 KB
Holding disk /var/spool/amanda/disk1: 170167149 KB disk space available,
using 159681389 KB
slot 13: read label `bio-daily-009', date `20080228004501'
NOTE: skipping tape-writable test
Tape bio-daily-009 label ok
Server check took 168.519 seconds
Amanda Backup Client Hosts Check
--------------------------------
ERROR: marlin.bio.mor.nsm: [could not access /export/langford/other
(/export/langford/other): Permission denied]
ERROR: marlin.bio.mor.nsm: [could not access /export/langford/lab
(/export/langford/lab): Permission denied]
Client check: 4 hosts checked in 7.950 seconds, 2 problems found
(brought to you by Amanda 2.5.1p3)
<this is on Solaris 9 on an E250 - sun4u platform - both servers>
---------------------------------------
|contents of debug file on client server|
---------------------------------------
marlin:/:root# more /tmp/amanda/client/daily/selfcheck.20080414150002.debug
selfcheck: debug 1 pid 197 ruid 555 euid 555: start at Mon Apr 14 15:00:02
2008
selfcheck: version 2.5.1p3
Reading conf file "/usr/local/etc/amanda/amanda-client.conf".
Could not open conf file "/usr/local/etc/amanda/daily/amanda-client.conf":
No such file or directory
selfcheck: debug 1 pid 197 ruid 555 euid 555: rename at Mon Apr 14 15:00:02
2008
selfcheck: time 0.203: checking disk /export/pboff
selfcheck: time 0.284: device /dev/rdsk/c2t2d0s7
selfcheck: time 0.284: disk /export/pboff OK
selfcheck: time 0.284: amdevice /export/pboff OK
selfcheck: time 0.284: device /dev/rdsk/c2t2d0s7 OK
<snip>
selfcheck: time 0.393: checking disk /export/langford/other
selfcheck: time 0.441: device /export/langford/other
selfcheck: time 0.441: could not access /export/langford/other
(/export/langford/other): Permission denied
selfcheck: time 0.442: checking disk /export/langford/lab
selfcheck: time 0.487: device /export/langford/lab
selfcheck: time 0.487: could not access /export/langford/lab
(/export/langford/lab): Permission denied
selfcheck: time 0.488: checking disk /export/herbarium
selfcheck: time 0.502: device /dev/rdsk/c4t6d0s6
selfcheck: time 0.502: disk /export/herbarium OK
selfcheck: time 0.502: amdevice /export/herbarium OK
selfcheck: time 0.502: device /dev/rdsk/c4t6d0s6 OK
<snip>
OK. So, ...
I get these errors in the debug logs for amandad and selfcheck on the
client when I run amcheck off cron on the backup server in the mid
afternoon. The error is returned in the amcheck email, which I would not
receive if there were no errors.
I get these errors in the debug logs for sendsize when I run amdump off
cron on the backup server during the night. However, the dump works just
fine and the errors are not reported back in the email summary that
amdump sends.
The error does not show up in any debug files on the amanda server.
Since the dump works just fine, and runs off an suid wrapper (there are
/usr/local/libexec/runtar and rundump both), my gutt reaction is that
these are spurious errors and should not be reported by amcheck, since,
after all, amcheck is supposed to be telling you whether your dumps are
going to work. However, that leaves open the question of whether there
is something being missed by the planner because of the failure of
sendsize on the client when amdump is running. Perhaps that needs
changing so that it appropriately uses suid as well.
What I found finally was that while I do have other partitions being
backed up that don't have read permission outside their research group,
the parent directory of those partitions does, whereas the langford
partitions are nested one level deeper and the parent directory does not
have read permission. My personal preference is not to proliferate
permissions. I use amanda:amanda for the backup user. That user has no
specific permissions outside of its own files and directories. In other
words, I haven't specifically added it to any other groups. I prefer to
keep it that way.
For the moment, I have changed /export/langford to 755. I'll see this
afternoon, but that should solve the immediate problem with amcheck.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
|
