It means you are using narauth on server/storage node and to cut the story you should disable it. Looking for nsrauth in forum search will give you more details. If you wish to keep it and address this specific error only you can either search again forum or docs where this is described how to address it. I would go for disabling nsrauth.
If you don't want to disable the enhanced security with nsrauth follow the steps in solution esg77529 how to resync nsr peer information between clients.
nsrauth was terrible in 7.3.x but in actual versions of 7.4 and 7.5 we see it working well.
I believe, its just a typo. Hrvoje actually might have meant "nsrauth" and not narauth.
The deleting of the peer information and creating a new one will do no good. The error will still come back. but I have not tried disabling the nsrauth on that client. Its better you try that.
I disagree. I wrote the article referenced and when that message appears, it's one of the few that has an absolute and explicit meaning (and cause). Moreover, leaving strong authentication on is preferred and turning it off is considered a workaround to be used sparingly.
Nsrauth is what provides certificate based authentication. So yes, in one sense, turning it off circumvents, but does not solve the issue.
The very first time two NetWorker hosts communicate they will present their certificate to the other, then cache the other's certificate in the local agent database store. Thereafter every time they communicate, they will present their certificates to each other, and if the presented cert does not match the cached cert, you will see this message.
For example: If client A has cert "A" and server 1 has cert "1", then the first time they communicate, server1 caches clientA:A and clientA caches server1:1 as type nsr peer information in nsrladb. Now, let's say we upgrade clientA; the nsrladb may be overwritten, creating a new certificate. If this happens, the server will refuse to talk to the client since his cached cert for clientA does not match the new one clientA is presenting.
The simple answer therefore is to do as is laid out earlier in this post and in the article; delete either selectively or entirely the cached, and now incorrect, nsr peer information objects and communications will thereafter be allowed. This is most typically seen between server and client where a client has been reinstalled, but can happen between any NetWorker host, since this is all an aspect of the base Client component.
ble1
4 Operator
•
14.4K Posts
0
November 9th, 2009 04:00
Holger_Inf
1 Rookie
•
122 Posts
0
November 12th, 2009 07:00
nsrauth was terrible in 7.3.x but in actual versions of 7.4 and 7.5 we see it working well.
jarady
2 Intern
•
132 Posts
0
December 7th, 2009 00:00
Hi Hrvoje Crvelin
What do you mean by "narauth"? this is the first time I hear it.
PrinceAijaz
1 Rookie
•
38 Posts
1
December 7th, 2009 02:00
Hello Go to networker Server and type the following
nsradmin -p nsrexec
nsradmin>print type: nsr peer information;name:w-00117.ye.ad.ep.corp.local
delete
y
start servcies on NWR server
then login to this cleint
#nsradmin -p nsrexec
nsradmin>print type: nsr peer information
delete
y
start services on client
You should be good to go. it will create new certificate for your cleint.w-00117.ye.ad.ep.corp.local
Regards
aijaz
Johnwkay
3 Posts
0
May 12th, 2010 06:00
Slight correction:
nsradmin>print type: nsr peer information; name: svr-name.domain.com
This will return something like this:
type: NSR peer information;
administrator: "group=Administrators,host=localhost", "group=Administrators,host=svr-nsrbackup.x.net", "isroot,host=svr-nsrbackup";
name: svr-name.domain.com;
peer hostname: svr-name.domain.com
Change certificate: ;
certificate file to load: ;
nsradmin> delete
type: NSR peer information;
administrator: "group=Administrators,host=localhost", "group=Administrators,host=svr-nsrbackup.x.net", "isroot,host=svr-nsrbackup";
name: svr-name.domain.com;
peer hostname: svr-name.domain.com
Change certificate: ;
certificate file to load: ;
Delete? y
deleted resource id 12.0.216.30.51.9.29.71.172.29.15.107(1)
nsradmin>
rovinabi
55 Posts
0
May 13th, 2010 03:00
Hi,
I believe, its just a typo. Hrvoje actually might have meant "nsrauth" and not narauth.
The deleting of the peer information and creating a new one will do no good. The error will still come back. but I have not tried disabling the nsrauth on that client. Its better you try that.
HTH,
Rovin D'Souza.
jkernagh
35 Posts
0
October 6th, 2010 11:00
I disagree. I wrote the article referenced and when that message appears, it's one of the few that has an absolute and explicit meaning (and cause). Moreover, leaving strong authentication on is preferred and turning it off is considered a workaround to be used sparingly.
Nsrauth is what provides certificate based authentication. So yes, in one sense, turning it off circumvents, but does not solve the issue.
The very first time two NetWorker hosts communicate they will present their certificate to the other, then cache the other's certificate in the local agent database store. Thereafter every time they communicate, they will present their certificates to each other, and if the presented cert does not match the cached cert, you will see this message.
For example: If client A has cert "A" and server 1 has cert "1", then the first time they communicate, server1 caches clientA:A and clientA caches server1:1 as type nsr peer information in nsrladb. Now, let's say we upgrade clientA; the nsrladb may be overwritten, creating a new certificate. If this happens, the server will refuse to talk to the client since his cached cert for clientA does not match the new one clientA is presenting.
The simple answer therefore is to do as is laid out earlier in this post and in the article; delete either selectively or entirely the cached, and now incorrect, nsr peer information objects and communications will thereafter be allowed. This is most typically seen between server and client where a client has been reinstalled, but can happen between any NetWorker host, since this is all an aspect of the base Client component.
Hope that helps! James.
JohanRM
1 Rookie
•
79 Posts
0
July 23rd, 2015 04:00
That worked. Tx