This issue appeared during the following operation. First, a PowerShell script was used to create a symbolic link:
New-Item -ItemType SymbolicLink -Path d:\share_folder\ -Name latest -Target d:\share_folder\v1000 -Force
This command creates a shortcut named ‘latest’ inside d:\share_folder, pointing to the sibling folder v1000. Then share_folder was shared over the network. When accessing \\xxx.xxx.xxx.xxx\share_folder\latest from another machine, the error appeared: ‘Cannot follow symbolic link because its type is disabled’. Searching online revealed the reason, for example: https://www.zywvvd.com/notes/system/windows/symlink-disabled/symlink-disabled/
By default, Windows only allows symbolic link following locally. Remote‑to‑local (a shortcut inside a share pointing to a local path) and remote‑to‑remote (a shortcut inside a share pointing to another share path) are disabled. Following the solution, running: fsutil behavior set SymlinkEvaluation R2L:1 enables remote‑to‑local following. But then accessing the link produced ‘target folder does not exist’.
Continue reading…