save failed to authenticate with nsrmm using GSS Legato: Timed out

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.

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?

You may try disabling nsrauth on the client.

Arun

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!

Real men don't use nsrauth nor wizard

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.

Hi,

Please, can you give a link to BUG base (ID (NW112881))?

I have same problem with 7.6

Thank you

I'm getting this occasionally on some filesystems on the same client during the same save session. I'm running  7.6.Build.142

all have same errors in there, here is one

40473 09/02/11 22:30:05  2 0 0 1 15618 0 snapshot4.xxx.com savegrp command ' save -s snapshot4.centtech.com -g Jedi-Combined -LL -m jedi5w.xxx.com -l full -q -W 78 -N /share/fs10 /share/fs10' for client jedi5w.xxx.com exited with return code -1.

32496 09/02/11 22:30:05  2 0 0 1 15618 0 snapshot4.xxx.com savegrp job (1186762) host: jedi5w.xxx.com savepoint: /share/fs10 had ERROR indication(s) at completion.

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.

Hi!

Can you render the daemon.raw file from the client and get the exact error message?

To do this, go the location of the daemon.raw file, typically located at C:\Program Files\Legato\nsr\logs

Copy the daemon.raw file, paste it in the same folder. Rename to the date you are doing the work. For example, daemon_09162011.raw

Next, open the command prompt and CD to the logs file directory:

cd C:\Program Files\Legato\nsr\logs

Then run the following command:

nsr_render_log daemon_09162011.raw >> daemon_09162011.log

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.

Mark Bellows

Kramer,

I am sorry 0 I have been tied up with some upgrades, so I have not gotten back to this.

I am wondering about the command used for the backup:

save -s snapshot4.centtech.com -g Jedi-Combined -LL -m jedi5w.xxx.com -l full -q -W 78 -N /share/fs10 /share/fs10

The -q tells networker to run this backup with summary information only.

Run this backup from the command line of the NetWorker server.  Use this:

save -s snapshot4.centtech.com -g Jedi-Combined -LL -m jedi5w.xxx.com -l full -W 78 -N /share/fs10 /share/fs10

All I have done is to remove the -q.

BEFORE you run this, go to the client that is giving you trouble, stop the NetWorker services, then got to nsr/logs and rename the daemon.raw to deamon.old.  Start the services back up and a clean daemon.raw will be created.

Run the backup agan, then render the new daemon.raw and see what is there.  You can also attach it to a post so we can see it, if it is not too big anyhow.

I would like to know what exactly is going on. This is the easiest way to do that.

Mark

we are still using the gui schedules on the backup server to that command came from there. do most users run backups from cron on the clients? seems like it is easier to customize (ie, cloning after fulls etc). just updated server to 7.6 sp2 yesterday. next fulls are going to run on 10/7

The idea behind running this command manually is to get more information put into the daemon.raw file - I am not saying this should be used on a regular basis.

I've split the group into 2 jobs. Seems like I'm hitting some timeout (parallelism too high?)

Have you rendered the daemon.raw files to see what the error messages are?

Also, it might be parallelism or target sessions that are too high.  If you split it into two groups, but you have them starting at the same time, then it will not really change things.  The second group should start at a different time - say an hour or two later - to allow the first groups a chance to get through the "light" stuff - VSS backups mainly, and smaller drives - before the second groups starts.

If you have a support contract, you can contact support and ask them to review your settings for you to make sure they are set correctly.

You can also review the NetWorker 7.6 version Performance Optimization Planning Guide . This is located on Powerlink at Home > Support > Technical Documentation and Advisories > Software ~ J-O ~ Documentation > NetWorker Family > NetWorker > 7.6 & Service Packs.  Look for the information for the exact version you have - that is 7.6, 7.6 sp1 or 7.6 sp2.  Only because there are slight differences for the enhancements in each.

If you have DataDomain, I would suggest 7.6.2  and get the DDBoost license.  You can take full advantage of the deduplication technologies that DataDomain offers through NetWorker.

Mark