How do I overcome the "The symbolic link cannot be followed because its type is disabled." error when getting the target of a symbolic link?

Question

Following on from a previous question, I am creating a symbolic link on a Server 2008 from a Vista machine using UNC paths. I can create the link just fine. I can go to the Server 2008 box and double click on the link in explorer to open the target file. What I cannot do though is use FileCreateW to get a handle to the UNC path link (from the Vista box). When I try it, it fails and GetLastError() returns error code 1463 (0x5B7), which is:

The symbolic link cannot be followed because its type is disabled.

How to enable its "type" in Server 2008 (assuming the error means what it says)?

Answer 1

Well I found the answer, though to describe it as badly documented is an understatement!

First of all, this TechEd article highlights the fact that users can "enable or disable any of the four evaluations that are available in symbolic links". Those four "evaluations" include remote to local and local to remote. It doesn't give any clue as to how to do this.

However a further search revealed this fsutil help page, which does actually document how to "enable or disable any of the four evaluations that are available in symbolic links". So to fix the problem I was having, I need to issue the following command on the Vista box:

fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1

in order to allow full access to where symlinks are pointing on both local and remote machines.

Answer 2

To add to @David Arno's helpful answer, based on W7:

---

fsutil.exe can be made to show what arguments it takes by simply running:

fsutil behavior set /?

To report the current configuration, run fsutil behavior query SymlinkEvaluation - see @Jake1164's answer, particularly with respect to how a group policy may be controlling the behavior.

The symbolic-link resolution behavior is set on the machine that accesses a given link, not the machine that hosts it.

The behavior codes for fsutil behavior set SymlinkEvaluation - namely L2L, L2R, R2L, and R2R - mean the following:

• L stands for "Local", and R for "Remote"
• The FIRST L or R - before the 2 - refers to the location of the link itself (as opposed to its target) relative to the machine ACCESSING the link.
• The SECOND L or R - after the 2 - refers to the location of the link's target relative to the machine where the LINK itself is located.

Thus, for instance, executing fsutil behavior set SymlinkEvaluation R2L means that you can access links:

• located on a remote machine (R)
• that point to targets on that same remote machine (L)

---

Unlike what David experienced on Vista, I, on W7, was able to resolve a remote link that pointed to a resource on another remote machine by enabling R2R alone (and not also having to enable R2L).

Answer 3

I recently found this on all my corporate Windows 7 boxes when one of my legacy programs stopped working. After some searching and finding these settings I tried setting via the command line and via the registry with no relief.

I found that you can use the command from an elevated prompt:

fsutil behavior query SymlinkEvaluation

This will return the status of these links AND in my case that they are being controlled by a group policy! Thanks IT department (you f@$#%$rs)!

Answer 4

These settings can also be manipulated directly via the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem: See SymlinkLocalToLocalEvaluation, SymlinkLocalToRemoteEvaluation, SymlinkRemoteToLocalEvaluation, SymlinkRemoteToRemoteEvaluation.

if with "fsutil behavior query SymlinkEvaluation" you get message .."is currently controlled by group policy"..., check HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Filesystems\NTFS or simply search throug registry for "Symlink"