save failed to authenticate with nsrmm using GSS Legato: Timed out
Hi,
Have a NetWorker 7.6 server backing up numerous Windows 2003 and 2008 clients. On various save jobs we get the following errors: -
2010-05-28T11:01:36Z 39077:save: error, Failed to connect to storage node on myserver.mydomain.internal: save failed to authenticate with nsrmm using GSS Legato: Timed out
5777:save: Cannot open save session with myserver.mydomain.internal
This is Known issue in 7.6 , You can have a Look at the BUG ID (NW112881) , I'm not sure whether the bug is fixed or not , But there is a work around for this.
You may need to disable nsrauth on the client end.
I get the same error on NW 7.5.2. It only happens over the weekend when I have my full backup jobs running. Strange part is that some drives on a server will backup but others get this error. If I re-run the job a few days later then it all runs fine. Is there some issue with nsrauth getting overloaded?
After fighting this same exact issue non stop for 3 months they figured out turning off NSRAUTH was a workaround for this error(not a fix). Turning off NSRAUTH breaks the configuration wizard and the browsing when modifying a job. They figured out a workaround for that(not a fix). Now the configuration wizard won't work with the SQL servers. This software is crap!
I believe nsrauth has been worked on for 7.5SP3 (should be out soon or at least until August I believe).
Those wizard thingy might be cool in the start, but afterwards you should be able to use existing setup as template and achieve what you want much faster even without wizard. nsrauth has been common enemy since 7.3.x release so I always recommend not to use it.
64690 09/02/11 22:30:05 2 0 0 1 15618 0 snapshot4.xxx.com savegrp savegrp:Jedi-Combined * jedi5w.xxx.com:/share/fs10 See the file /nsr/tmp/sg/Jedi-Combined/sso.jedi5w.xxx.com.07aqGE for output of save command.
/nsr/tmp/sg/Jedi-Combined/sso.jedi5w.xxx.com.07aqGE has already be rotated/deleted.
Of course the name of the file will be based on what you have named it to. The daemon_date.log file will be in a readable format. You should have the information you need there that we will need to help you.
hari_prakash
22 Posts
1907
0
Posted June 1st, 2010 03:00
Hi Mark,
This is Known issue in 7.6 , You can have a Look at the BUG ID (NW112881) , I'm not sure whether the bug is fixed or not , But there is a work around for this.
You may need to disable nsrauth on the client end.
HTH
Hari.