Why does amcheck fail while amdump succeeds?: Difference between revisions
Paul.bijnens (talk | contribs) m (up link) |
(man links) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Troubleshooting Header}} | |||
=Problem= | |||
Errors occur with {{man|8|amcheck}}, but {{man|8|amdump}} runs without errors. | |||
=Explanation= | |||
If you use GNUtar as backup program, Amanda uses a wrapper called runtar which should be set suid root: | If you use GNUtar as backup program, Amanda uses a wrapper called runtar which should be set suid root: | ||
| Line 4: | Line 10: | ||
-rwsr-x--- 1 root disk 13K Oct 28 11:59 /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, | 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. | ||
which means that you may get errors with | |||
=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. | 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. | 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. | 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. | 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.