i've been reaseraching ways to implement a single namespace CIFS environment with netapp and it looks like the way this should be done is with Widelinks. I have however been looking at a configuration guide or setup steps that show the full process of doing this and so far i cant find anything that works. everything seems to be using NFS or nix client to create the link which i would prefer to not do - as this would prove a headache if we want to quickly add another share/symlink
Can anyone help.
our environment is a HA pair of .7 FAS controlers.
i would like to know how to configure the following
Poor mans DFS Here is an example from my laptop and VSIMs below and also some copy/paste from NetApp docs and kbs that cover the topic very well...a little tricky but easy once you get the example processed a couple times. 7-Mode example so different commands for cDOT but can be done in cDOT too. Note that relative path links follow automatically per below with no symlink entry. Also if you can use windows dfs that would be better with a gui to manage and replication. I don't know of a windows tool to create the symlink (I used my OSX nfs mount to do that) but remember someone posting a a tool somewhere that created links... or worst case you could use the ONTAP systemshell, sudo mount and run the ln command from bsd... not ideal since support for systemshell isn't for us to do this but if you don't have a linux machine or any unix system that can mount that would be a workaround.
Symlink file created by an nfs client can be used as a cifs widelink to redirect symlinks on a filer...using DFS on the cifs client. It can be a share on the same filer or another filer. A poor mans name space without a dfs server... a little tricky, but a few experiments and it works great... matching the unix symlink to a translation file on the filer to the actual cifs share target is the key that puts it together.
ABSOLUTE SYMBOLIC LINKS ONLY!
RELATIVE LINKS FOLLOW AUTOMATICALLY....no mapping needed... and no widelink option set on the share itself...handled by "options cifs.symlinks.enable on" for relative paths... default is on.
Note: CIFS client users who follow symlinks to resources outside the link’s share do not work,
unless the cifs share -nosymlink_strict_security option has been specified for the source
Widelink Time To Live
options cifs.widelink.ttl # timeout for widelink updates... default is 600 (10 minutes)
### Show links and cd to links to make sure they work.. note: for a widelink to work, the symlink doesn't have to be valid, but it's nice if they do work and go to the same place. The widelink just takes the value of the links target as the mapping value to a cifs share.
scott-gelbs-macbook-pro:/ root# ls -l /mnt/wideroot
*** Now... for CIFS to use this we have to create /etc/symlink.translations on the filer.
*** THIS IS KEY TO LINK THE symlink target to the cifs share local or remote... add the * at the end of the link and share or it won't work.. The first value is the value in the link (doesn't have to be valid) but the second value must be a valid cifs share
net use w: \\192.168.150.200\wideroot # map source only...then go to local_link and remote_link.. dfs referrals are used... the symlinks look like directories... a poor mans namespace without a dfs server...
na_symlink.translations - Symbolic link translations to be applied to CIFS path lookups
When the CIFS server encounters a symbolic link (also called a "symlink," or "soft link"), it attempts to follow the link. If the symlink target is a path that starts with a "/", the filer must interpret the rest of the path relative to the root of the file system. On the filer, there is no way to know how NFS clients (which must be used to create the symlinks) might have mounted filesystems, so there is no reliable way to follow such absolute, or "rooted" symlinks. The symlink.translations file enables you to use absolute symlinks by mapping them to CIFS-based paths.
The entries in this file are similar to the httpd.translations file. There are two formats for file entries, as follows:
Map template result
Widelink template [@qtree] result
Any request that matches template is replaced with the result string given. Note that the result path for a "Map" entry must point to a destination within the share to which the client is connected. This is because the client has only been authenticated to that share; therefore access is limited to the same share for security reasons. A result path for a "Widelink" entry may point anywhere, thus the name "wide symlink" or widelink for short. Widelinks have these limitations-- the filer share on which the symlink resides must be enabled for wide symlinks, the CIFS client must support Microsoft's Dfs protocol, and the destination must be able to function as a Dfs leaf node. By using Dfs requests, the filer causes the client to authenticate with the destination and thus enforces security. To enable a filer share for "wide symlinks", use the "cifs shares -change" filer console command.
Both templates and results might (and usually do) contain wildcards (a star "*" character). The wildcard behaves like a shell wildcard in the template string, matching zero or more characters, including the slash ("/") character. In the result string, a wildcard causes text from the corresponding match in the template string to be inserted into the result.
The entries are examined in the order they appear in the file until a match is found or the lookup fails.
This example maps absolute symlinks that start with "/u/home" to go to the filer path "/vol/vol2/home". Also, symlinks starting with "/u" go to "/vol/vol0". Note that you should put the more restrictive entries first to avoid premature mapping since the matches are done in order.
# Example Map symlink translations
Map /u/home/* /vol/vol2/home/*
Map /u/* /vol/vol2/*
The next example maps absolute symlinks that start with "/u/docs/" to go to the filer path "\\filer\engr\tech pubs". Note that widelink result paths use CIFS pathname syntax (backslashes are separators, spaces in path components are allowed, and so on).
# Example Widelink symlink translation
Widelink /u/docs/* \\filer\engr\tech pubs\*
The next example maps absolute symlinks that start with "/u/joe". Note that depending on how NFS mounts are set up, it is possible that there could be several absolute symlinks pointing to "/u/joe" which need to have differing destinations. The qtree in which a symlink resides can optionally be used to distinguish destinations. Thus, following an absolute symlink starting with "/u/joe" in qtree /vol/vol1/mixed takes the client to "\\filer\home\joe", while symlinks in other qtrees take the client to "\\filer\test tools\joe".
Note that there is no theoretical reason why a wide symlink can't point to another filer or indeed any NT server, though it may be difficult to imagine the translated link making sense to the Unix client which created the original symlink.
I stand corrected - check out mklink.exe. I couldn't get it to work, but I didn't spend too much time on it. It also looks like there may be some tools out there that will let you create symlinks from within windows.
Ok, Thanks for the assistance. i'm not a major nix user so didnt want to go down the route of having a nix client, or finding nix tools for windows to do this. i could also not get mklink or ln.exe or the ntap_symlink tools to work.
however i do belive i have got it to work after discovering the powershell toolkit cmdlet New-nafileSymLink. these were the steps i took to get a folder in a share redirect to another folder in another share on another controler
I created the following share 'share' in the following location controler A /vol/ShareVol/ShareQt/
I created the following share 'share' in the following location on controlerB /vol/ShareVolR/shareQtr/
enable widelinks on 'share' on controlerA
user powershell command new-NaFileSymLink -Symlink /vol/ShareVolR/ShareVolQtr/foldertolink -path /vol/ShareVol/ShareQt/LinkName
i can now unc to \\ControlerA\Share\ and see a folder called 'LinkName' which takes me to 'FoldertoLink
This works for redirecting folders in a share to another share/folder. however is it possilbe to create a symlink so \\controlerA\Share links direct to \\controlerB\Share - so that one symlink is created for a share and all data within that is automaticaly created/edited on the destination. I hope i made that last part clear. one share we would like to link has a large number of subfolders at the root level, and new folders are automaticaly created on that root level, we would then need to manualy move and recreate the symlink when those new folders are created.
Good find on PowerShell. More customers are using WFA and PowerShell now and very useful. I don’t know of a way to get the path to go straight to the B target without going to the target share directly. The namespace provides the links in it to go to…unless another script or path the user is given pathA\pathB<file:/// pathA\pathB> for example.