- To aggregate disparate parts of the file system.
- As a convenience, similar to a shortcut in the Windows environment.
- To access data outside of a cluster. For example, a symlink can point to data in another server in a server farm or a non- server.
- Relative symlinks contain a path relative to the symlink itself. For example, . ./dst is a relative symlink.
- Absolute symlinks contain a path relative to the root of the file system on the NFS client that created the symlink (not relative to the root of the server's file system). For example, /mnt/datadir/dst is an absolute symlink.
When accessing the file system through NFS, the server fully supports symlinks. NFS/UNIX clients assume that files marked as symbolic links contain a text pathname that the client can read and interpret as an indirect reference to another file or directory. Any client can follow a symlink, but accessing the target file (or directory) still requires permission.
- For relative symlinks, the link can be followed because the server can follow the path from the link itself.
-
For absolute symlinks, the server does not have access to the root of the file system on the NFS client that created the link, so it cannot follow the link automatically.
The server provides global symlinks, which allow clients using SMB1 to follow absolute symlinks:
- If an absolute symlink refers to a file or directory in the same SMB share as the symlink, the server follows the symlink (on behalf of the SMB client) internally.
- If an absolute symlink refers to an object in a different SMB share to the symlink, the SMB client is redirected to the link's destination via the Microsoft DFS mechanism.
Note: The Microsoft DFS mechanism supports redirection only to a directory (not a file). Therefore, absolute symlinks that refer to a file (in a different SMB share) will not be handled properly by an SMB client.The link's destination may be on the same file system as the link, on a different file system within a server farm, or on a remote SMB server. To associate a global symlink with an absolute symlink, the server maintains a translation table between absolute symlink paths and global symlink paths.Note: As of release 12.2 of the NAS Platform, clients using SMB2 or later can follow relative and absolute symlinks to files on storage without using server-side symlinks.
When accessing server-side symlinks, SMB clients cannot follow some symlinks which are perfectly valid for NFS, because the storage system follows the symlink on the SMB client's behalf and presents the linked-to file instead of the symlink. In this case, in line with the behavior of Samba, the server hides the existence of the symlink entirely from the SMB/FTP client. By default, a symlink that points outside of the scope of its own share (for example, to a different file system) is not followed.
Clients using SMB2 or later can follow relative and absolute symlinks to files on storage without using server-side symlinks. The following CLI commands manage this client-side SMB2 behavior:
- smb2-client-side-symlink-handling-default
- smb2-client-side-symlink-handling-disable
- smb2-client-side-symlink-handling-enable
- smb2-client-side-symlink-handling-status
For more information about the CLI commands, see the Command Line Reference.
- For NFS clients, the server returns the content of the global symlink, allowing the client to follow the link to the destination. This means that the NFS client's mount points and the NFS exports must be set up correctly.
- For SMB clients, the server causes the client to request a symlink lookup from the local EVS translation table. Once the client requests the lookup, the server returns the destination server name, share name, and path to the SMB client, allowing it to access the destination.
Using global symlinks with SMB has a performance penalty. Therefore, global symlinks are disabled by default, but can be enabled by selecting the Follow Global Symbolic Links check box on the Add Share page (when creating the share) or CIFS Share Details page (after the share has been created).
- Table entries do migrate with the EVS. If an EVS is migrated, all of its table entries migrate along with the EVS.
- Table entries do not replicate from the EVS. When replicating data from one EVS to another, the mapping information for global symlinks is not automatically relocated, and it must be recreated in the translation table of the EVS into which the data was copied.
- Table entries do not move with a file system. If a file system is moved from one EVS to another, the mapping information for global symlinks is not automatically relocated and must be manually adjusted, except for those symlinks that are relative to a CNS tree (those symlinks do not require adjustment).
- Table entries irrelevant for symlinks that are relative to a CNS. When an EVS is migrated, no adjustment is necessary for symlinks that are relative to a CNS because, when the client follows the symbolic link, it is first referred to the CNS tree, then from the CNS tree to a real file system when the path crosses a CNS link.
- global-symlink-add
- global-symlink-del
- global-symlink-delall
- global-symlink-list
For more information about the CLI commands, see the Command Line Reference.