Consider the issues in this section when planning migration for NSS volumes.
There is no change in format between junctions created on NSS volumes on NetWare and those created on NSS volumes on Linux. The junctions that are created on a NetWare NSS volume continue to work if that volume is later mounted on Linux, and vice versa.
DFS on Linux requires the NCP™ protocol for the junction’s server because Samba and AFP do not support DFS junctions. For NSS volumes that contain junctions, NCP Server must be running on the Linux server, and users must access the junction via the Novell Client™. An NSS volume on an OES 2 Linux server running Samba can be the target of a junction that resides on an NSS volume on a NetWare CIFS server.
In an NCP environment, junctions can point to the root of a target volume or to a subdirectory on it. For junctions pointing to subdirectories, users must use the latest version of the Novell Client in order for junctions to work.
In a CIFS/Samba environment, junctions can point to the root of a target volume, but not to a subdirectory on it.
If you move devices with NSS volumes cross-platform, make sure your migration plan considers the following caveats:
DFS Support for Remounting Shared Volumes on Different Servers
DFS Support for Remounting Unshared Volumes on Different Servers
Remounting NSS Volumes When Move and Split Jobs Are In Progress
Mounting an NSS Volume on a Server in the Same DFS Management Context
Mounting an NSS Volume on a Server in a Different DFS Management Context in the Same Tree
DFS supports using junctions on shared volumes when used in clusters using Novell Cluster Services™ for NetWare and Linux. Each server in the cluster must use an operating system that supports DFS, and DFS must be installed and running on each server. When the NSS volume fails over to a different node, its junctions work.
NSS supports moving non-clustered devices between servers with compatible operating platforms and access protocols. If any NSS volume on the device contain junctions, the destination server must be in the same tree in order for junctions to continue to work. In addition, the destination server’s operating system and access protocols must support DFS, and DFS must be installed and running. When the volume is mounted on the destination server, the junctions work.
If the volume is a junction target, the destination server must be in a DFS management context. It can be the same or different context as the original server. Any junctions pointing to a remounted volume are broken until the VLDB for the destination server is repaired.
You must repair the VLDB for any DFS management contexts that are affected by the relocation of the volume. For example, if the new location is in the same DFS management context, a VLDB repair updates the volume location. If the destination is a different context, the VLDB repair in the original location removes the volume information from its database, and the VLDB repair in the destination location adds the volume information to its database.
For information about updating the VLDB, see the following:
For instructions on how to move NSS devices cross-platform, see Migrating NSS Devices from NetWare to OES 2 Linux
in the NW 6.5 SP8: NSS File System Administration Guide.
DFS supports remounting NSS volumes on different servers in the same tree. DFS stores a copy of a volume’s DFS GUID in a file (called ~DFSINFO.8-P) at the root directory of the NSS volume. When a new Volume object is created in the same tree, DFS checks for the existence of the file, then writes the existing DFS GUID as an attribute for the new object. Keeping the same DFS GUID allows NSS volumes to be found in the same tree, independently of the actual DFS management context they are in at any given time.
If the NSS volume contains junctions, but it is not a junction target, then the destination server can be anywhere in the same tree.
If the NSS volume is a junction target, the destination server can be in the same or different DFS management context in the same tree.
An NSS volume cannot be remounted from a NetWare to a Linux server, or vice versa, while a or job is in progress. Wait until the move or split job is completed to attempt remounting. Early in a job’s progress, it is also possible to stop the job and delete it.
If a volume is a junction target (that is, it has junctions pointing to it), and if you mount the volume on a different server in the same DFS management context, you must run a VLDB repair so that the volume’s new physical location can be recorded in the VLDB.
If the volume is shared in a cluster, a VLDB repair should not be necessary when a volume is mounted on a different node as part of the cluster failover. The VLDB maps the location to the clustered virtual server’s IP, not to a specific node in the cluster.
For instructions on VLDB repair, see Section 9.14, Repairing the VLDB.
After changes have been made in Novell eDirectory™, run VLDB repair in the original and destination DFS management contexts. You must run VLDB repair in the original DFS management context to remove the volume entry. You must run VLDB repair in the destination DFS management context to add the volume entry. For instructions on VLDB repair, see Section 9.14, Repairing the VLDB.
DFS does not work across trees. After the migration, all junctions on the volume are broken. Junctions on the moved volume cannot point to volumes in the original tree. All junctions in the original tree that point to the moved volume are broken.
If you move all of the volumes that are involved to the new tree, you must create a new DFS management context in the new tree, wait until the VLDB is built, and then modify the target location for each of the broken junctions to point to the volumes in their new location.
The OES 2 File System Migration Tool does not consider the consequences to DFS junctions of moving data on NSS volumes. If you use the OES 2 File System Migration Tool, make sure your migration plan considers the following caveats:
If the NSS volume contains junctions, the junctions do not work if you migrate data from the NSS volume to a non-NSS volume. If an NSS volume is a junction target, junctions that point to it do not work if you migrate the data from an NSS volume to a Linux tradtional volume. The junction target volume can be migrated to an NCP volume if the NCP volume has a Volume object in eDirectory and you add an entry to the VLDB for it.
After migrating an NSS volume to an NSS volume on a different server in the same management context, you must run VLDB repair for the DFS management context. This updates the VLDB with the new physical location of the volume. For instructions on VLDB repair, see Section 9.14, Repairing the VLDB.
In a DFS environment, we recommend that you use the DFS or tasks to migrate data from the NetWare server to an OES 2 Linux server. This is an NSS to NSS migration that avoids breaking junctions and automatically updates the VLDB. For information about moving and splitting NSS volumes, see Section 5.4, Migrating NSS Volumes with the DFS Move Volume or Split Volume Task.
After migrating an NSS volume to an NSS volume to a server in a different DFS management context, you must run VLDB repair in the original DFS management context to remove the volume entry. You must run VLDB repair in the destination DFS management context to add the volume entry. For instructions on VLDB repair, see Section 9.14, Repairing the VLDB.
DFS does not work across trees. After the migration, all junctions on the volume are broken. They cannot point to volumes in the original tree. All junctions in the original tree that pointed to the volume are broken.
If you move all of the volumes that are involved to the new tree, you must create a new DFS management context in the new tree, wait until the VLDB is built, and then modify the target location for each of the broken junctions to point to the volumes in their new location.