ONTAP Discussions

Windows client having problem following symlink to a widelink-ed folder


Hi everyone,


We have a cluster runing ONTAP 8.2 in Cluster Mode, and I am having problem making windows client to follow a unix symlink that points to a widelink properly.


What I have is:

1. wide link setting by command "vserver cifs symlink create -vserver server1 -unix-path "/VOL3/" -share-name vol_3 -cifs-path / -cifs-server -locality widelink", in which is the server1 itself.

cluster::vserver cifs symlink> show
Vserver    Unix Path       CIFS Server     CIFS Share  CIFS Path      Locality
---------- --------------- --------------- ----------- -------------- --------
server1   /VOL3/     vol_3       /              widelink
1 entries were displayed.

2. On a linux machine that can access a volume named vol_1, create a unix symbolic link to "VOL3", with command "ln -s "

➜  vol1  ln -s /VOL3/ link_vol3 
➜  vol1  ls -l
total 20
lrwxrwxrwx  1 steven  staff     6 Oct 31 19:00 link_vol3 -> /VOL3/

3. Then on a Windows 7 client, when accessing the same vol_1, it is able to see "link_vol3" as a folder and double click will open vol_3 and show content, which means the widelink is working.

4. However, if I go back to a Linux machine and create a symbolic link pointing to somewhere under "link_vol3", like this:

➜  vol1  ln -s link_vol3/test.txt vol3_test.txt
➜  vol1  ls -l
total 20
lrwxrwxrwx  1 steven  staff     6 Oct 31 19:00 link_vol3 -> /VOL3/
lrwxrwxrwx  1 steven  staff    21 Oct 30 11:14 vol3_test.txt -> link_vol3/test.txt

5. Problem is, when back to the Windows 7 client, I will see the "vol3_test.txt" as a folder, not a file or shortcut as expected, double click will show a error "Windows can't access this disc" and can not open the file.


Tried to access using Windows server 2008 and 2012, all the same.


But, above methord workes perfectly fine on another box runing ONTAP 7(only difference is the widelink were created by writing an entry to/etc/symlink.translations)


Question, has anyone met the same problem before? Is it caused by some new bug on ONTAP8? or is there any setting that can make the above linking scheme work?








This is by design. Please check the KB article below.



There are 5 important things to consider:

  • The CIFS symlink map entry needs to exist on the vserver that has the share that contains the symbolic link, not the destination.
  • The share on the vserver with the symbolic link you are mapping needs to have symbolic links enabled or set to read-only, verify with the cifs share show command.
  • The vserver will parse the contents (destination path) of the symbolic link to use for mapping, not the name of the link, nor the path of the link itself. (To see what a link points to, that is, what needs to be mapped, do an ls -l on the directory with the link, and check the destination path.)
  • Symbolic link mapping to CIFS referrals only works for directories, not for files.
  • If the only purpose of the symbolic links is to redirect, it's perfectly fine for the symbolic link destination to not be real, it can exist purely for the purpose of the map (which does need to be real).
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
Cannot find the answer you need? No need to open a support case - just CHAT and we’ll handle it for you.


If this is because widelink do not support link to files, we are having problem with directories too, so I don't think it's right behavior.


for example when we have the above widelink working, if we create a symbolic link to this directory, windows clients are still having problem accessing it:

➜  vol1  ls -l
total 20
lrwxrwxrwx  1 steven  staff     6 Oct 31 19:00 link_vol3 -> /VOL3/

➜  vol1 ln -s link_vol3 link_vol3_ln

when windows client try click the "link_vol3_ln", it will see an error:

Windows can't access this disc
The disk may be corrupt. Make sure that the disc uses a format that Windows recognize. If the disc is unformatted, you need to format it before using it.

According to documentations, even if the system do not permit links on file level, it should still permit links to directories. But it's not working properly.


Any thoughts?