none
Creating a symlink directory on a network share to a path below a mapped drive letter, local path, or UNC path does not work

    Question

  • Am I correct in assuming I can not create a `symlinkd` to a network share, local path, or a UNC path on a network share that will be accessible by clients?

    ###Mapped drive letters don't work:

    1) navigate to a network share:

    pushd \\windows2008server\share\


    2) make a hardlink:

       
    mklink /d test_sharedir t:\directory\
    dir .\test_sharedir
    #Directory of Z:\test_sharedir
    #File Not Found

    UNC paths don't work:

    1) navigate to a network share:

    pushd \\windows2008server\share\


    2) make a symlink:

    mklink /d test_dirunc \\windows2008server\share
    dir .\test_dirunc
    #Directory of Z:\test_dirunc
    #File Not Found

    I can create a functional `symlinkd` on a local drive to a mapped drive letter or a UNC path.

    Are my assumptions above correct?

    We are in the middle of a migration and have created two symlinkd to UNC paths for shared DLLs, one below c:\windows\system32\ (directing to a share containing 64-bit DLLs) and one below c:\windows\syswow64 (directing to a share containing 32-bit DLLs).

    On the file server, we have had a path to 32-bit DLLs (from Windows 7 clients: s:\dll\).  I am attempting to rename this directory so that it is accessible via "s:\dll32\" and would like to create a symlinkd that links "s:\dll" to "s:\dll32" [again where S: is a mapped drive on a Windows 2008 server].  How do I do this?

    Thanks,

    Matt

    Thursday, October 31, 2013 1:19 PM

All replies

  • Hi,

    According to your description, my understanding is that you want to create symbolic links with network share to a mapped drive letter or a UNC path but got “The system cannot find the path specified” error.

    I have done a test with the same setting an on my PC. In “c:\windows\system32\”, I create a folder named dll. Then I share the folder and map the folder “c:\windows\system32\” driver letter s: on the client. Then create a symbolic link on the server using the below command:

    mklink /d c:\windows\system32\dll32 c:\windows\system32\dll

    Then you can create a symlinkd that links "s:\dll" to "s:\dll32" on the client.

    Please note: you cannot use mklink /d s:\dll32 s:\dll on the client, it will got “The system cannot find the path specified” error.

    If I have misunderstanding, please feel free to let me know.

    Regards,

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    • Marked as answer by Mandy YeModerator Thursday, November 7, 2013 1:18 AM
    • Unmarked as answer by mbrownnyc Thursday, November 7, 2013 11:52 AM
    Monday, November 4, 2013 10:01 AM
    Moderator
  • Hello Mandy,

    To be clear: Creating a symlink in a CIFS share to another CIFS share works, but does not redirect.

    I believe this is a limitation of how the CIFS client stack treats SYMLINKs (it doesn't process them).

    Try the following:

    Create a link on a UNC path to CIFS share, to an UNC path to a CIFS share.

    mklink /d \\%logonserver%\netlogon\test \\%logonserver%\netlogon\source

    The SYMLINKD is created, but it is not followed when a client accesses it.

    Thanks,

    Matt

    Thursday, November 7, 2013 11:57 AM
  • Wednesday, November 13, 2013 6:39 AM
    Moderator
  • Hello again Mandy,

    This SYMLINKD is still not followed by the Windows CIFS client.

    1) Log onto windows 2008 server via RDP

    2) open cmd

    3) `cd` to shared directory (let's say d:\share\test)

    4) `mklink /d shareroot d:\share\test`

    returns: `symbolic link created for shareroot <<===>> d:\share\test`

    5) attempt access by Windows 7 client over CIFS:

    pushd \\win2008server\share\test
    dir
    ...
    11/13/2013  10:19 AM    <SYMLINKD>     shareroot [d:\share\test]
    ...
    dir shareroot
     Volume in drive Z is VolumeName
     Volume Serial Number is XXXX-XXXX
    
     Directory of Z:\share\shareroot
    
    File Not Found

    So, it must be the CIFS client stack does not process SYMLINKDs on an UNC path.

    Can you confirm the same?  If so, can I put this in as a feature request for the Client Redirector (CIFS client stack)?


    Thanks,

    Matt



    • Edited by mbrownnyc Wednesday, November 13, 2013 3:26 PM
    Wednesday, November 13, 2013 3:24 PM
  • Hi,

    Please refer to the article below to control CIFS client access to symbolic links:
    https://library.netapp.com/ecmdocs/ECMP1196993/html/GUID-9CA64CF7-63DF-41B4-8919-534E5FC92D2D.html

    Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Regards,

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Friday, November 15, 2013 8:38 AM
    Moderator
  • Hello Mandy,

    The link you sent me is for Netapp CIFS server daemon contained within DataOnTap (the Netapp OS) to follow symlinks.  I am inquiring about the Microsoft products Windows Server and Windows 7.

    To gain a better understanding of the Microsoft Windows Server and client (Windows) CIFS stacks and interaction of the stacks, I have referred to Figure 6 "Server Message Block Server Model" within the following (albeit older) document: http://download.microsoft.com/download/2/8/0/2800a518-7ac6-4aac-bd85-74d2c52e1ec6/tuning.doc

    You will see the following:

    I assume that the Windows Server CIFS server service must be "smart enough" to determine that a CIFS client is attempting access to a SYMLINKD and actually fill the request by following the SYMLINKD.  The CIFS server service does not appear to operate like this.

    1) Am I correct in my assumption that the CIFS client (redirector) and the CIFS server (server) do not following symbolic links (whether they be file or directory)?

    2) If not, how do I submit a feature request for this so that it can be reviewed and approved or not approved for inclusion/hotfix release?

    Thanks for your time,

    Matt Brown

    [UPDATE]

    Note that you can use a `directory junction` instead of using a SYMLINKD, to link to LOCAL resources (source). However, `directory junctions` do not allow access to resources over UNC.

    • Edited by mbrownnyc Friday, November 15, 2013 2:37 PM
    Friday, November 15, 2013 2:09 PM
  • It will be useful, in these particular case, to check the configs in this article:

    http://sourcedaddy.com/windows-7/how-to-create-symbolic-links-to-shared-folders.html

    • Local Link To Local Target Enabled by default, this allows local symbolic links to targets on the local file system.
    • Local Link To Remote Target Enabled by default, this allows local symbolic links to targets on shared folders.
    • Remote Link To Remote Target Disabled by default, this allows remote symbolic links to remote targets on shared folders.
    • Remote Link To Local Target Disabled by default, this allows remote symbolic links to remote targets on shared folders.

    Tuesday, December 16, 2014 7:39 PM
  • I'm facing the same problem:

    "FileServerA" has symlink to "FileServerB", both 2012 servers.

    If I browse through the symlink on FileServerA or FileServerB, all is fine. But windows clients (Servers, Windows 7 and Windows 10) can't browse throug the symlink: "the symbolic link cannot be followed because its type is disabled".

    I don't undestand why the question raised by Matt Brown are not answered as they are so important!

    Is there anyway to set the CIFS server on FiIleServerA to follow Symlink for clients?

    I can see here (https://superuser.com/questions/343074/directory-junction-vs-directory-symbolic-link) that by default the system does not follow the symlink on remote volumes, any chance to change the default behavior.

    Or is there a new feature in Windows 2016 that could to the job better that symlink? I realy need to organize folders structure without limitations of relative/absolute path!

    PS: Junction are not revelant as files are on a remoter server

    PPS: A actually use shortcuts (.lnk), but webdav clients like iPads don't understand them.

    Wednesday, September 13, 2017 1:04 PM