I'm sorry to sound pedantic here, but I think this is a case where we can only fix it by looking at specific problems. Amcheck is pretty careful to give as many error messages as possible in each run, rather than simply bailing out after the first, so if there's a case where this does not happen, it's a bug that's been missed for some time now.
On Mon, Sep 13, 2010 at 12:59 AM, Paul Bijnens <paul.bijn...@xplanation.com> wrote: > When then later trying to run as the amandabackup user you're > in trouble, as e.g. even the debug folder is not even writable by amanda > and you have no immediate clue about what is going wrong. I *think* we've fixed the problem with the debug directories now - every script checks that it's running as the appropriate user, and once the debug directories are created, they are chown'd to the dumpuser. On Mon, Sep 13, 2010 at 7:26 AM, Lisa Seelye <l...@thedoh.com> wrote: > When I first configured Amanda on my Gentoo servers some time ago I ran > into the problem where several installed files were not correctly owned or > had improper permissions. I would correct one, perhaps in > /var/spool/amanda and re-run amcheck and another fault would come up. If /var/spool/amanda is a holdingdisk, then there shouldn't be any follow-on permissions problem for it - it either has the right permissions or not, right? I'm still nervous about automatically fixing permissions (even though amcheck runs setuid root).. Is there any chance you or Stefan could do a fresh install from the updated ebuilds (I believe robbat has just put 3.1.2 in ~x86) and see what problems you come to? They'll make good gentoo bugs for the ebuild, but also a good concrete symptom that we can look at fixing in Amanda. Dustin -- Open Source Storage Engineer http://www.zmanda.com
