On Sun, Sep 20, 2009 at 11:13, Geert Uytterhoeven <geert AT linux-m68k DOT org> 
wrote:
> On Mon, 14 Apr 2008, Chris Hoogendyk 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.
>
> I'm seeing a similar issue on a machine I just installed (Ubuntu 9.04/amd64,
> Amanda 1:2.5.2p1-4):
>
> | Amanda Backup Client Hosts Check
> | --------------------------------
> | ERROR: hostname: [Can't open disk /home/username]
> | ERROR: hostname: [No include for /home/username/subdir1]
> | ERROR: hostname: [could not access /home/username/subdir2 
> (/home/username/subdir2/REST): Permission denied]
> | ERROR: hostname: [Can't open disk /home/username/subdir2]
> | ERROR: hostname: [No include for /home/username/subdir2/subdir3]
> | ERROR: hostname: [could not access /home/username/subdir2 
> (/home/username/subdir2/subdir3): Permission denied]
> | ...
>
> But unlike in Chris' case, amdump couldn't back it up neither.
> Worse, it didn't report any failure, but created an empty tar archive instead:
>
> | HOSTNAME   DISK                 L   ORIG-kB    OUT-kB   COMP%  MMM:SS KB/s  
> MMM:SS    KB/s
> | --------------------------------- 
> ------------------------------------------- ---------------
> | hostname   /home/username/subdir1   0        10        32     --     0:00 
> 112.2    0:00   124.8

[...]

> The protection mask of /home/username/ is 2770. As the backup user is not a
> member of the right group, it cannot access the directory.
>
> Adding the backup user to this group fixes at least the amcheck issue (will
> see what happens with the dump next night), but this doesn't sound like The
> Right Thing to do to me...

Amdump also succeeded. But we can't to be expected to add the backup
user to _all_ groups, right?

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert AT linux-m68k 
DOT org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds