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?

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)?

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 Rbefore 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 Rafter 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).

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.

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 [email protected]$#%$rs)!

enter image description here

These settings can also be manipulated directly via the registry at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem:
See SymlinkLocalToLocalEvaluation, SymlinkLocalToRemoteEvaluation, SymlinkRemoteToLocalEvaluation, SymlinkRemoteToRemoteEvaluation.

if with “fsutil behavior query SymlinkEvaluation” you get message ..”is currently controlled by group policy“…, check HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsFilesystemsNTFS
or simply search throug registry for “Symlink”

Thanks David for the tip, I was becoming desperate to fix this problem which made symlinks mostly useless.

One should note that the default configuration for Vista is L2L and L2R enabled, but R2R and R2L disabled.

I first tried to enable only R2R, but this is not sufficient. R2L has to be enabled too.

The next question on my list: How to get rid of that stupid /D switch for the mklink command for directory links. The default link type should be inferred automatically from the target pathname type!

These settings can also be manipulated directly via the registry (requires local admin to write):

Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem

Registry values (name/data pairs):

Name                             Type       Data  (1: Enabled; 0: Disabled)
SymlinkLocalToLocalEvaluation    REG_DWORD     1
SymlinkLocalToRemoteEvaluation   REG_DWORD     1
SymlinkRemoteToLocalEvaluation   REG_DWORD     1
SymlinkRemoteToRemoteEvaluation  REG_DWORD     1

Official documentation is difficult to find, but this appears to be an official Microsoft page: Selectively allow the evaluation of a symbolic link

FYI if you have Group Policies in place controlling SymlinkEvaluation settings you CAN still set them yourself from the command line. They will be overwritten by GP at next reboot/login but your settings will work during your user session.

So as a workaround if you need to set it to something other than what GP dictates you could even run a script at logon to set them after GP is applied.

Remote junction points work by default. For files you still need symlinks.

Leave a Comment