Hi Ivan,
> xfsdump assumes /sbin is in root's path. If it isn't, it probably should
> be. If it is, then be sure that xfsdq is there.
i think that the dump program is executed by the amanda user that in any
case has /sbin in the path (just as root). I suppose is a problem
inherited from amanda autoconf.
> Hm, this is a bit odd. One might expect these failures if xfsdump were
> running on a busy filesystem, where a file may be deleted between the time
> that xfsdump finds out about it, and the time it decides to finally dump
> it to tape.
>
> However, I assume that the files in question are not subject to regular
> deletion and creation, so ... hmmm.
Filesystems are dumped early in the morning, when activity is very poor.
On the other hand, that's the second message i get about the same three
files, so it's very unlikely that this is the case.
>
> Can you try the following commands:
>
> . stat <filename>
> . ls -li <directory>
> (confirm that regular stat will work on files)
>
> . df -klT
> (is /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern on the same
> filesystem as /home)
>
> . cat <filename>
> (is the file readable)
>
> . xfs_check
> . xfs_repair
> (chech for inconsistencies within the filesystem)
>
Yes files are on the same fs....
I've tried all commands but xfs_repair and stuff _seems_ in good shape.
Hope this helps,
-m
|