This mentions Release 4.3. However, I'm on 5.1D4 and does this work ? In a word : NO.
Any "bugs" of which I am unaware not withstanding... no! The CIFS symlink following mechanism should work in a Data ONTAP 5.1 release just as it did in the 4.3 releases. So let's see what might be up...
I've got an F520 running release 5.1D4. I've got a problem with reading
Unix
soft links on NT.
Symbolic links. OK...
NetApps Inc. say that soft links only work on NT within one quota tree. That is a difficult thing t live with, but I suppose I'll have to.
The limitation that exists with the symlink following mechanism is that the encountered link must point to a location in the filer's file system that resides under the same *share* that the client encountering the link originally connected to in order to be able to hit the link in the first place (if you see what I'm saying? :-)). The "problem" is a rather fundamental one. If a link points to a location on the filer that is outside of the scope of the share being accessed from a client, our software has no way of telling the client to disconnect itself from the existing share and reconnect to another that could *possibly* allow it to go to the destination (even if one existed). Simply taking the client to the destination without regard to share security would be a "well iffy" piece of behavior from the security perspective.
As for the quota tree limitation you specifically mention, yes, I believe that might be a new thing in 5.1, but there is a good reason for it and it isn't actually that much of a "new restriction" in practice. The good reason for it is that now our qtrees can have different security styles associated with them. You only get to inform a client about the security of the file system it is connecting to (FAT or NTFS) at connect time, so taking a client from a FAT file system (which actually has UNIX security on it in our case), to an NTFS file system would definately constitute a problematic situation in the eyes of the protocol. There's just no mechanism to cleanly handle such a transition.
Oh... and the reason that it isn't actually that much of a (new) restriction is that qtrees are always rooted in the root directory of a volume, so the only share that a client could possibly connect to that would allow inter-qtree jumps while still obeying the "in the same share" rule, would be the C$, D$, E$ etc, etc... administrative shares, which aren't normally used by ordinary users.
I can make soft links with relative pathnames work OK, but what about
links
with absolute pathnames ? On the NOW NetApp site, I found a sysadmin man page mentioning the /etc/symlink.translations file, which is apparently a way to make this work.
It's a way to make *something* work, but not inter-share jumps. From a UNIX client you may have created symlinks that a filer could not possibly follow, because they point to locations that are not actually on the filer. A UNIX client can follow these links elsewhere because it is an NFS client. A filer can't, because it is not. The symlink translation mechanism lets you make a copy of the target data somewhere that *is* on the filer (manually), and then automatically translate the existing symlinks to hook a Windows client over to it.
Make sense?
Keith