Andy,
thanks for your reply.

>Are you doing "Restore by directory tree" or
>"Restore by file specification" from the GUI?
>Or are you using "Restore subdirectory branch"
>or the command line interface?
I used the CL interface together with the command:
restore -subdir=yes d:\data\dirtorestore\*.*
and also tried
restore -subdir=yes d:\data\dirtorestore

I tried to restore to another node, to another directory, to another
directory with totally open security (everyone fullcontrol, just to get
sure it's not a simple security problem and ADSM is not allowed to
change dir security).

>>   or when you restore to another machine
>>   that is a member of the same domain but has
>>   different local groups (e.g.
>>   server\administrators is different from
>>   machine to machine).
>
>I'm not too sure about this specific scenario. I
>did try to restore to a different machine, with
>not problems.

In one case I got back the security when rostoring directly to the
machinge where the files originated. Restoring to any other server and
restoring through a workstation with mounted $-Share both lead to
incorrect directory security.

>I did all my testing with client version 2.1.0.6.
That's the version we use, too. I'll try the new V3 client as soon as
possible.

There's one idea that comes to my mind, but I cannot verify this:
Is it possible, that an older PTF of the NT client did not backup the
directory persmissions correctly so that this is leading to the problems
we have. The server in question is one of our oldest and it had quite a
few updates of ADSM in the past.
Do you think it makes sense to rename the filespace to start with a new
fullbackup? I could try this, but when the idea comes true we need a
method to verify what is stored in the ADSM database.

Regards,
Michael
--
Michael H. Bartl
Michael H. Bartl
ADAC e.V. (Rechenzentrum, Produktionsplanung und Organisation)
Tel.: (089) 7676-4063, Fax: (089) 7676-8161
EMail: Michael.Bartl AT Zentrale.ADAC DOT de
>