Novell is now a part of Micro Focus

Trustee assignments don't work after upgrading from NetWare 4.x to NetWare 6.

Articles and Tips: qna

01 Jun 2003


eDirectory

Problem:

Trustee assignments don't work after upgrading from NetWare 4.x to NetWare 6. When viewing the Trustees of the file or subdirectory, the user is listed. However, when you check "Rights to Files and Folders," the user does not have rights. Deleting the trustee and adding it back alleviates the problem but it occasionally returns.

Solution:

The following are descriptions of similar Global Unique Identifier (GUID) issues that have been known to prevent trustee rights from appearing correctly on NSS volumes after upgrading from NetWare 4.x to NetWare 6.

Scenario 1

You may experience the problem if eDirectory is not installed in the replica ring that contains the user object that has a trustee assignment to the server being upgraded. You may also experience the problem if the server being upgraded doesn't have a real copy of the user object that holds a trustee assignment to it.

This primarily refers to any version of NDS 6.x running on Netware 4.x. All other versions support GUIDs. However, the enforcement of adding GUIDs to objects was added in eDirectory 8.5.

Problem:

NDS 6.x does not understand GUIDs. So if a real copy of the user object doesn't exist on a server running NDS 7.x or higher, the GUIDs won't be created. Therefore, nothing will be written to the NSS file system. If the GUID is not present, NSS obviously won't see any GUID attribute in NDS when it attempts to write a GUID into its metadata for the trustees and thus won't give any trustees for the user to the NSS volume.

How to avoid the problem:

At least one server must be running NDS 7.x or higher in every replica ring in which users have been assigned file system trustee assignments.

Another workaround is to ensure that the server being upgraded contains all replicas for all users that have file system trustee assignments to that server before upgrading it.

Scenario 2

The Netware 4.x server is not running an NDS version that will consistently synchronize with servers that are running eDirectory 8.6.x or higher (i.e., any Netware 6 server).

Problem:

The GUIDs that are created on the user objects are not being synchronized to the Netware 4.x box (along with other attributes). When the Netware 4.x box is upgraded, there is not a GUID so the eDirectory upgrade adds a GUID to the object. Now the same object is on two different servers with two different GUIDs. The NSS file system will only read one of the GUIDs. This will cause complete loss or inconsistent results of trustee assignments.

How to avoid the problem:

Make sure that all Netware 4.x servers are running NDS version 6.17 or higher before upgrading any server to Netware 6.

Scenario 3

Random information on an object may not synchronize to all servers in the replica rings when using the FCS version of eDirectory 8.6.2. This issue can be verified by examining the modification timestamp (MTS) of the GUID attribute on the user that lost trustee rights for each replica. The MTS should be identical to the GUID value. If the MTS is older than the transitive vector for that partition, then random information on the object probably didn't synchronize to all servers in the replica ring.

Note: For more information on how to Use NDS iMonitor to look at these attributes, refer to the eDirectory 8.7 documentation at: http://www.novell.com/documentation/lg/ndsedir86/index.html under the Novell eDirectory Management Utilities | Novell iMonitor section.

Problem:

eDirectory 8.6.2 SP2 or higher is required on all servers running eDirectory 8.6.2. There were some issues in which the transitive vectors advanced too soon and not all data was synchronized between replicas.

How to avoid the problem:

  • Make sure that eDirectory 8.6.2 SP2 or higher is applied to all servers running eDirectory 8.6.2 before upgrading servers to Netware 6.

  • If performing an across-the-wire migration, make sure that to apply the eDirectory 8.6.2 SP2 patch or higher to the temporary server before migrating to Netware 6.

Scenario 4

Upgrade a server to Netware 6 before the GUID attribute is synchronized to all servers in the replica ring(s) that contain the user objects.

Problem:

When another Netware 4.x box is upgraded that is in the same replica ring as the original box in the above scenario, there is not a GUID attribute on the user. So the eDirectory upgrade adds a GUID to the object. Now you have the same object on two different servers with two different GUIDs. The NSS file system will only read one of these GUIDs. This will cause complete loss or inconsistent results of trustee assignments.

The NSS volume will only write the GUID to its metadata the first time, and does not sync its information again. DMPTRUST.NLM is a utility that will check the NSS GUIDs with the NDS GUIDs and report any errors.

How to avoid the problem:

Make sure you give the replicas time to synchronize. Also follow the instructions from How to avoid the problem from Scenario 3.

Solution:

How do I fix the problem if one of the above scenarios has occurred?

Note:

The following should be executed on the Netware 6 server that was just upgraded.

  • Make sure you are on the latest version of NSS code.

  • Do "NSS /resetidcache" from the server console. This will reset the NSS cache with the current eDirectory information.

  • The NSS cache is refreshed by default every 25 hours. Failure to reset the cache could give you incorrect information when using DMPTRUST.NLM and SYNCGUID.NLM.

  • Use DMPTRUST.NLM first to make sure that inconsistencies exist. Refer to the readme.txt in DMPTRUST.EXE for instructions on using DMPTRUST.NLM.

  • Make sure that NDS has synchronized the same GUID attribute on all users that have trustee assignments to the upgraded server throughout the corresponding replica ring.

  • If scenario 3 occurs, the only way to synchronize the GUIDs is to perform a partition epoch. (Note: For more information on declaring a partition epoch, see http://support.novell.com/cgi-bin/search/searchtid.cgi?/10073685.htm)

  • Do not forget external references. After the real copy of the objects have the correct GUID, run a backlinker process to update the external references with the new GUID.

  • Running the backlinker process

    • Set dstrace=on

    • Set dstrace=+blink

    • Set dstrace=*b

      • Go to the Directory Services screen and make sure the backlinker process finishes successfully.

  • Contact Novell Technical Support to get a utility named SYNCGUID.NLM to synchronize the GUIDs between NDS and NSS. Refer to the readme.txt in SYNCGUID.EXE for instructions on using SYNCGUID.NLM. (Make sure to reset the NSS cache before running SYNCGUID.NLM. This is done by running "nss /resetidcache" from the server console. Failure to reset the cache will allow SYNCGUID.NLM to use cached information rather than the newly synchronized eDirectory information).

Do "NSS /VisibilityRebuild=VolName" to reset the NSS visibility list.

* Originally published in Novell Connection Magazine

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates