6

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
ren D:\Shares\Shared\Admin\Finance D:\Shares\Shared\Admin\Finance_old
mklink /D D:\Shares\Shared\Admin\Finance \\abc\def\Finance

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.

Aside: Windows SymLink Permissions

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:

Share settings

Successfully shared

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:

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
  • 1
    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
2

I would encourage you to take a look at DFS. I've not gone through the setup myself but I've seen admins successfully migrate a share from one Windows CIFS server to another with it.

It looks a bit like this:

  1. Server1 contains a share at \\Server1\share. A DFS share gets created that looks like \\DFS\share which takes information from \\Server1\share.
  2. Server2 gets stood up and added to the DFS replication. Now all the data from \\Server1\share is available at \\server2\share and \\DFS\share.
  3. Change your GPOs (or whatever is mapping the shares) to \\DFS\share rather than \\Server1\share.
  4. Now you can remove \\Server1\share from the DFS and shut it down. Any time you need to migrate the share again, you can add a new server to the DFS replication. Additionally, you can have multiple servers in the DFS continuously for backup (one server dies, the other has the data) or availability (one server at two distant offices) reasons.
  • Actually that's why most of this is happening: we're moving to DFS so that I never have to worry about this migration again (your point #4). The problem right now is (a) I only have the 1 DFS server, so I can't set up replication, and (b) end users/programs are not ready to change their paths - some use the mapped network drive which I can change via GPO, but others use UNC paths (which is why the symlink helps) – dthor Mar 8 at 15:53
  • Can't help with the one server issue other than to suggest a VM or a container if you don't have ready hardware. Once you get a second server up, you could create mess with DNS to get the clients to still access the correct server provided the UNC path isn't an IP. Standardizing all your links to a DNS CNAME is probably your first order of business. Then you can do all kinds of trickery like load balancing and proxies. – duct_tape_coder Mar 8 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.