When Robocopy Fails because of Folder Permissions...
-
@scottalanmiller said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
We're in the process of moving all files on a specific volume from one server (old Server 2003 machine) to a volume on a new file server (Server 2012 R2). We tried robocopy on the source server but actually found the admin accounts we were using to run the robocopy do not have access to all subfolders of the volume.
What kind of admin account doesn't have file access?
That would be the kind that some consulting firm setup before you got here.
-
@Mike-Davis said in When Robocopy Fails because of Folder Permissions...:
I would think taking ownership of the files makes the most sense. Does your backup account have access? If not, those files aren't getting backed up. How did files get created that an admin doesn't have permissions to? Were permission set on the drive where a user has full control?
Administrators of the server have full control from the root volume, but it looks like inheritance was broken at some point before the folders to which we do not have access. There are users will full control of folders set in many areas. One of our projects after moving servers will be to clean up permissions and remove the full control.
The backup agent is running under a local system account, which I believe have access to all folders on the system (did not see any errors about file / folder access in backup job logs).
-
If that's the case I would fix all the folder permissions before trying to move stuff. The problem will keep coming back to bite you.
-
@Mike-Davis said in When Robocopy Fails because of Folder Permissions...:
If that's the case I would fix all the folder permissions before trying to move stuff. The problem will keep coming back to bite you.
Exactly this. Check out icacls on the 2003 server, fix the permissions, then do your move and adjust on the new server.
If this were a pair of VMs, you could disconnect the drive from one VM to another and call it done (mostly).
-
@Grey said in When Robocopy Fails because of Folder Permissions...:
@Mike-Davis said in When Robocopy Fails because of Folder Permissions...:
If that's the case I would fix all the folder permissions before trying to move stuff. The problem will keep coming back to bite you.
Exactly this. Check out icacls on the 2003 server, fix the permissions, then do your move and adjust on the new server.
If this were a pair of VMs, you could disconnect the drive from one VM to another and call it done (mostly).
Unfortunately the Server 2003 machine is physical and uber low on storage space. The new file server is a VM, however. I'd not heard of icacls but will definitely check it out. Thanks.
-
@scottalanmiller said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
We're in the process of moving all files on a specific volume from one server (old Server 2003 machine) to a volume on a new file server (Server 2012 R2). We tried robocopy on the source server but actually found the admin accounts we were using to run the robocopy do not have access to all subfolders of the volume.
What kind of admin account doesn't have file access?
I'm sure he can get access, the admin just doesn't have everyday access - do you see an actual problem with this?
-
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
f our projects after moving servers will be to clean up permissions and remove the full control.
I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.
robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)
-
@Dashrender said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
f our projects after moving servers will be to clean up permissions and remove the full control.
I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.
robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)
This may be the missing link. Not that we shouldn't fix permissions, but we really do need to get the data transferred. I will give it a try over the weekend and let you know how things go. Thanks!
-
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
@Dashrender said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
f our projects after moving servers will be to clean up permissions and remove the full control.
I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.
robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)
This may be the missing link. Not that we shouldn't fix permissions, but we really do need to get the data transferred. I will give it a try over the weekend and let you know how things go. Thanks!
Why do you assume permissions are broken?
My boss has files on the server that I have no business touching. She can (and does) use Windows file permissions to prevent my casual looking at those files. I don't see a problem with this.
-
@Dashrender said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
@Dashrender said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
f our projects after moving servers will be to clean up permissions and remove the full control.
I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.
robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)
This may be the missing link. Not that we shouldn't fix permissions, but we really do need to get the data transferred. I will give it a try over the weekend and let you know how things go. Thanks!
Why do you assume permissions are broken?
My boss has files on the server that I have no business touching. She can (and does) use Windows file permissions to prevent my casual looking at those files. I don't see a problem with this.
There's not a problem with using permissions to keep people out of folders as you mention, and it goes right along with the JITJEA principle. Our real issue is that the folks who setup permissions on the server set individual user permissions instead of assigning the permissions to groups. That's where it seems messy and broken to me. But I completely agree with you that there are things I don't need to stumble upon and see, and that's a good thing.
-
@Dashrender said in When Robocopy Fails because of Folder Permissions...:
@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:
f our projects after moving servers will be to clean up permissions and remove the full control.
I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.
robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)
The backup mode parameter worked like a champ. Thanks again for the help.
