Trustee assignments appear to no longer work after NetWare 4.x to NetWare 6.x upgrade or migration.
(Last modified: 22Oct2003)
This document (10078892) is provided subject to the disclaimer at the end of this document.
fact
Novell NetWare 6.0
Novell NetWare 6.0 Support Pack 2
Novell NetWare 6.0 Support Pack 1
Novell NetWare 4.11
Novell NetWare 4.2
Novell Migration Wizard
symptom
Trustee assignments appear to no longer work after NetWare 4.x to NetWare 6.x upgrade or migration.
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 appears to alleviate the problem but occasionally it returns.
note
DS.NLM version 6.21 includes a new NLM called SGUID.NLM that will allow for the creation and synchronization of GUIDs on NetWare 4.x servers. For information on how to use this new utility, see TID 10081527 - How to use SGUID.NLM on a NetWare 4.x server
cause
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 following an upgrade from NetWare 4.x to NetWare 6.
NOTE: Novell Engineering is currently working on an updated version of DS.NLM for NetWare 4.x which will allow GUIDs to be created on a NetWare 4.x server and will also allow for successful synchronization between NetWare 4.x and NetWare 6.x servers. This will only be a temporary solution while servers are upgraded to NetWare 6. When this new version is available, this solution will be updated accordingly.
Scenario 1
Not having a version of eDirectory in the replica ring that contains the user object that has a trustee assignment to the server that is being upgraded to Netware 6 or the Netware 6 server being upgraded does not have a real copy of the user object that holds a trustee assignment to that server that is being upgraded. This primarily means any NDS 6.x version on Netware 4.x. All other versions of DS support GUIDs, however, the enforcement of adding GUIDs to objects was not added until eDirectory 8.5 and greater.
Problem:
NDS 6.x does not understand GUIDs. For this reason, if there is not a real copy of the user object on a server running NDS 7.x or higher, the GUIDs will not be created so there is nothing to write to the NSS file system. If the GUID is not present then when NSS goes to write a GUID into its metadata for the trustees it sees no GUID attribute in NDS and thus does not give any trustees for the user to the NSS volume.
How to avoid the problem:
Make sure that there is at least one server running NDS 7.x or higher in every replica ring where users have file system trustee assignments assigned to them.
Another workaround is to make sure the server that is being upgraded has all replicas for all users that have file system trustee assignments to that server before upgrading the server.
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 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.
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
There is an issue with the FCS version of eDirectory 8.6.2 where random information on an object may not synchronize to all servers in the replica rings. 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 as well as the GUID value. If the MTS is older than the transitive vector for that partition, then scenario 3 probably occurred.
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 where the transitive vectors advanced too soon and not all data is synchronized between replicas.
How to avoid the problem:
- Make sure that eDirectory 8.6.2 sp4 or higher is applied to all servers running eDirectory 8.6.2 before upgrading servers to Netware 6.
- If doing an across the wire migration, make sure that you apply the eDirectory 8.6.2 sp4 patch or higher to the temporary server before migrating to Netware 6.
- If doing an inplace upgrade, the Netware 6 sp3 overlay must be used to ensure this problem does not occur.
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 it metadata the first time, and does not sync its information again. DMPTRUST.NLM is a utilitly 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.
fix
How do I fix the problem if one of the above scenarios happened to me?
(Note: the following should be executed on the Netware 6 server that was just upgraded.)
- 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 through out the corresponding replica ring.
o 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)
o 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 the Directory Services screen and make sure the backlinker process finishes successfully.
- Contact Novell Technical Support to get a utility named SYNCGUID.NLM to syncronize 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 syncronized eDirectory information).
- Do "NSS /VisibilityRebuild=VolName" to reset the NSS visibility list.
.For additional information on eDirectory 8.7, please see the following solution. NOVL [no longer available]NOVL81742 - eDirectory 8.7 Readme Addendum
document
| Document Title: | Trustee assignments appear to no longer work after NetWare 4.x to NetWare 6.x upgrade or migration. |
| Document ID: | 10078892 |
| Solution ID: | NOVL85846 |
| Creation Date: | 16Jan2003 |
| Modified Date: | 22Oct2003 |
| Novell Product Class: | NetWare Novell eDirectory |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.