Robocopy Command as Admin for copy:DAS

[LordPinhead]

I have a strange problem with working with the Library for some time. I'm running a .net 6 ASP Service with a Rest Interface, to give users the ability to create folders from a template.

The ACLs from the source folder should be copied, so I use the flag "copy:DAS", which need Admin rights. The service runs as a local admin, so it should copy the rights.
But when it runs "robocopy copy:DAS more flags d:\template d:\target", only the subfolders get the ACL's from the template and the main folder stays with inherited properties.

Does the library call Robocopy in a way, it drops it privileges?

[PCAssistSoftware]

If you use RoboCopy command line using the EXACT same source, destination, flags and switches, does it work correctly?

IF yes then please provide full command line so I can try and replicate here

[LordPinhead]

The complete code with example folders is:

RoboCommand = RoboCommandParser.Parse($"robocopy D:\files\_Template D:\files\3019293 /E /copy:DAS /NP /V /IS");        

RoboCommand.CopyOptions.Depth = 100000;

RoboCommand.RetryOptions.RetryCount = 1;

RoboCommand.RetryOptions.RetryWaitTime = 2;

RoboCommand.OnError += ErrorHandler;

RoboCommand.OnCommandError += CommandErrorHandler;

RoboCopyResults results = await RoboCommand.StartAsync();

An example folder structure is:
D:\files_Template\ -> has special ACL's that should be copied (the S in copy:), different from it's parent folder, but they are ignored
D:\files_Template\customer -> has also different ACL`s, but this one is getting it's ACL's right

D:\files\3019293 should now have the ACLS from _Template, but it is inheriting the ACL`s from d:\files, which is wrong.

When you run the Robocopy command as Admin in a shell like this:

robocopy D:\files\_Template D:\files\3019293_test1 /E /copy:DAS /NP /V /IS

it works, but when you run it as a normal user, like this:

robocopy D:\files\_Template D:\files\3019293_test2 /E /copy:DAS /NP /V /IS

and run

cacls D:\files\3019293_test1
cacls D:\files\3019293_test2
cacls D:\files\_Template

you will see different results.

This, after some research, happens when the account has no higher administrative rights or the process is not running like it should. I found on Stackoverflow a thread about it: https://stackoverflow.com/questions/2532769/how-to-start-a-process-as-administrator-mode-in-c-sharp

When you remove the S of the copy attribute, the subfolders have completely wrong ACL's.

That's how far I am right now. My guess is, the RoboCommand.cs the Process Startinfo details in GetRoboCopyTask() are to blame here. I saw, I could run the RoboCommand with a domain and credentials, but not the parser and I don't want to hardcode the account infos into my service.

[PCAssistSoftware]

make sure the app you are using the code in is set to run elevated with admin permissions. I use the library in VB.NET and C# WinForm / WPF apps and the app.manifest has to be set to run elevated e.g. as admin for it to work.

[LordPinhead]

I've added a manifest to it to run with elevated rights, checked in a hexeditor if it's in the exe and dll, it is, in the "Properties->Compatability" window of the EXE file, I've checked "Run as administrator".

[PCAssistSoftware]

Using a standard winforms .NET app running as admin it works perfectly fine.

So you mentioned ASP.NET, so I assume user accessing it via a website / webpage and running it? Does the user themselves have admin rights?

Is the app being published with admin rights? I believe for ASP.NET you would publish it as a service e.g. builder.Host.UseWindowsService();
And then configure the service to run using an account which has administrator rights to the location where the source / destination folders are. If hosting with IIS then the application probably runs under the Application Pool Identity, so to give it administrator rights you would need to a) Change the Application Pool identity to an administrator account, or b) Grant only the specific permissions it requires (preferred). N.B. Running an IIS application pool as Administrator is generally discouraged.

This is definitely a permissions issue, as you already determined when using RoboCopy via CLI, for several switches, specifically those relating to security, elevated / admin rights are required, same goes for RoboSharp which is just a wrapper for RoboCopy CLI

[LordPinhead]

I will do some more tests when I'm back to work. At least the subfolders get now the right permissions.
I know it's just a wrapper, but I remember I also had to add something to a Process.Start.Info to an App many years ago.

It's running as it's own application, not IIS, and it's company internal only. Parameters are checked with RegEx, so you can not send anything besides Numbers, a hyphen and 10 chars. And because of the ACL's things, it has to run as Admin. Different branches have access to certain subfolders and denied on others. So the easiest way is, to create your template with ACLs and mirror them, that's the tools purpose.