UID still used as file owner after a user has been de-LUMenabled.

  • 7004529
  • 25-Sep-2009
  • 06-Nov-2012

Environment

Novell Open Enterprise Server 2 (OES 2) Linux

Situation

After a user is de-LUMenabled, the server still uses the UID as owner for files stored over a NCP connection.
This is the case for files stored on NSS as for files stored on file systems shipped with SuSE Linux Enterprise Server, for instance EXT2, EXT3, Reiser.

Resolution

This issue is addressed in the OES2 SP1 January 2010 Scheduled Maintenance Patch and the OES2 SP2 January 2010 Scheduled Maintenance Patch and later code.

After the installation of the January 2010 Maintenance Patch or later code, there is a need to perform a ndsrepair -U, followed by a /etc/init.d/ncp2nss restart, then a nsscon /ResetIDCache after the users were de-LUM-enabled to clean up any leftover UID information of these users in several OES system caches.

Cause

NSS has the file owner's GUID and performs a GUID to UID translation using eDirectory APIs via NCP.
This call is apparently returning a valid UID for these users, despite they are de-LUMenabled.
NCP maintains a persistent cache for localIDtoUID mappings but invalid UIDs were not cleaned up.

With the OES2 SP1 and OES2 SP2 January 2010 Scheduled Maintenance Patch the NCP server regularly performs a routine that verifies the UIDs and correctly cleans up invalid entries.
However, NSS ID Cache also needs to be reset, which needs to be performed manually (Otherwise it can take up to 25 hours for NSS to clear its cache). This way NSS will also remove the stail UID information it received from NCP.

Additional Information

In case the affected volumes are only NCP exports of a file system shipped with SuSE Linux Enterprise Server and the Novell Open Enterprise Server is not hosting NSS volumes, or is installed without the Novell Storage Services (NSS) pattern, the /etc/init.d/ncp2nss and nsscon /ResetIDCache are unavailable and not are not required to be executed.