# Summary

Is it possible to share a symlink to a network location as a Network Share in Windows? E.G:

D:\folder\Shared\foo on \\server is shared as \\server\foo, where D:\folder\Shared\foo is actually a directory symbolic link to \\other\server\bar.

Or is this an XY Problem?

# Background

We have a Windows Server 2008 R2* virtual machine, fs1, with 2 virtual disks. C: is of course the system drive and D: is a data drive. We share multiple folders on D: via SMB using Windows Share and Storage Management. For example:

• D:\Shares\Shared\Engineering is shared as \\fs1\Engineering
• C:\Shares\Shared\Admin is shared as \\fs1\Admin

These shares are typically mapped as network drives on user workstations. E:\ might be mapped to \\fs1\Engineering, for example.

I want to move these shares off of this virtual disk and onto our new storage location \\abc\def, and I want to do this transparently to the end user (at least for now - eventually the original path will go away but that's out of scope of the question).

*Upgrading to 2016 or 2019 this year.

### Where I am Now

Certain subfolders of the shared folders are being migrated by first by copying the data to the target location (\\abc\def) using RoboCopy, then renaming the original path to a backup path, and finally creating a directory symlink to the new target. The process looks roughly like so (some additional flags/options are omitted for brevity):

robocopy D:\Shares\Shared\Admin\Finance \\abc\def\Finance /mir


Then the Finance_old folder gets permissions changed and eventually deleted once we've verified that things are working well.

Note that the root shared folder, D:\Shares\Shared\Admin, is still an actual folder and not a symlink.

This works very well - it can be done with less than 1 second of downtime, and all end user programs continue to work.

I have already set up a GPO to allow Remote Link to Remote Target symbolic links. source1, source2

# The Problem

There are too many subfolders to make symlinks for each one, so instead I'd like to make a single symlink for each shared root folder.

I can successfully create a symlink in the D:\Shares\Shared directory:

mklink /D D:\Shares\Shared\symlink_test \\abc\def\target


I can then successfully add it to Share and Storage Management:

And the share shows up when browsing \\fs1 in Windows Explorer.

But when I try accessing the shared location \\fs1\symlink_test, I get a "Device not ready" error:

### Hey it says stuff about permissions!

I have checked all of the permissions, the location should be readable.

• I can access \\abc\def\symlink_test directly.
• I can access D:\Shares\Shared\symlink_test and it correctly takes me to the target location.

So I don't think it's a permission issue.

# Other Info

• fs1 is running Windows Server 2008 R2
• \\abc\def is actually a Distributed File System namespace
• \\abc\def\foo is a folder in the DFS namespace with a target on a Synology NAS \\nas1\foo
• By sharing the symlink itself, you're effectively telling the old server to access the remote content and serve it to the clients. As far as I'm aware, the Windows file server isn't capable of doing this, it can only serve out local content. To put that another way, what you're doing now works because the client processes the symlink; what you're trying to do won't work because the server is processing the symlink. – Harry Johnston Mar 7 at 21:38
• ... that said, the obvious thing to try is to make sure that the local system account on fs1 has access to \\abc\def and to all the content it contains. You can use psexec (available from the Microsoft web site) to check, i.e., if something like psexec -s \\fs1 cmd /c dir \\abc\defworks then the access rights are OK. As I said, I don't think it will work anyway, but you could try. – Harry Johnston Mar 7 at 21:40
• Hmm... I was afraid of that. I did check psexec and the access rights are correct. Looks like I'll have to come up with another solution. I wonder if I can do some DNS hackery... – dthor Mar 8 at 16:13
• resharing network locations is in general Bad Idea™ - you move from client<->server to client<->middleman<->server – warren Mar 12 at 14:47
• With little data, I suspect you're hitting a double hop situation and failing authentication - as Harry explained. DFS is different because it provides a referral to the client about where to go get the data directly. DFS is a good first step for hiding your underlying topology. Clustering is a more advanced approach for ensuring business continuity. – Matthew Wetmore Mar 14 at 6:56