Environment
Novell Open Enterprise Server (OES)
Situation
Lost or inconsistent trustee assignments are encountered on NSS volumes under OES Linux - esp. after a resource has been offlined/onlined or migrated.
Resolution
Resolution #1: The first attempt to resolve this matter is to synchronize the NSS metadata with the trustee database (used by NCP). To do so, run the following command:
ncpcon nss resync=VOLUME_NAME
replacing VOLUME_NAME with the correct name of the volume encountering this issue.
Resolution #2: In some cases, the NSS attributes on the database itself -- found on
/media/nss/VOLUME_NAME/._NETWARE/.trustee_database.xml
may be incorrect. To verify the attributes are correct on this file, while logged in to the server console or ssh session as root, you should run:
attrib -l /media/nss/VOLUME_NAME/._NETWARE/.trustee_database.xml
the output of this command should look like:
Attributes for /media/nss/<volume_name>/._NETWARE/.trustee_database.xml
-----------------------------------------------------------------------
Read Only
Hidden
Archive
Attribute Archive
-----------------------------------------------------------------------
Read Only
Hidden
Archive
Attribute Archive
If you have additional attributes like Delete-Inhibit and/or Rename-Inhibit, these attributes can interfere with the proper updating of the trustee database. To remedy, perform the following:
- Login to the server console or TTY session as root
- change directory to ._NETWARE on the volume -- i.e. cd /media/nss/VOLUME_NAME/._NETWARE
- run attrib -c all .trustee_database.xml
(this will remove the NSS attributes from the trustee database) - change directory to /media/nss
- dismount and remount the volume:
For NCS cluster resources: cluster offline and cluster online the resource
For non-NCS volumes: from nssmu dismount and remount the VOLUME_NAME - run ncpcon nss resync=VOLUME_NAME
Your trustees should now be consistent.
Additional Information
NCP clients accessing OES Linux NSS volumes receive their trustee assignments through a trustee database found in a system directory at the root of the NSS volume.
Under some conditions, it is possible for the contents of this database to be inconsistent with the trustee assignments stored in the NSS metadata. Tools such as ConsoleOne, iManager, and the `rights` command line utility store trustee assignments directly in the NSS metadata, which is the authoritative source for trustee assignments.
If the trustee database does not match what is stored within the NSS metadata, inconsistent trustee assignments may be encountered.
Under some conditions, it is possible for the contents of this database to be inconsistent with the trustee assignments stored in the NSS metadata. Tools such as ConsoleOne, iManager, and the `rights` command line utility store trustee assignments directly in the NSS metadata, which is the authoritative source for trustee assignments.
If the trustee database does not match what is stored within the NSS metadata, inconsistent trustee assignments may be encountered.
A majority of the time, resolution #1 above will repair the trustees and all is well. In some cases, the mounting of the NSS volume that was formerly on NetWare, will not complete the transition to Linux successfully. The transition process goes through the NSS metadata to build the trustee database the first time the volume is mounted on linux. If this is interrupted -- either accidentally or purposefully -- the trustee database will get "frozen" with the last trustee assignment transitioned. Resolution #2 should remediate this situation.
Formerly known as TID# 10101030