Highlighted
mellofone Absent Member.
Absent Member.
3966 views

mount: fs type nssvol not supported by kernel

I have had an OES server "dropped" in my lap and I am really stuck. I've been searching like crazy, and I can't seem to come up with a fix for the problem. Everything was running just fine, then suddenly the main (and only) NSS volume would not mount. I've rebooted the server several times, and I continue to get the same errors:

# ls /media/nss/
DATA

At least something is there now. However:

# mount DATA
mount: fs type nssvol not supported by kernel

So I try:

# /etc/init.d/novell-nss start
Starting Novell Storage Services (NSS)
ERROR: required LUM(namcd) is not running
.......... ABORTING /etc/init.d/novell-nss ..........

Ok, I thought I was getting somewhere. So:

# /etc/init.d/namcd start
Starting NAM Cache Daemon ...
Waiting for LDAP server to be ready ...
........

And it takes forever. Checking messages, I see:

Aug 13 00:36:33 NWL-FS1 namldapprobe: namGetLDAPHandle failed to get LDAP handle, error 3.
Aug 13 00:36:34 NWL-FS1 namldapprobe: pam_ldap_init(): retrieval of trusted root cert failed. Make sure you have LDAP server certificate in /var/lib/novell-lum directory.

Over and over and over. So I did:

# namconfig -k
Enter the admin(cn=admin,o=NWLSD) password:

namconfig.getSchemaName: schema name = cn=schema
Certicate file updated sucessfully

Yet I continue to get the same error over and over.. I'm stuck. I can't seem to come up with anything. Here is what I can get out of the server (again, I am brand new to OES):

# SPident -v

Summary (using 664 packages)
Product/ServicePack conflict match update (shipped)
OES-9-i386 0 0% 259 39.0% 238 (1628 15.9%)
SLES-9-i386 0 0% 202 30.4% 225 (1486 13.6%)
OES-9-i386-SP1 0 0% 121 18.2% 187 (836 14.5%)
SLES-9-i386-SP1 0 0% 33 5.0% 142 (481 6.9%)
OES-9-i386-SP2 0 0% 197 29.7% 199 (962 20.5%)
SLES-9-i386-SP2 0 0% 67 10.1% 168 (647 10.4%)
SLES-9-i386-SP3 0 0% 109 16.4% 181 (750 14.5%)
Unknown 265 39.9%


CONCLUSION: System is up-to-date!
found SLES-9-i386-SP3 + "online updates"

And all packages are updated via rug. I am to the point of begging for help!
Labels (2)
0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: mount: fs type nssvol not supported by kernel

Had the same problem a month ago and you can find some solution in the
same group 19.7 this year.
Also found an earlier post with sles 9 but the same symptoms.
Also be sure to restart the server at the end of reimporting the
certificates - I didn't and it took me a while to realize it was already
functioning.

Hope you get somewhere,

DB
--
****************
DominicusB
Southern Finland
architect
Netware 6.5 sp7
GW 7.x


mellofone wrote:

>
> I have had an OES server "dropped" in my lap and I am really stuck.
> I've been searching like crazy, and I can't seem to come up with a
> fix for the problem. Everything was running just fine, then suddenly
> the main (and only) NSS volume would not mount. I've rebooted the
> server several times, and I continue to get the same errors:
>
> # ls /media/nss/
> DATA
>
> At least something is there now. However:
>
> # mount DATA
> mount: fs type nssvol not supported by kernel
>
> So I try:
>
> # /etc/init.d/novell-nss start
> Starting Novell Storage Services (NSS)
> ERROR: required LUM(namcd) is not running
> ......... ABORTING /etc/init.d/novell-nss ..........
>
> Ok, I thought I was getting somewhere. So:
>
> # /etc/init.d/namcd start
> Starting NAM Cache Daemon ...
> Waiting for LDAP server to be ready ...
> .......
>
> And it takes forever. Checking messages, I see:
>
> Aug 13 00:36:33 NWL-FS1 namldapprobe: namGetLDAPHandle failed to get
> LDAP handle, error 3.
> Aug 13 00:36:34 NWL-FS1 namldapprobe: pam_ldap_init(): retrieval of
> trusted root cert failed. Make sure you have LDAP server certificate
> in /var/lib/novell-lum directory.
>
> Over and over and over. So I did:
>
> # namconfig -k
> Enter the admin(cn=admin,o=NWLSD) password:
>
> namconfig.getSchemaName: schema name = cn=schema
> Certicate file updated sucessfully
>
> Yet I continue to get the same error over and over.. I'm stuck. I
> can't seem to come up with anything. Here is what I can get out of
> the server (again, I am brand new to OES):
>
> # SPident -v
>
> Summary (using 664 packages)
> Product/ServicePack conflict match update (shipped)
> OES-9-i386 0 0% 259 39.0% 238 (1628 15.9%)
> SLES-9-i386 0 0% 202 30.4% 225 (1486 13.6%)
> OES-9-i386-SP1 0 0% 121 18.2% 187 (836 14.5%)
> SLES-9-i386-SP1 0 0% 33 5.0% 142 (481 6.9%)
> OES-9-i386-SP2 0 0% 197 29.7% 199 (962 20.5%)
> SLES-9-i386-SP2 0 0% 67 10.1% 168 (647 10.4%)
> SLES-9-i386-SP3 0 0% 109 16.4% 181 (750 14.5%)
> Unknown 265 39.9%
>
>
> CONCLUSION: System is up-to-date!
> found SLES-9-i386-SP3 + "online updates"
>
> And all packages are updated via rug. I am to the point of begging for
> help!

0 Likes
mellofone Absent Member.
Absent Member.

Re: mount: fs type nssvol not supported by kernel

DominicusB;1616712 wrote:
Had the same problem a month ago and you can find some solution in the
same group 19.7 this year.
Also found an earlier post with sles 9 but the same symptoms.
Also be sure to restart the server at the end of reimporting the
certificates - I didn't and it took me a while to realize it was already
functioning.



I've searched and searched and can't seem to find anything that helps. In iManager, I've re-recreated all of the certificates that I can, restarted everything and still have the same results.
0 Likes
mellofone Absent Member.
Absent Member.

Re: mount: fs type nssvol not supported by kernel

Is there a howto on recreating SSL certs? I've tried it and it made no difference.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.