Permissions problem

Hram Admin 290

Hello,

Consider the following test:

On Server1 I create a test folder C:\TESTС with two subfolders - REPORTS and storage.
Share C:\TESTС using Advanced Sharing for the single local account (Task) - full controll.
Do NOT add Task account on the NTFS permissions tab:

as a result both subfolders - REPORTS and storage inherit permissions from C:\TESTC WITHOUT permissions for Task account.

I map the J: to the C:\TASKC under Task account (I can do it because share permission = FC) and try to copy some folder to C:\TASKC\storage (J:\storage) and write the log to C:\TASKC\REPORTS (J:\REPORTS)

Since the Task account does NOT have any write permissions to C:\TESTC (it's neither a member of the Administrators local group nor has been purposely applied write permission on the NTFS tab - it has only read permissions due to its membership in the Users group ) the copy operation should fail when

copying to J:\storage
writing the log to J:\REPORTS.

The result: copy operation fails with the Access Denied error as expected but the log is successfully created in the J:\REPORTS folder UNDER the local Task account (I enabled File Access audit and checked it) in the folder that does NOT HAVE WRITE PERMISSION for the Task account:

???!!!

Regards,
Michael

8 answers

Hram Admin 290 Reputation points

2025-11-13T08:53:36.3366667+00:00

Hello MotoX80,

This -

"test" | out-file J:\Storage\Storage-Test.txt

"test" | out-file J:\Reports\Reports-Test.txt

copy-item J:\Storage\Storage-Test.txt J:\Reports copy-item J:\Reports\Reports-Test.txt J:\Storage

... -works perfect:

But the script still does not:

I also tried to copy the folder D:\TEST (instead of D:\STORAGE - to rule out the possible issues with the SOURCE folder, maybe it is excessive step since the error in the log clearly states the access is denied to J:\STORAGE - NOT to the source folder but...) but the result was exactly the same.

And the icing on the cake - I tried to copy the D:\TEST folder to J:\Reports - NOT to J:\STORAGE, e.g. to the folder in which even the script is able to create its logs:

Once again: the same script raises Access Denied error when trying to copy some files to J:\Reports and successfully writes the log to the same J:\Reports folder!!!

What am I missing here???

Regards,
Michael Firsov
Please sign in to rate this answer.
MotoX80 37,156 Reputation points

2025-11-13T14:16:10.45+00:00

It would appear to be related to however robocopy references the file owner. You have /COPY:DAT (without "O") so it should not copy the owner from the source. That would imply that the owner would be set to the account that the robocopy process is executing as. But I don't know what API calls robocopy makes. Try Copy-Item and see if you can copy files from D:\Test to the J: drive folders.

While this is a nice little brain teaser to see if we can figure out what's going on, the root cause to your problem is that you are using an account (TASK) to copy files, and it doesn't have sufficient NTFS permissions to do that. I always removed CreatorOwner from my main user data shares/folders. To me, CreatorOwner would make sense for a "drop box" folder where you wanted to allow users to copy files to it, but would restrict them from other users files.

Remove the CreatorOwner ACL from the permissions and grant the TASK user full control.

Hram Admin 290 Reputation points

2025-11-14T11:03:08.9833333+00:00

"You have /COPY:DAT (without "O") so it should not copy the owner from the source." - does it mean the owner must be set according to the destination folder as COpy-Item does (in your tests)???

MotoX80 37,156 Reputation points

2025-11-14T13:23:21.49+00:00

If you have a source folder with a bunch of files that were created by your end users, each of those files might have different owners.

Robocopy can copy things like permissions, owner, and auditing.

/COPY:copyflag[s] :: what to COPY for files (default is /COPY:DAT). (copyflags : D=Data, A=Attributes, T=Timestamps, X=Skip alt data streams (X ignored if /B or /ZB). (S=Security=NTFS ACLs, O=Owner info, U=aUditing info).

In a Powershell prompt, the quickest way to display the owner is to run a dir command via a cmd prompt.

cmd /c "dir /q"

In your case, robocopy is executing as an account that does not have full control or explicit write access to it. Correct? It's relying on the CreatorOwner ACL for access.

The 4 line test you did proves that out-file and copy-item work against the J: drive. Those files should all have the TASK account as the owner. But I don't know about your TEST source folder and what owners are on those files. That was why I commented: "Try Copy-Item and see if you can copy files from D:\Test to the J: drive folders."

It seems to me that the issue is one of 1 of 2 things. The owner that is set on the source files, or whatever API robocopy uses to copy a file and then set the owner based on the /copy: setting.

All of that is really a moot point to me. If you want to use this TASK account to copy files, then remove the CreatorOwner ACL and grant TASK full control.

If you need to maintain the owner attribute of the source files then use robocopy's /COPY:DATO switch.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Hram Admin 290 Reputation points

2025-11-17T09:13:20.17+00:00
"If you want to use this TASK account to copy files, then remove the CreatorOwner ACL and grant TASK full control.

If you need to maintain the owner attribute of the source files then use robocopy's /COPY:DATO switch." - yes, I agree - thank you!

I just want to perceive what am I seeing in this particular case:

these files - when copied MANUALLY -

"test" | out-file J:\Storage\Storage-Test.txt

"test" | out-file J:\Reports\Reports-Test.txt

copy-item J:\Storage\Storage-Test.txt J:\Reports copy-item J:\Reports\Reports-Test.txt J:\Storage

...were copied in PS session run as backupserver\admin account but in which the J: drive was mapped under backupserver\task account (which does not have any permissions on J:)

The result: the files have been copied successfully and the owner for both files (Storage-Test.txt and Reports-Test.txt) is set to backupserver\task account (the account under which the J is mapped).

As far as I understand this does work due to the destination's Creator Owner permission (in this case the Creator Owner is the account under which the J: drive is mapped).

2 when I try to copy some folder (even the newly-created D:\Test folder with the default owner set to backupserver\admin) to the same J:\REPORTS folder by running the script - the script does write the log AND SET THE OWNER TO THE SAME backupserver\task account BUT REFUSES TO COPY THE FOLDER ITSELF - I just don't understand what's the difference for robocopy between these two actions (write the log to J:\REPORTS that succeeds and the folder copy operation to J:\REPORTS that throws the Access Denied error) ???

...this is a rhetorical question so thank you so much for your help once again!

Regards,

Michael Firsov
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Hram Admin 290 Reputation points

2025-11-18T07:16:50.81+00:00
"If you want to use this TASK account to copy files, then remove the CreatorOwner ACL and grant TASK full control.

If you need to maintain the owner attribute of the source files then use robocopy's /COPY:DATO switch." - yes, I agree - thank you!

I just want to perceive what am I seeing in this particular case:

these files - when copied MANUALLY -

"test" | out-file J:\Storage\Storage-Test.txt

"test" | out-file J:\Reports\Reports-Test.txt

copy-item J:\Storage\Storage-Test.txt J:\Reports copy-item J:\Reports\Reports-Test.txt J:\Storage

...were copied in PS session run as backupserver\admin account but in which the J: drive was mapped under backupserver\task account (which does not have any permissions on J:)

The result: the files have been copied successfully and the owner for both files (Storage-Test.txt and Reports-Test.txt) is set to backupserver\task account (the account under which the J is mapped).

As far as I understand this does work due to the destination's Creator Owner permission (in this case the Creator Owner is the account under which the J: drive is mapped).

2 when I try to copy some folder (even the newly-created D:\Test folder with the default owner set to backupserver\admin) to the same J:\REPORTS folder by running the script - the script does write the log AND SET THE OWNER TO THE SAME backupserver\task account BUT REFUSES TO COPY THE FOLDER ITSELF - I just don't understand what's the difference for robocopy between these two actions (write the log to J:\REPORTS that succeeds and the folder copy operation to J:\REPORTS that throws the Access Denied error) ???

...this is a rhetorical question so thank you so much for your help once again!

Regards,

Michael Firsov
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Permissions problem

8 answers

Your answer