Why does amcheck fail while amdump succeeds?: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
(man links)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
If you use GNUtar as backup-binary, [[amdump]] uses a wrapper called runtar which is set suid root at install-time:
{{Troubleshooting Header}}
=Problem=


  # ll /usr/local/libexec/runtar
Errors occur with {{man|8|amcheck}}, but {{man|8|amdump}} runs without errors.
  -rwsr-x---  1 root disk 13K Oct 28 11:59 /usr/local/libexec/runtar


[[amcheck]] does not use that wrapper, so it does not have root-permissions,  
=Explanation=
which means that you may get errors with amcheck while [[amdump]] runs through without problems.
If you use GNUtar as backup program, Amanda uses a wrapper called runtar which should be set suid root:
You can check for [[amcheck]] errors in /tmp/amanda/amcheck* logs on the client. There should
 
be "permission denied" error messages.
# ls -l /usr/local/libexec/runtar
-rwsr-x---  1 root disk 13K Oct 28 11:59 /usr/local/libexec/runtar
 
Nor amcheck (on the server) nor amandad (on the client) use that wrapper, so it does not have root permissions, which means that you may get errors with {{man|8|amcheck}} while {{man|8|amdump}} runs through without problems.
 
=Solution=
Check for errors in the debug file named '''amcheck.''datetime''.debug''' (server part check) in the [[AMANDA_DBGDIR]] directory on the Amanda server host, or in the files named '''amandad.''datetime''.debug''' (client part check) on each client host (including the server). There are many amandad debug files; look for the one with the string "SERVICE selfcheck" in it.
There should be "permission denied" errors in it.
 
Making the toplevel directories of the disklist entries readable by the [[dumpuser]] should remedy this. The parent directories, up to the root directory, need to be accessible by the dumpuser too.
 
When using local exclude lists on the client, they should be accessible and readable too. Alternatively, you can add the 'optional' keyword in the exclude list for that dumptype; this suppresses the error message.

Latest revision as of 23:24, 30 June 2008

This article is a part of the Troubleshooting collection.

Problem

Errors occur with amcheck(8), but amdump(8) runs without errors.

Explanation

If you use GNUtar as backup program, Amanda uses a wrapper called runtar which should be set suid root:

# ls -l /usr/local/libexec/runtar
-rwsr-x---  1 root disk 13K Oct 28 11:59 /usr/local/libexec/runtar

Nor amcheck (on the server) nor amandad (on the client) use that wrapper, so it does not have root permissions, which means that you may get errors with amcheck(8) while amdump(8) runs through without problems.

Solution

Check for errors in the debug file named amcheck.datetime.debug (server part check) in the AMANDA_DBGDIR directory on the Amanda server host, or in the files named amandad.datetime.debug (client part check) on each client host (including the server). There are many amandad debug files; look for the one with the string "SERVICE selfcheck" in it. There should be "permission denied" errors in it.

Making the toplevel directories of the disklist entries readable by the dumpuser should remedy this. The parent directories, up to the root directory, need to be accessible by the dumpuser too.

When using local exclude lists on the client, they should be accessible and readable too. Alternatively, you can add the 'optional' keyword in the exclude list for that dumptype; this suppresses the error message.