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

This was useful and I only add that the client, as well as the server hosting the symbolic link, needs to have R2R:1 set and enabled — Jamie Jackson, Mar 23 '20 at 23:03

score 67 · Answer 1 · edited Dec 11 '10 at 17:04

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.

This page has some more information fsutil: http://technet.microsoft.com/en-us/library/cc785435(WS.10).aspx — ErJab, Jul 15 '11 at 16:15

score 46 · Accepted Answer · edited May 23 '17 at 12:10

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" (who would've thunk?)
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).

score 12 · Answer 3 · answered Jun 23 '14 at 11:19

12

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

enter image description here

answered Jun 23 '14 at 11:19

Jake1164

12,062
6
41
61

1

That was very helpful. Thank you – Oscar Ortiz Sep 17 '14 at 21:44
1

in the GPO you can Change it in "Computer Configuration > Administrative Templates > System > Filesystem" and configure "Selectively allow the evaluation of a symbolic link" – deru May 11 '17 at 06:45

score 8 · Answer 4 · answered Apr 23 '15 at 07:16

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"

changing HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Filesystems\NTFS worked for me — Fernando Gabrieli, Apr 13 '16 at 22:38

score 5 · Answer 5 · answered Dec 17 '08 at 18:28

5

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!

answered Dec 17 '08 at 18:28

2

"The default link type should be inferred automatically from the target pathname type!" Agreed! – Fowl Mar 01 '09 at 10:39
Since a link can be to a link itself, this would require recursive evaluation all the way to the root object, at creation time, which would make a symbolic link non-portable between machines or even potentially non-portable on the same machine, if another link were made to it. That's kind of the point of a symlink - it's supposed to be a universal reference that is runtime-evaluated. It's impossible to infer from target type what you want, unless it is a UNC path, in which case, for NTFS, it MUST be a symlink. All other cases are ambiguous. – dodexahedron Jan 02 '19 at 18:20

mwolfe02 · Answer 6 · 2014-05-20T12:58:25.197

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

Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

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

Nice find. Do you have a link to any MS documentation on this though? It would be worth adding IMO if you do. — David Arno, May 20 '14 at 12:16

score 2 · Answer 7 · answered Jul 15 '14 at 22:34

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.

score 1 · Answer 8 · answered Oct 08 '09 at 04:19

1

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

answered Oct 08 '09 at 04:19

Ian Kelling

8,644
8
31
37

Junction points are bad for performance in case of R2R, because then all traffic is routed over the server containing the junction point. – Daniel Oct 05 '18 at 07:38

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?

8 Answers8

Linked