>oh, another tidbit of info. ...
Aha! The truth finally comes leaking out ... :-)
>Like I said, my mount point on that slave
>machine is /export, but I've got /export/data in my disklist file.
Short answer -- don't do that. Only do complete file systems with
ufsdump.
>Under that directory exists ftp and mail. On all the tapes that I
>went through for the past 7 weeks, every file under /export/data/ftp
>was intact, subdirectories and all. Why did it single out
>/export/data/mail/folders to deny? ...
It's a permissions thing.
Many dump programs will flat out refuse to do anything other than an
entire file system (that's the only thing they are designed to do).
Others will, as a courtesy, fire up some other program for you, probably
tar, or go into a variant of their normal processing. Here's what the
ufsdump man page says:
Alternatively, files_to_dump can identify
individual files or directories. All files
or directories are dumped, which is
equivalent to a level 0 dump; however,
/etc/dumpdates is not updated, even with the
u option specified. ...
So this is probably not doing what you want to do since it is not able
to do incrementals.
I think what bit you was the Amanda is not running as root. Normally,
it does not have to do so with a ufsdump because access can be controlled
via the raw disk device entry. But when Amanda runs a program that
reads the real file system (e.g. tar) it does so under a setuid-root
wrapper program to get around the permissions issue.
But it didn't know to do that in this case, so ufsdump was run as a normal
user, and that couldn't get into the directory you had trouble with.
I'm guessing the other directories were open enough to get through.
At least that's my best theory.
>-drew
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
