SFTP access to an NSS volume on OES is very slow

Many of the file and directory entries on the NSS volume were listed as being assigned GID "nobody".  This represents a value which could not be found in eDirectory, which would cause lookup delays.  Use the chgrp or chown commands to set the GID to "root". For example, so set every GID in a directory, cd into that directory and give the command:

 

chgrp root *

or

chown :root *

 

It is generally considered fine to set all file and directory GIDs on NSS to "root", as that is what almost all methods of creating entries on NSS would result in, by default.

 

An alternative solution would be to edit /etc/nam.conf and set "cache-only   yes".  This is defined in the man page as:

 

       cache-only
                 Specifies whether namcd will use only the cache for  informa
                 tion  about  users  and  groups.  If  the  information  about
                 user/group not found in the cache,  namcd  will  not  request
                 this  information from LDAP. Values can be "yes" or "no." The
                 default value is "no".

This would speed up access again.  However, the danger is that "new" information (information that may now exist in eDir but is not yet in cache) would never be learned.

NSS volumes typically report "nobody" as the assigned GID if the GID value is something unknown to eDirectory.  Values not known to eDir are not cached by namcd (the Novell Account Management Cache Daemon).  So if an entry's GID is not in the cache, it takes some extra time (about a second) for that GID to be looked up in eDir and the negative answer to come back.  If a large amount of these are present, it can add up to a long delay.

 

In most cases, this scenario will not come up.  Most methods of creating files on an NSS volume with simply assign the "root" group as the GID, which is always a known entity.  However, it is conceivable that unknown values could be present.  For example, if a NSS volume was migrated from NetWare, and that NetWare volume was used for NetWare NFS file sharing, various GID values which to not exist in eDirectory could be present.  There may be other sources of unknown GIDs as well, but they are considered rare.