So this is a weird one...

 

I have a weekly script I've used in the past to back up all my recorded tv from my PC to my former windows server. I'm trying to use this same robocopy script to point at Unraid, but strange things are happening.

 

When I run the script, it fails immediately on permissions problems. Not only is nothing copied from my windows machine, but the Unraid folder destination gets its permissions all locked down. I still have read access, but lose write. Only "nobody" retains ownership of the files in the folder.

 

I'm forced to run "Docker Safe New Perms" to regain my write access.

 

Here is the script causing my problems:

robocopy "d:\Recorded TV" "\\Tower\Recorded TV" *.wtv /mov /np /log:d:\RobocopyLogs\log.txt /xa:sh /R:2 /W:2

 

Any assistance would be greatly appreciated since I'm stumped!

To be clear, I can manually move files from this Windows box to my Unraid share, but the Robocopy fails and makes my unraid share lock down its write permissions.

Is "Recorded TV" a public or private share? Whose credentials is the script using to gain access to the share? Suppose instead of using \\Tower\Recorded TV as the destination you first map it to a drive letter (say, R:) using your own credentials, if the script then uses R:\ as the destination do you then still have access?

"Recorded TV" is a private share. The user running the script has R/W permissions on the share - I'm manually running the batch file as the user with proper permissions while I debug.

 

Oddly enough, I changed the share to public but the same behavior happens.

 

I get "Access Denied" errors coming back from the script and the share becomes locked down to "nobody" saying "You require permissions from Tower\Nobody to make changes to ..."

I removed Robocopy from the mix and just ran:

move "d:\Recorded TV\*.wtv" "\\Tower\Recorded TV"

 

This worked without issue.

 

I'd prefer to use Robocopy, but I guess this will work fine.

 

Still, no idea why Robocopy totally messes up all the file permissions.