I'm using Robocopy to copy the contents of my source to an unRAID share.  My desire to to copy directly into the root of the share.

 

If my destination equals the root of the share, write permissions get removed from the share.  Permissions get set to drwxr-xr-x nobody users and I receive an access denied error message.

robocopy.exe %source% \\tower\share /dcopy:dat /copy:dat /mir /tee /log+:c:\logs\robocopy.txt /r:2

 

If I direct the copy to a subfolder inside the share, things work as expected.  

robocopy.exe %source% \\tower\share\subfolder /dcopy:dat /copy:dat /mir /tee /log+:c:\logs\robocopy.txt /r:2

 

Does anyone know why this is?

I might be completely wrong here, but try adding \ after share so it's like this:

 

robocopy.exe %source% \\tower\share\ /dcopy:dat /copy:dat /mir /tee /log+:c:\logs\robocopy.txt /r:2

I'm just guessing here as I really have no idea, but try it

Thanks for your input.  I don't think the trailing slash makes a difference in Windows, but I will try it once my copy finishes.

Edited March 4, 20179 yr by dboonthego
Grammar mistake

3 hours ago, strike said:

 

I might be completely wrong here, but try adding \ after share so it's like this:

 

 I tried this for kicks.  It didn't work.  The remaining command after the slash is treated as a subfolder.  It thinks the options are all part of the destination path and fails miserably.

 

Ah I see, well then I was at least right in my first statement, I was completely wrong I just vaguely remembered something about getting access denied when I was mapping a network share in windows once and using \\server\share and not \\server\share\ or maybe I'm getting that wrong as well, idk. Anyway I'm sure someone else can help you

Try putting the destination in quotes "\\tower\share"

10 minutes ago, mr-hexen said:

Try putting the destination in quotes "\\tower\share"

 

My source path has spaces in it, so I have quotes around that.  My destination path doesn't have spaces.  I have tried with and without quotes.  Both fail.

 

The kicker is the same exact command works with \\tower\share\subfolder, but jacks up share permissions with \\tower\share.  My share is set to public.  After executing the command, Windows tells me "You need permission to perform this action." if I try to write to the share.

 

Only thing I can think of is unRAID created \\tower\share, but my windows user created the subfolder inside the share.  That is part of the equation somehow.

Try mounting the share as a drive in windows then writing to the "drive"?

3 minutes ago, mr-hexen said:

Try mounting the share as a drive in windows then writing to the "drive"?

 

Did that too. I swear, I feel like I've tried everything.

Then you need to drop down to the command line and change the permissions on the root folder, to 777 I believe. I think you also can use the new permission script if you go to tools, preferably the docker safe permission script so you not mess up your dockers

for the docker safe script I think you need to have the CA backup/restore plugin installed

2 hours ago, strike said:

Then you need to drop down to the command line and change the permissions on the root folder, to 777 I believe.

 

That's sort of the reason for my post.  The permission is already 777.  It gets changed to 755 after I run execute the Robocopy command and then I'm locked out of the share; from writing at least.  I actually think changing the owner from "nobody" to my windows username will work. I will try that later, but I don't understand why I even need to do that from a security perspective.  The share is public.

Edited March 4, 20179 yr by dboonthego

12 minutes ago, dboonthego said:

I actually think changing the owner from "nobody" to my windows username will work

 

That'll work. The thing I don't understand is why the permissions change when you execute the robocopy command. I don't understand the command as I've never used robocopy, but maybe the command copies the permission on the source folder/file or something? If the permission change to 755 when you run it it won't matter if the share is public as only the owner can write to it. But yeah, change the owner to the windows user should solve it. If you don't figure out why the permissions changes

Changing the share owner worked, but it still changes the permission to 755.  If anyone knows why, I would love to hear it. 

17 hours ago, strike said:

I don't understand the command as I've never used robocopy, but maybe the command copies the permission on the source folder/file or something?

Thanks for your help.  I think it is a bug within Robocopy.  I read somewhere it doesn't handle inherited permissions too well.  There is a specific S flag to copy security.  It would be used in the copy switch like this: /copy:dats or /copyall.  I specifically omit that.

 

FYI, since you don't know what the switches do, this is what they mean:

 

/dcopy:dat = what to copy for directories (copyflags : D=Data, A=Attributes, T=Timestamps).

/copy:dat = what to copy for files (copyflags : D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info).

/mir = mirror the destination with the source.  (If a file exists on the destinaton, but not the source, it will get deleted)

/tee = display output to screen in addition to log file

/log+ = append to the log file, the log file path

/r = number of times to retry a failed cooy