none
The create operation stopped after reaching a symbolic link

    Question

  • I recently deployed symlinks in a DFS file share deployment (symlink /D). I started receiving "The create operation stopped after reaching a symbolic link" on some client machines. I am not able to find any information on what this error actually means or what should be done to remedy it. Does anybody have any suggestions on possible solutions or additional troubleshooting steps I should take?

    The create operation stopped after reaching a symbolic link

    Environment:

    • Windows 7 x64 Clients
    • Windows Server 2008 x86 and Windows Server 2008 R2 file share using DFS folder Targets (2) and DFSr replication (2) (although the error started before I created additional folder targets, but after I enabled folder replication.)
    • I've only been able to reproduce the error with a few clients connecting to the Windows Server 2008 x86 Server.
    • The connection is over a WAN link

    Regards

    Thursday, April 12, 2012 10:22 AM

Answers

  • I have uncovered the cause of this particular error in my environment:

    My error is related to SMBv2 (which supports symbolic links.) This error is occurring on endpoints which are deployed with a Riverbed Mobile Client with the option "Enable SMBv1 Backwards Compatibility Mode" turned on, which basically forces any CIFS connections to use SMBv1. This in essence "breaks" SMBv2 and thus the proper functioning of Symbolic Links. I would assume this would be a similar underlying issue when a Windows XP client tries to access a Symbolic Link.

    Obviously, my original Environment was lacking in mentioning the Riverbed Mobile Client and I apologize for this omission.


    • Marked as answer by tstock_sjc Saturday, February 02, 2013 12:12 AM
    • Edited by tstock_sjc Saturday, February 02, 2013 12:15 AM Update info
    Saturday, February 02, 2013 12:12 AM

All replies

  • Hi,

    As you are trying to create symbolic link in DFS namespace, I would like to know if it is accept to do this in DFS management by creating subfolders under namespace, such as creating \\domain.com\namespace\subfolder1, subfolder2 etc. You could set folder target for these subfolders.

    For your current issue, I would like to know the exact server clients (in problem) are connected. You may need to monitor the whole process when clients trying to access the file. Symbolic link will not be replicated by DFSR, so you may receive error if connected to the wrong server target.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    Friday, April 13, 2012 7:27 AM
    Moderator
  • In answer to your first question, that is a very interesting thought. I did look at that briefly and found it to be not realistic. Obviously, since a DFS replicated folder cannot be underneath another replicated folder, I would have to replicate each folder individually (albeit they could be in the same Replication group.) This would make management difficult, as we are talking 350+ folders currently using symlinks that would instead need to be added to the DFS namespace and then replicated. This would still leave any item that came before the replicated folders to be dealt with another way (as replication would not be possible.)

    In regards to your second question. So you think it might be possible for a client to be pointed to an active DFS target, but when the Symlink is navigated, the symlink navigation process somehow finds the non-active target? This error did occur right around the time I added a second server to the replication group (although I'm pretty sure before I enabled the new server as a target in the DFS namespace.)

    Here is an example of my Symlinks:

    DFS Namespace Path (to Symlink): \\domain.com\corp\Site\Location\Contract\Job\Logistics

    DIR command: <SYMLINKD>     Logistics [..\..\!General\Logistics\Contract\Job]

    So, the Symlink is Logistics, the link goes back 2 directories then goes under !General and back up to the target.

    I have not received the error after the first few times, however, I do have another error that is much more prevalent (suppose I should post that separate.)

    Thank you for your insight.


    • Edited by tstock_sjc Friday, April 27, 2012 6:19 PM remove link
    Friday, April 27, 2012 4:46 PM
  • I have uncovered the cause of this particular error in my environment:

    My error is related to SMBv2 (which supports symbolic links.) This error is occurring on endpoints which are deployed with a Riverbed Mobile Client with the option "Enable SMBv1 Backwards Compatibility Mode" turned on, which basically forces any CIFS connections to use SMBv1. This in essence "breaks" SMBv2 and thus the proper functioning of Symbolic Links. I would assume this would be a similar underlying issue when a Windows XP client tries to access a Symbolic Link.

    Obviously, my original Environment was lacking in mentioning the Riverbed Mobile Client and I apologize for this omission.


    • Marked as answer by tstock_sjc Saturday, February 02, 2013 12:12 AM
    • Edited by tstock_sjc Saturday, February 02, 2013 12:15 AM Update info
    Saturday, February 02, 2013 12:12 AM