Disk offline

--- This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. ---

Well, assuming the disk is not really off line :-), it may be a permission problem, but then, `amcheck' would have reported it.

Another possible reason for this failure is a filesystem error, that causes DUMP to crash before it estimates the backup size; a `fsck' may help.

Yet another possibility is that the filesystem is so large that the backup program is incorrectly reporting the estimated size, for example, by printing a negative value that AMANDA will not accept as a valid estimate. If you are using DUMP, contact your vendor and request a patch for dump that fixes this bug. If you are using GNU tar, make sure it is release 1.12 or newer; 1.11.8 won't do! Even release 1.12 may require a patch to correctly report estimates and dump sizes, as well as to handle sparse files correctly and quickly instead of printing error messages like `Read error at byte 0, reading 512 bytes, in file ./var/log/lastlog: Bad file number' in sendsize.debug and being very slow. Check the patches directory of the Amanda distribution.

---

Check for the correct AMANDA-user on the problematic client (Is that client running with the correct user?)

Does that user exist on that machine?

If the DLE is a SMB-share, check for proper permissions by accessing the share via smbclient:

  smbclient //SMBserver/SMBshare -U SMBuser

Check if you have the dump-binary installed ;-)