Could someone help me better understand the mechanism for maintaining trustee rights on NSS volumes under OES2 Linux? Even a link to some decent documentation would be helpful as I haven't been successful in finding any.

For example, a switch failure recently caused multiple cluster nodes to crash. After resolving that and restarting the servers, some volume resources couldn't be onlined because the pools were still flagged as active on other nodes. After using nssmu to deactivate the pools, we could online the resources. The the trustee issues began.

On one volume resource, all trustee rights were "gone." Luckily using ncpcon, we were able to perform an nss sync=<volname> and restore the trustees. But why were the trustees "gone" in the first place when they really weren't "gone?" There are 2 places that these trustees exist?

Now I have another one of the crashed volumes experiencing issues. When I right click a directory and select Trustee Rights..., I can see the listed trustees. However, when using a third party tool (JRB Utils) to dump all trustee of the volume, it shows that half of them are "gone." This utility does not exhibit this behavior on any other volumes. I'm planning an ncpcon nss sync on this volume, but once again, what are these 2 places that trustees can apparently live?

In various documentation, I've run across mentions of trustee.xml, namcd, ncp2nss, and other ingrediants of the soup that is used to present nss rights in OES2 Linux.

Can anyone help me better understand how all these parts fit together?