From Windows, under the path \\myfiler\vol1\down\tree\, mylink appears as a directory, and its Properties have the DFS tab present, which shows the Referral list with Path = \\myfiler\vol1, Active = Yes, and Status = Okay. However, when I click on the mylink folder, I get a Windows error popup stating "\\myfiler\vol1\down\tree\mylink refers to a location that is unavailable. It could be on a hard drive on this computer...", etc.
I'm guessing there is something wrong with my widelink syntax in symlink.translations. Can someone point me in the right direction here? Note that the NFS and CIFS shares are at the volume level, i.e. /myfiler/vol1, \\myfiler\vol1, and the symlink is "down the tree", i.e. down several levels of subdirectories.
Sorry for posting this in multiple locations, I should have started a new discussion here to begin with.
I think your suspicion is correct about the widelink logic. The first argument to "Widelink" statement is not the path of the filer that physically contains the symlink as you have it now, but it should be the target unix path as referenced by your symlink target that you wish to assocate with a target CIFS path.
I assume widelinks are enabled on the source share? Does the syntax below work? Sometimes if you wait a while it just works because of cache/timeouts... I would reboot a client and run with the exact paths...you can also use partial paths if multiple directories to link to, but the path below should work based on your output in the post.
This change causes an interesting result for me...now when I navigate to \\myfiler\vol1\down\tree\mylink, it appears to take me into a folder named 'mylink', but the content is the same as the parent mylink, including mylink; if I click on that copy of mylink, I now appear to be in \\myfiler\vol1\down\tree\mylink\mylink, and the content is again the same as that of the original \\myfiler\vol1\down\tree...the same pattern repeats no matter how far I go...my displayed path keeps adding another mylink folder, but the contents of the folder I'm in remain the same.
Confirming - yes, widelinks are enabled on the source share, and not on the target share.
I'm curious about the basic reversal in your example - in the various docs and discussions I've explored on the subject of widelinks, the source share (where the symlink resides) is on the left, and the target share (where what the symlink points to resides) is on the right; but in your example, the target is on the left, source on the right. Did you mean I should try
Sorry I never got back to update this with the final results here - it turned out that your suggestion was indeed correct, I'm not sure at this late date why it didn't work the first time I tried it. In any case, tech support took another month to arrive at the same suggestion you gave here, and at that point it did work.
In retrospect, the failure when I initially attempted your suggestion may have been due to the order of things in the symlink.translations file - there is a "map" entry in there for the source volume to its CIFS share that preceded the widelink entry I was adding at the bottom of the file. I later moved the widelink entry above the map entry but didn't go back and retry your suggestion.
So, belated thanks to you for finding the correct answer! Wish I'd understood the whole thing better the first time.