Even though this post is old, I came across the same thing today with Windows 7 clients accessing redirected folders on a Windows Server 2012R2 with Excel 2013. So the problem is still there.
Problem Reproduction
Since the original description was a bit vague here is the exact way to reproduce the problem:
- "my documents" (or probably any other library) is redirected to a server share
- "my documents" contains an MS Excel (probably any MS Office) document.
- create a link to that document in another redirected library, for example on the "desktop".
- trying to open the document by double-clicking the link will prompt for the user's credentials, while a double-click directly on the file in "my documents" works fine.
It is interesting to note that this only happens when creating the link from within a redirected library like "my documents". If you access the same shared folder directly by its UNC path and create the link from there, everything works fine as well.
The Solution that worked for me
It is a permission problem on the redirected folders share, even though it looks fine at first and is perfectly accessible for other programs than MS Office.
The shares that host redirected folders need exactly these permissions, as documented by Microsoft (as early as Windows Server 2003):
on the share:
EVERYONE:F (or at least F for the users that access the share)
in the file system:
CREATOR OWNER - Full Control (Apply onto: Subfolders and Files Only)
System - Full Control (Apply onto: This Folder, Subfolders and Files)
Domain Admins - Full Control (Apply onto: This Folder, Subfolders and Files)
Everyone - List Folder/Read Data (Apply onto: This Folder Only)
Everyone - Read Attributes (Apply onto: This Folder Only)
Everyone - Traverse Folder/Execute File (Apply onto: This Folder Only)
Everyone - Create Folder/Append Data (Apply onto: This Folder Only)
I was missing the last 2 permission entries, thinking I could get away with just read access. Adding those 2 entries, which seem totally unrelated, solved the problem.
It works!
When I was looking in the restore section of Windows Server Backup, it didn't show the documents. But, I did a little test-recovery of my own files and the folder with my documents showed up with all of the documents inside.
The user that is doing the backups has to be a part of the backup operators group. That group can evidently backup documents that it doesn't have access too.
Hope this helps someone in the future :)
Best Answer
The folders aren't being renamed. They have a
Desktop.inifile present and Windows Explorer is using the instructions in that file to alter the name being presented on-screen. The files are hidden by default, and unless you've asked Windows Explorer to display hidden files and unticked the "Hide protected operating system files" you're not going to see them.If you do find and delete them they're just going to come back. If you're like me, you can use a File Screen to prevent the files from being created in the first place. That's what I've done most everywhere because I find the
desktop.inifiles provide little utility.