When creating an NSS pool or volume with NSSMU on your Linux server, an Error 613 is returned if the server has no eDirectory Read/Write replica available in the same tree when you create the pool or volume so that the Storage objects can be written to eDirectory. The error occurs because NCP (NetWare Control Protocol) cannot map to the pool or volume.
To avoid this problem, make sure the server has an eDirectory Read/Write replica. You can also add the NSS volume path to the /etc/opt/novell/ncpserv.conf file for NCP Server.
When creating an NSS pool by using NSSMU or iManager, an Error 672 is returned if there is no NSS Admin object in the NetIQ eDirectory database for the server (such as HOSTNAMEadmin.context). NSS requires that an NSS Admin object must exist for each and every server, or management does not work.
NOTE:NSS Admin object must be placed under the default location, that is, the same place where the server object exists.
This situation occurs if you move a server across trees without also moving its NSS Admin object from one tree’s eDirectory database to the other.
If you re-create the NSS Admin object, you are then able to successfully create pools.
To re-create the NSS Admin object, run nssAdminInstall at a Linux terminal console as the root user:
Open a terminal console, then log in as the root user.
At the console prompt, enter the following (all on the same line, of course):
nssAdminInstall -a adminname.context -P -o HOSTNAMEadmin.context
For example, the nssadmin user object is in the form of server1admin.example, where server1 is the server name and example is the container where the server object also resides.
nssAdminInstall -a admin.example -P -o cn=server1admin.o=example
After the NSS Admin object is created, update the eDirectory Pool object. For information, see Section 15.14, Updating eDirectory Pool Objects.
When the eDirectory context of the nss admin user object changes, when doing NSS Volume/Pool management operations, for example, create, rename, you might get the error 601. To avoid this problem, perform the following steps:
Remove the nss admin user object from eDirectory using iManager. (By default, nss admin user resides in the container where the server object resides).
For example, the nssadmin user object is in the form of server1admin.example, where server1 is the server name and example is the container where the server object also resides.
Run nssAdminInstall to recreate the nssadmin object.
For example, nssAdminInstall -a admin.example -P -o cn=server1admin.o=example where admin.example is the context of the eDirectory admin user and server1admin.example is the nssadmin user object to be recreated.
NOTE:Run the nssAdminInstall command on all the servers whose nssadmin object context is changed.