You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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:
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.
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.
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".
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
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.
Activity
PCAssistSoftware commentedon Jul 24, 2026
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 commentedon Jul 24, 2026
The complete code with example folders is:
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 /ISit 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 /ISand run
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 commentedon Jul 24, 2026
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 commentedon Jul 24, 2026
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 commentedon Jul 24, 2026
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 commentedon Jul 24, 2026
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.