I ran into a situation where after running a Robocopy script to migrate folders from an old server into a new one the folders were not visible. This was unexpected because as the script was running we could see the folders populate at the new server but after they were copied they disappeared. We knew that they were not gone because from a client PC the folders and file could be accessed and the users all had the proper permissions to the folders and files contained therein. It was just that from the server, the folder appeared not to exist.
- We could run an elevated command prompt and a /dir would not the list folder.
- We could run an elevated command prompt and a net share would not list the share.
- We could look in the share wizard on the server and the share was listed.
- File space was taken up
- Users could interact with the share, folders and files normally
Our Robocopy script copies the folder, subfolders, files, share and security permissions. The destination was the root of the drive.
The above is in bold because it is what caused this problem. When you Robocopy a folder with permissions to the root of the drive it will inherit the attributes of the root. The attributes of the root are of course the attribute of the hidden $ share of the drive which are SH (system and hidden)
Now you might try what I did which is to remove the SH attribute. It won’t work. Those attributes can’t be removed without another attribute being present. So first you need to add the +A attribute. Then go ahead and remove the –SH attributes. Your folder will now be visible.
Robocopy documentation offers another alternative. They suggest that you do not copy permissions when the destination is the root of the drive. A colleague suggests that you setup a temp folder at the root first, then robocopy your data into it. When it is done move your copied data to the root and delete the temp folder. Either of these suggestions would also work.