Managing NFS and NIS, 2nd Edition - Mike Eisler [69]
Resolving symbolic links in NFS
When an NFS client does a stat( ) of a directory entry and finds it is a symbolic link, it issues an RPC call to read the link (on the server) and determine where the link points. This is the equivalent of doing a local readlink( ) system call to examine the contents of a symbolic link. The server returns a pathname that is interpreted on the client, not on the server.
The pathname may point to a directory that the client has mounted, or it may not make sense on the client. If you uncover a link that was made on the server that points to a filesystem not exported from the server, you will have either trouble or confusion if you resolve the link. If the link accidentally points to a valid file or directory on the client, the results are often unpredictable and sometimes unwanted. If the link points to something nonexistent on the client, an attempt to use it produces an error.
An example here helps explain how links can point in unwanted directions. Let's say that you install a new publishing package, marker, in the tools filesystem on an NFS server. Once it's loaded, you realize that you need to free some space on the /tools filesystem, so you move the font directory used by marker to the /usr filesystem, and make a symbolic link to redirect the fonts subdirectory to its new location:
# mkdir /usr/marker
# cd /tools/marker
# tar cf - fonts | ( cd /usr/marker; tar xbBfp 20 - )
# rm -rf fonts
# ln -s /usr/marker/fonts fonts
The tar command copies the entire directory tree from the current directory to /usr/marker (see the manpage for tar(1) for a more detailed explanation).
On the server, the redirection imposed by the symbolic link is invisible to users. However, an NFS client that mounts /tools/marker and tries to use it will be in for a surprise when the client tries to find the fonts subdirectory. The client looks at /tools/marker/fonts, realizes that it's a symbolic link, and asks the NFS server to read the link. The NFS server returns the link's target — /usr/marker/fonts — and the client tries to open this directory instead. On the client, however, this directory does not exist. It was created for convenience on the server, but breaks the NFS clients that use it. To fix this problem, you must create the same symbolic link on all of the clients, and ensure that the clients can locate the target of the link.
Think of symbolic links as you would files on an NFS server. The server does not interpret the contents of files, nor does it do anything with the contents of a link except pass it back to the user process that issued the readlink RPC. Symbolic links are treated as if they existed on the local host, and they are interpreted relative to the client's filesystem hierarchy.
Absolute and relative pathnames
Symbolic links can point to an absolute pathname (one beginning with / ) or a pathname relative to the link's path. Relative symbolic link targets are resolved relative to the place at which the link appears in the client's filesystem, not the server's, so it is possible for a relative link to point at a nonexistent file or directory on the client. Consider this server for /usr/local:
% cd /usr/local/bin
% ls -l
total 1
lrwxrwxrwx 1 root bin 16 Jun 8 1990 a2ps -> ../bin.mips/a2ps
lrwxrwxrwx 1 root bin 12 Jun 8 1990 mp -> ../bin.mips/mp
If you mount just /usr/local/bin from this server, you will not be able to use any of the executables in it unless you have them in the directory /usr/local/bin.mips.
Using symbolic links to reduce the number of directories in a pathname is beneficial only if users