Using DFS for Centralized Access to Multiple NFS Servers

Using DFS for Centralized Access to Multiple NFS Servers

Lately, we have seen customers who are trying to utilize DFS to publish NFS shares from a single DFS server to centralize the access for the clients.

This has several benefits. It removes the problem of keeping a note of what NFS server is hosting a given NFS share and also the need to mount them. While you can still map a DFS link to a drive letter, I think it would be easier to browse to the DFS server using UNC and use the shares.

So, the DFS capability was added to SFU 3.0/3.5 via hot fix in KB837197 and this functionality exists in the NFS clients that ship with W2K3 R2 and later Windows releases.

The requirement to be able to create a DFS Link on a DFS server and to be able to access from a DFS client is that these machines should have the NFS client installed. Another requirement is about the identity mapping - all such systems should be using the same information store to match the Windows and UNIX identities.

With these things in place, you can go ahead and create a DFS root. You can create a single DFS root for all UNIX-based NFS shares that you want to publish using DFS or you can create multiple DFS roots depending upon on your requirement and design.

Next step would be to add a DFS link that is UNC path to NFS share on NFS server. We recommend that you should avoid using multi-path NFS shares (like /usr/local or /export/home etc) here. If you must use multi-path share, you will have to first mount them on a drive letter on the DFS server to avoid any service disruptions.

Once the link has been added and verified, your clients are pretty much ready to access it. Just browse to your server-based or domain-based DFS namespace and start using them.

If you have symlinks on your NFS shares or if you are not sure about them - there're some registry settings that need to be created and modified so that symbolic links work as expected.

The following registry entries should be added on the DFS servers -

• MountSymlinkDfsMaps - This entry takes care of resolving the target of the symlink when they are accessed from a DFS link. This is a Multi-String (MULTI_SZ) type and the values in this entry should in the following format -
  /NFSShare:\\DFSServer\DFSRoot
  This registry entry should be created at HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Client for NFS\CurrentVersion\Users\Default\Defaults
• DisplayAllLinks - This is REG_DWORD type and unless this entry is set to 1, any remote or unresolved symbolic links will not be displayed on the DFS clients.
  This registry entry needs to be present at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Client for NFS\CurrentVersion\Default
• MountSymlinkTargetShare - This also is a REG_DWORD and this allows the MS NFS client to traverse the target of a symbolic link if the target is not on the same NFS share.
  This registry entry should be created at HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Client for NFS\CurrentVersion\Users\Default\Defaults

Of the above, only the MountSymlinkTargetShare registry entry needs to be present on the clients so they can access the symlinks that point the targets on a different NFS share. You can read more about the above registry entries in KB837197.

Note: Symbolic links that point to an absolute path do not work over NFS and they must be recreated with relative target paths.