Consider the guidelines in this section when planning your data migration from NSS volumes to NCP volumes by using the File System Migration Tool, or by using migration commands.
Both NSS volumes and NCP volumes use the OES trustee model for controlling access to data. If you migrate data from an NSS volume on NetWare to an NCP volume, the trustees and trustee rights are enforced.
IMPORTANT:Make sure that the trustees are also authorized NetIQ eDirectory users of the destination server.
NCP Server does not provide a user quotas feature, so NCP volumes cannot support user quotas that are set on the NSS volume you are migrating. After the data is migrated, the quotas are not enforced in the NCP volume.
After the migration, you can use Linux tools to set user quotas on the Linux POSIX file system underneath the NCP share if the Linux file system being used under the NCP share supports user quotas and the Linux file system resides on a local, iSCSI, or Fibre Channel drive. All users of the NCP volume must be LUM enabled.
NCP volumes do not support the deleted file salvage and purge that is available for NSS volumes. If you have deleted files on the NSS volume, they are not migrated. If you want to salvage deleted files, do it before you migrate the data. In addition, the Salvage (Undelete) and Purge options in the Client for Open Enterprise Server and the Files and Folders plug-in to iManager are disabled for NCP volumes on Linux file systems.
NCP volumes do not support volume encryption. If you migrate data from an encrypted NSS volume, the data is not encrypted on the NCP volume. This would be a major security violation.
WARNING:We strongly recommend that you do not migrate data from an encrypted NSS volume to an NCP volume.
Consider migrating the device that contains the encrypted NSS volume from the NetWare server to the Linux server. For information on this scenario, see Moving Non-Clustered Devices From NetWare 6.5 SP8 Servers to OES 23.4
in the OES 23.4: NSS File System Administration Guide for Linux.
Distributed File Services is a feature of OES Storage Services. If an NSS volume contains junctions or is a junction target, it affects how you migrate the data.
DFS does not support junctions on NCP volumes on Linux file systems. If the original NSS volume contains junctions, its junctions are broken after migrating its data to an NCP volume. Instead of migrating data to an NCP volume, consider one of the following methods to move the data to an NSS volume on OES 23.4:
Use the File System Migration Tool to migrate the data from the NSS volume on NetWare to an NSS volume on OES.
Use the Distributed File Services Move Volume task to move the NSS volume from NetWare to Linux. For information, see Using DFS to Move NSS Volumes
in the OES 23.4: Distributed File Services Administration Guide for Linux.
Move the devices that contain the pool from NetWare to Linux. For information, see Migrating NSS Devices to OES 23.4
in the OES 23.4: NSS File System Administration Guide for Linux.
NCP volumes can be the target of junctions on NSS volumes. If the original NSS volume is a junction target, it resides in a DFS management context. The Data Migration Tool uses the same Volume object for a volume when it is migrated within the same tree. This allows the volume to keep the same DFS GUID, so junctions that point to the volume are broken only until the VLDBs that are involved are repaired, as described in Table 4-1:
Table 4-1 Post-Migration DFS Tasks
|
Destination Server’s DFS Management Context |
Post-Migration DFS Tasks |
|---|---|
|
Same |
Run VLDB repair in the DFS management context. |
|
Different |
Run a VLDB repair in both the original and destination DFS management contexts. |
|
None, but in the same tree |
Create a DFS management context that contains the destination server. This creates a new VLDB that contains the destination volume information. |
For information about running a VLDB repair, see Repairing the VLDB
in the OES 23.4: NSS File System Administration Guide for Linux.