Tech Tips on Symbolic Links for DiskAccess and AccessNFS Gateway

This document will provide technical tips on symbolic links with respect to the DiskAccess and AccessNFS Gateway products. It is written from a support analyst’s point of view and deals primarily with the necessary steps that a user needs to take so as to be able to access symbolic links located on an NFS server.

Section 1: Symbolic Link General Information

A symbolic link is a file that points to either a file or directory. The file or directory that a symbolic link points to is often called the target of the symbolic link. The symbolic link target can be on the same file system as the symbolic link or a completely different file system. The other file system could be one located on a NFS client system that wishes to access the symbolic link; however, such a scenario is often rarely encountered. Most often the target of a symbolic link with reside on the same NFS server as the symbolic link but just on a different file system.

Perhaps an easier way to understand the concept of a symbolic link is to think of it as just another name for the target of the symbolic link. An analogy would be a person whose name may be Richard but is often referred to as Rick. Consequently Rick is a symbolic link to the person named Richard.

When either DiskAccess or AccessNFS Gateway encounters a symbolic link residing on the NFS server, it can optionally attempt to resolve the symbolic link to the link’s target or not resolve the link but simply display the name of the symbolic link. In order for DiskAccess or AccessNFS Gateway to resolve a symbolic link, the target of the symbolic link must reside within the NFS server’s exported directories and be accessible by the DiskAccess or AccessNFS Gateway computer.

Note

DiskAccess and AccessNFS Gateway performance can be affected when enabling support for resolving or displaying symbolic links.

Section 2: Steps to Configure Symbolic Links

The following is a step-by-step process that a user should take if they wish to view symbolic links that reside on an NFS server. By default, symbolic links are not resolved when running DiskAccess or AccessNFS Gateway on Windows NT or Windows 2000. Consequently a symbolic link will not be displayed to the user of DiskAccess or AccessNFS Gateway unless steps are taken to enable the products to make the symbolic links viewable. The necessary steps to take will be explained later in this document.

DiskAccess loaded on a Windows 95 or Windows 98 system will automatically display symbolic links that can be resolved. However under special circumstances, the user may need to create registry entries to view special symbolic links. The necessary registry entries will be explained later in this document.

The steps taken will assume there is a symbolic link on the NFS server that is not being displayed in either the Windows Explorer or from the DOS Command window with the aid of the ‘dir’ command. The assumption that the NFS server is a computer running a form of UNIX or Linux is also made. Lastly, the user will need to be knowledgeable with the NFS server’s operating system.

Step 1. Verifying Symbolic Links on the NFS Server

Verify that the file or directory that currently cannot be viewed is in fact a symbolic link. While logged on to the NFS server perform the ‘ls –ls’ command on the exported NFS directory.

The listing from Figure 1 indicates that there are two symbolic links. The symbolic links are named “1.2” and “bbtwslink.txt”. The target of the symbolic links are “/usr/test2/brix4/REL/BrxLUG/1.4” and “/mnt1/testlink.txt” respectfully.

From Figure 1, the user can identify that the files are symbolic links by a number of ways: First, notice that the “l” at the far left of the permission field indicates that it is a link and second, the “@” at the end of the filename indicates that it is a link. Lastly, the arrow “->” is another indication of a link, it points to the target name or destination of the symbolic link. The syntax to identify a file as a symbolic link may differ from one NFS server to anther.

Note

It is imperative that the targets of symbolic links are defined with absolute path names, as shown in Figure 1, as opposed to relative path names.

If relative path names are used as the targets of symbolic links, the only way DiskAccess and AccessNFS Gateway can resolve the relative path is for it to be within the same NFS exported file system as the symbolic link.

As an example, assume that an NFS server may be exporting the directory /usr/tmp. The /usr/tmp directory may have two subdirectories named “betty1” and “betty2”. Assume that the “betty1” directory has the following symbolic link:

1 lrwxrwxr-x 1 betty users 9 Dec 26 09:56 symlink.txt -> ../betty2/real.txt

DiskAccess and AccessNFS Gateway will be able resolve the target of the symbolic linked file, symlink.txt, because the file is within the mounted directory /usr/tmp.

If by chance the symbolic link’s target was outside the NFS exported directory structure as in the following,

1 lrwxrwxr-x 1 betty users 19 Dec 26 09:56 symlink.txt -> ../../real.txt

DiskAccess and AccessNFS Gateway would not be able to resolve the target’s path. An attempt to resolve the path would fail because the target file, “../../real.txt”, is located at /usr/real.txt and /usr was not being exported by the NFS server.

Figure 1 illustrated characteristics of symbolic links so as to be able to verify them at the NFS Server, as well, as determining names and absolute paths of targets. The next step would be to determine if the target paths exist on the local NFS server or perhaps on a different NFS server. To help make the determination, the ‘df’ utility can be used.

The ‘df’ command lists all mounted file systems, including the file system physical names and other details. See Figure 2 as an example of the output of a ‘df’ command.

From Figure 2 notice there are three mounted file systems on the NFS server. The names of the file systems are “/”, “/usr”, and “/mnt1”.

Without going into details, the “/” and “/usr” file systems are associated to the disks located on the NFS server. The “/mnt1” file system is associated from another NFS server’s exported file system; namely a server whose name is “sunlab1.b8.ingr.com.” and whose exported NFS file system is named “/TeSt”.

In our working example from Figure 1, DiskAccess and AccessNFS Gateway will be able to display and resolve the symbolic link named “1.2”. However in order to resolve the symbolic link “bbtwslink.txt”, a symbolic link configuration file will be needed on the DiskAccess or AccessNFS Gateway system.

Step 2. Configuring Symbolic Links for DiskAccess or AccessNFS Gateway on Windows NT and 2000

The symbolic link configuration on DiskAccess is located at Control Panel - DiskAccess. The DiskAccess Property Sheet is used to modify the default configuration; however, the configuration can be altered at the time of mounting the NFS server’s exported directory.

AccessNFS Gateway offers Client and Server access to NFS resources; therefore, symbolic links must be configured separately for Client and Server. To configure symbolic links for Clients, go to Start – Programs – AccessNFS Gateway – Universal Options. To configure symbolic links for the Gateway Administrator, go to Control Panel – AccessNFS Gateway.
The symbolic link configuration is accomplished with the “Symbolic Links” tab sheet.

In order for the products to be able to display symbolic links, the “Resolve Symbolic Links” option must be selected. With this option selected, any symbolic link that can be resolved will be displayed. If the symbolic link cannot be resolved for whatever reason, then the link will not be displayed unless the “Display Unresolvable Symbolic Links” option has been enabled.

Although all symbolic links will be displayed when the “Resolved Symbolic Links” and “Display Unresolvable Symbolic Links” option are enabled, only links that have been resolved will be available to the user to manipulate the data. Manipulation of data being defined as reading data, writing new data, or deleting of data. There is no way to tell the difference between resolved symbolic links and unresolved symbolic links from the NFS client computer.

A symbolic link cannot be renamed or deleted from the NFS client computer unless the “Allow Rename and Delete on Symbolic Links” option has been selected. This option should be used with caution. If a symbolic link is deleted, then it cannot be recovered. Furthermore, if a symbolic link is renamed, the link will be severed and the result will be an ordinary file.

As Figures 1 and 2 illustrate, the target of a symbolic link can be located on another NFS server’s exported directory. In this special event, DiskAccess and AccessNFS Gateway will need to be configured to refer to a configuration file. The name of the configuration file is to be entered in the edit box titled “Symbolic Links File Name”. If this special event is not present, then the configuration file is not needed.

The symbolic link configuration file contains information taken from the ‘df’ results. This file provides the necessary information about the mount point, where the mount point is the directory name where the NFS server mounts another NFS server’s exported directory, also known as a partition point or reparse point.

This symbolic link configuration file, an ASCII file, must be manually created and it must abide by the specific syntax,

/< mount point name> /<NFS Server Name>/NFS Export Name

Using the data in Figures 1 and 2 and assuming the name of the NFS Server, which the DiskAccess or AccessNFS Gateway computer is mounting, is named sunlab1.b8.ingr.com, the following would be the syntax used:

/mnt1 /sunlab1.b8.ingr.com/TeSt

When either DiskAccess or AccessNFS Gateway encounters the symbolic link named “bbtwslink.txt” as defined in Figure 1, it will search for the name of the directory path in the configuration file. In the example, the name of the directory path is “/mnt”. Since “/mnt” is defined in the configuration file, then the product will substitute sunlab1.b8.ingr.com/TeSt for the /mnt directory path and attempt to create a UNC connection to \\sunlab1.b8.ingr.com\TeSt\bbtwslink.txt

Note

Each line in the symbolic link configuration file must end with a carriage return. A common problem is the last line of the configuration file may not have a carriage return.

Step3: Configuring Symbolic Links for DiskAccess on Windows 95 or Microsoft Windows 98

The DiskAccess Control Panel application running on a Microsoft Windows 95 or Windows 98 (W9X) system is different than the Control Panel application running on a Microsoft Windows NT or Windows 2000 (NT/W2K) system. DiskAccess running on W9X does not provide the user interface necessary to manipulate how symbolic links are handled.

DiskAccess on W9X will automatically allow the user to view symbolic links that can be resolved. If the symbolic links on the NFS server have targets that are other NFS server’s exported resources, then configuration information needs to be provided. If the configuration information is not provided, DiskAccess will assume the target of the symbolic link resides on the NFS server.

Unlike the NT/W2K version of DiskAccess that uses a local configuration file, DiskAccess on W9X uses the registry to configure symbolic links. Consequently the user will need to modify the registry. Prior to making any changes to the registry the user should create a backup of the registry. Furthermore, extreme caution should always be taken whenever modifying the registry.

Using an application such as the Microsoft utility named regedit.exe, create the registry key,

HKEY_LOCAL_MACHINE\SOFTWARE\SSC\DiskAccess\Default\Symbolic Links

When creating the registry key, care needs to be taken with respect to the capitalization and spaces. For instance the Symbolic Links registry key has a capital “S” in the word “Symbolic”, a capital “L” in the word “Links” and a space in between the two words.

After the “Symbolic Links” registry key has been established, create an entry of type “String Value” also known as “REG_SZ” for the key. The name of the entry will be the name of the mount point. The “Value Data” of the entry will be the IP address of the NFS server and its exported directory that is referenced in the symbolic link’s target. For example:

Value	Data
mnt1	\\216.206.131.39\home
mnt2	216.206.131.39:/export/home

Notes

Slashes cannot precede the name of the mount point.
The servers IP address must be used instead of its proper name.
The syntax used on W9X systems is different than the syntax used on NT/W2K.

Section 3: Troubleshooting Symbolic Link

Other problems that can occur when attempting to resolve symbolic links are:

The computer running DiskAccess or AccessNFS Gateway may not have access to the exported directory defined in the configuration file.
The named server in the configuration file may no longer export the named directory.
The named server in the configuration file may no longer be on the network.
The mount point may differ in case.
Mount points must be unique. You cannot have more than one mount point with the same name in a configuration file.