Network and Storage Protocols
Network and Storage Protocols
Solved! See The Solution
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.
So in your example given:
cd /myfiler/vol1/down/tree
ln -s /myfiler/vol2/down/tree/target_directory mylink
the syntax I would try is:
Widelink /myfiler/vol2/down/tree/* \\myfiler\vol2\down\tree\*
Do you have a CIFS share defined for vol2?
Make sure that you can access \\myfiler\vol2\down\tree\target_directory\ using CIFS.
Srinivas
Thanks for the idea...I need all the help I can get
Yes, the CIFS share for vol2 is working fine, and I can navigate down the tree into target_directory if I connect to that share.
I can even expand the folder structure in Windows Explorer and see both shares as branches of the same 'myfiler' tree, contradicting the error message saying the location is unavailable.
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.
So in your example given:
cd /myfiler/vol1/down/tree
ln -s /myfiler/vol2/down/tree/target_directory mylink
the syntax I would try is:
Widelink /myfiler/vol2/down/tree/* \\myfiler\vol2\down\tree\*
Thanks for the reply...I tried your suggestion and it hasn't changed the end result, unfortunately. I'll open a case with Tech Support, I'm getting nowhere on this.
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.
/myfiler/vol2/down/tree/target_directory\* \\myfiler\vol1\down\tree\*
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
widelink /myfiler/vol1/down/tree/* \\myfiler\vol2\down\tree\target_directory\*
Just to clarify what I'm trying to accomplish: my goal is to have navigation to \\myfiler\vol1\down\tree\mylink follow this symlink over to \\myfiler\vol2\down\tree\target_directory.
Thanks for your input - I've opened a case with tech support, waiting to hear back from them...once I do get a solution, I'll post it here.
The source path should be "/vol/vol1/down/tree/*".
Srinivas
Thanks, Srvinivas, but that doesn't change the error. I've only seen the "/vol/<volume name>/" syntax in map entries in symlink.translations, not in widelink entries.
Doug
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.