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
Relevant parts of the logs:
| selfcheck: time 0.110: Can't open disk /home/username
| selfcheck: time 0.110: No include for /home/username/subdir1
| selfcheck: time 0.110: checking disk /home/username/subdir1
| selfcheck: time 0.111: device /home/username
| selfcheck: time 0.111: disk /home/username/subdir1 OK
| sendsize[4939]: time 2.116: Can't open disk /home/username
| sendsize[4939]: time 2.116: No include for /home/username/subdir1
| sendsize[4939]: time 2.117: spawning /usr/lib/amanda/runtar in pipeline
| sendsize[4939]: time 2.117: argument list: runtar DailySet1 /bin/tar --create
--file /dev/null --directory /home/username --one-file-system
--listed-incremental
/var/lib/amanda/gnutar-lists/hostname_home_username_subdir1_0.new --sparse
--ignore-failed-read --totals --exclude-from
/tmp/amanda/sendsize._home_username_subdir1.20090920014504.exclude --files-from
/tmp/amanda/sendsize._home_username_subdir1.20090920014504.include
| sendsize[4939]: time 2.124: Total bytes written: 10240 (10KiB, 185MiB/s)
| sendbackup: debug 1 pid 4969 ruid 34 euid 34: rename at Sun Sep 20 01:47:23
2009 sendbackup req: <GNUTAR /home/username/subdir1 /home/username 0
1970:1:1:0:0:0 OPTIONS
|;auth=BSD;index;exclude-list=/etc/amanda/exclude.gtar;include-file=./subdir1;>
| parsed request as: program `GNUTAR'
| disk `/home/username/subdir1'
| device `/home/username'
| level 0
| since 1970:1:1:0:0:0
| options
`|;auth=BSD;index;exclude-list=/etc/amanda/exclude.gtar;include-file=./subdir1;'
| sendbackup: start: hostname:/home/username/subdir1 lev 0
| sendbackup-gnutar: time 0.025: doing level 0 dump as listed-incremental to
'/var/lib/amanda/gnutar-lists/hostname_home_username_subdir1_0.new'
| sendbackup-gnutar: time 0.029: doing level 0 dump from date: 1970-01-01
0:00:00 GMT
| sendbackup: time 0.039: Can't open disk /home/username
| sendbackup: time 0.039: No include for /home/username/subdir1
| sendbackup: time 0.039: spawning /usr/lib/amanda/runtar in pipeline
| sendbackup: time 0.039: argument list: runtar DailySet1 gtar --create --file
- --directory /home/username --one-file-system --listed-incremental
/var/lib/amanda/gnutar-lists/hostname_home_username_subdir1_0.new --sparse
--ignore-failed-read --totals --exclude-from
/tmp/amanda/sendbackup._home_username_subdir1.20090920014723.exclude
--files-from
/tmp/amanda/sendbackup._home_username_subdir1.20090920014723.include
| sendbackup: time 0.040: started index creator: "/bin/tar -tf - 2>/dev/null |
sed -e 's/^\.//'"
| sendbackup-gnutar: time 0.040: /usr/lib/amanda/runtar: pid 4974
| sendbackup: time 0.040: started backup
| sendbackup: time 0.076: 47: size(|): Total bytes written: 10240 (10KiB,
151MiB/s)
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...
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
|
