Error in /var/log/messages "kernel: Unable to find .USER.CONTEXT. to get the GUID."

In the course of normal filesystem operation (ls -l, for example) NSS is called upon to retrieve information about the owner of a file or directory.  When this occurs it has to lookup the GUID belonging to the fully qualified distinguished name (FQDN) stored in the ObjectID cache for the volume.  The object store, which is persistently stored on the disk, contains trustees assigned to the volume with a GUID to FQDN mapping.  After retrieving this information NSS queries eDirectory using the GUID and FQDN information to correlate them again and determine whether or not the user is a LUM user.  This information is eventually stored in an in-memory cache.

When an eDirectory user is deleted NSS receives a delete event containing the FQDN of the user.  NSS takes this deleted user's name and clears the user from the object store.  When NSS later tries to retrieve owner information for this FQDN and doesn't find it in the object store it assigns "nobody" as the owner of the file or folder.

In this case what seems to have happened is that when the eDirectory object was deleted NSS didn't receive or didn't process the event and the FQDN was left in the object store.  The result is that NSS expects to be able to resolve the FQDN<->GUID mapping from eDirectory (which it obviously can't because the user no longer exists).

WARNING: following these instructions will remove any user quotas that were set on the volumes.  Use "metamig" to back them up before doing the following procedure.

Run these three commands in "nsscon" to dump the caches and allow the object stores to be rebuilt. 

host:~ # nsscon                                                                    
host> nss /resetObjectIDStore=all
host> nss /removeObjectIDStore=all
host> nss /forcebackgroundcheck

The "all" directive runs the command against all NSS volumes.  If you are able to narrow the problem to a single volume you can alternately specify just that volume name.

These commands clear the ObjectID Store (GUID to FDN) cache and will be built again as users start accessing the file system.  So the side effect, if any, is like rebooting the machine as far as this cache is concerned. Other NSS caches will not be affected.  This problem also does not immediately remove or reset file ownership information in the persistent object store for the files owned by the now-deleted eDirectory users - the regular NSS processes will eventually reset the ownership to "nobody" using the process mentioned above.

Update - Dec 4, 2013
November 2013 OES11 versions have a  Scheduled Maintenance Update that includes this fix.