Cannot Backup Shares from a Snapserver NAS - Network Access Denied

[Ticedoff]

I have a simple setup.
Networker Power Edition 6.1.2 running on a Solaris 8 system
Networker Node Server 6.1.2 running on a Win2k Advanced Server.
I have several Win2k & Solaris Desktops that are being backed up.
The problem is backing up my 3 SnapServers. I know I can not load a Legato Client on the SnapServer, and the SnapServer does not support NDMP.

The Solaris Main Server is "beast"
The Win2k Node Server is "bigbeast"
The SnapServer is "bigerbeast". The share on bigerbeast "source". All SnapServers are running the latest SnapOS.

The entry in the "Save Set" of "bigbeast" is "\\bigerbeast\source". Currently, there are no entrys for "Remote Access", "Remote User" or "Backup Commands". The "Aliases" for "bigbeast" include "bigerbeast".

The SnapServer is set for "Domain Authentication". There is a SnapServer local user "administrator" and it has "Full Access" to all shares and NTFS. All of the Shares, NTFS & files on the Snapserver are owned by a users in the "Domain User" group and "Domain Admin" has "full access" to all the shares & the NTFS. "Administrator" is a member of "Domain Admins" on the Advanced Directory Server.

I am trying to use the UNL for the "Save Set", and it seems to ALMOST work. The /nsr/logs/messages file shows it tried to get to the \\bigerbeast\source share, but gets an error message:
May 28 07:56:53 beast root: [ID 702911 daemon.notice] * bigbeast:\\bigerbeast\source Cannot authenticate user: Logon failure: unknown user name or bad password.
May 28 07:56:53 beast root: [ID 702911 daemon.notice] * bigbeast:\\bigerbeast\source 05/28/03 03:00:02 nsrexec: Cannot authenticate user: Logon failure: unknown user name or bad password

I have tried a number of different techniques. This error messages is just the latest. Some of the other configurations result in "Network Access Denied".

The ONLY thing that works is if I run the "Networker User" program on the Win2k Node Server, and do a manual backup of the mapped drives. This is, at best, a work around.

Is there a specific "local user" that I have to create on the snapserver?
What is the secret here?

The next step, assuming I get an answer to this question, is - How do I recover the files back to the SnapServer?

 

[itzik]

Make sure your networker remote exec service on bigbeast is running a user that can get administrative access to the snapserver.
At standard Networker installation the service runs as "local system".
Restart the service after the effective user change.
You do not need the bigerbeast alias in the alias field for bigbeast

 

[clonny2]

Ho Ticedoff,
I work for SNAP Appliance. Let me see if I can find the answer for you. I am a Sr. QA Engineer, but I work with the Linux OS Servers, not the SnapOS versions. On the SNAPOS versions, you can not install any agent, you have to use a "mapped drive" approach.

For recover, I am not sure. But again, let me see if I can find out.




>---------------------------------------Lawrence Feldman
SR. QA. Engineer SNAP Appliance
lfeldman@snapappliance.com

 

[sdeb]

Try to change "Networker Remote Exec" service'user and set it to a Domain Admin User.

And then try to backup it via a command line such as :

save -s beast -c bigbeast -b Pool -g Group -l full -L u:
Where "u:\" is the mount point of you SNAP server (biggerbeast).
The "-L" is very important (will allow to backup a non local disk).

Then if you absolutly want to schedule those backup you can encapsulate this command line into a PRE/POST backup script of your "bigbeast" server.

 

[Ticedoff]

- I know the SnapServer doesn't support a Legato Client Agent. I have asked Snap Appliance for help, and never got an answer.

- Changing the user that the node server process is running as has had no effect.
It didn't help or hurt.
I changed the process to run as "administrator". I still get denied. All shares & NTFS on all SnapServers have "Domain Admins" with "Full Aceess". "Administrator" is entered into "Domain Admins" group.

- I have not tried to use the manual save option from the command line - I am sure it would work.
I have logged into the Node Server as the "administrator" and run the "Legato User" program. I can then use that to manually run a backup of the M:\ (or any other SnapServer mapped drive) drive without problems.
But that really misses the point - I use Legato to backup the clients on a schedule through it's GUI.
Please don't suggest entering the command line into a script or crontab, I would have to figure out a way to mount the Shared volumes without anyone loged in.

Thanks for the input - these are all great suggestions.

 

[sdeb]

I was in the same situation but with a Netapp filer.

We needed to backup shares (without an NDMP option), I understand that you don't really like the script idea but it's not so hard (even to manage mounting of the share without somedbody logged in).

With a few scripts you can automate all those tasks in Networker with standard pre/post commands(it won't be as easy as controlling everyday backup but it'll work no so bad).

The major problem is to manage logs, you'll be able to get them but not into Networker logs.

Let me know if you want more info.

 

[esterud]

I have some experience with backup packages and the SnapOS. Though most of my Legato NetWorker for Windows experience is with GuardianOS SnapServers and you have a SnapOS Snap Server. Let me give some pointers. I hope at least one will help...

1) Make sure you are running the latest SnapOS version, I believe it is 3.4.803. Throughout the years weird SMB and Domain authentication issues similar to this have been fixed with new SnapOS releases. Despite this though maybe there is still a problem here.

2) Backup packages often do something just little a different than Microsoft in terms of SMB authentication to a network device. So maybe the Snap Server is not responding to NetWorker's authentication correctly and is hanging on to bigbeast's connection too long. To prove that the connection still exists despite "net use" and the Snap's WebUI Active Users list showing otherwise, do a "netstat -a" from bigbeast's command prompt it will show you more low-level connections.

3) When you map drives to the Snap Server map by specifying the superuser as &quot;YourDomain\superuser&quot; or &quot;superuser@YourDomain.com&quot;. This will force the Snap Server to realize that you want to connect YourDomain user. Though you might already know this, you can specify the user on a mapping of the drive easily via the command prompt with the command, &quot;net use <drive_letter:> \\snapserver\sharename /uOMAIN\DOMAINUSER &quot;PASSWORD&quot;

4) After this bug is experienced where the shares to the Snap Server are all getting &quot;Access Denied&quot; on a new map to it, try mapping the exact same network drive letters to the Snap Server with the exact user which was mapped previously (when you did not get denied). Then do a &quot;net use <drive_letter:> /d&quot; for every mapped drive letter to that Snap. Wait about 20 seconds then remap the drives and hopefully they will allow you to access them again.

5) If for whatever reason bigbeast tries to authenticate to the Snap with its Administrator user the Snap will likely try to authenticate instead with its own local &quot;Administrator&quot; user. Therefore if the password of bigbeast's domain\local &quot;Administrator&quot; user and the password Snap's &quot;Administrator user are different this may be creating a problem somewhere. First off make sure you do #4 to specify the user you want to authenticate. Second, make sure the user which is used to run the Networker services is the exact same user which you have used to map the drive letters to the Snap Servers. Given your last mentioned configuration I feel you should change the Networker services to start as &quot;YourDomain\superuser&quot;. However if you do this make sure that &quot;superuser&quot; is a member of bigbeast's local Administrators group as often backup services need to be started as that machine's local Administrator.

I wish you good luck.

-Erik

 

[Ticedoff]

Thanks to all that have tried to help.
Unfortunatly, nothing has helped. The problem still exists, and backups rarely and only randomly complete.

1) I have upgreaded all SnapServers to SnapOS 3.4.803. I was running 3.4.790.
2) The Legato processes are running as &quot;superuser&quot; on &quot;bigbeast&quot;. &quot;superuser&quot; is a user that I created, and is a member of every &quot;XXXX Admin&quot; groups I can find. This includes &quot;Backup Operators&quot;.
3) There is no &quot;local user&quot; &quot;superuser&quot; defined on any of the SnapServers.

I have noticed one additional interesting point - When a backup is successful, I look at the SnapServer &quot;Active Users&quot; and the list contains &quot;Backupuser&quot; instead of &quot;superuser&quot;. There is no &quot;Backupuser&quot; defined on the SnapServers or the Advanced Directory.

 

[Ticedoff]

I got it to work.
1) Make sure the Networker service is running as the user &quot;Backupuser&quot; on the Win2k Server that is supposed to be the &quot;host&quot; for backing up the SnapServer. &quot;Backupuser&quot; is a special user in the Domain and has special privleges.
2) Make sure the user &quot;backupuser&quot; is defined for &quot;Full Acess&quot; on all SnapServer shares & file systems - this is important.
3) Make sure you are NOT NOT NOT NOT useing a Win2k in &quot;Terminal Server&quot; mode as the host to backup the SnapServer shares. This will FUBAR the backup if anyone is logged into the Terminal Server & has a SnapServer share mounted when a backup kicks off. This used to cause the SnapServer to crash, now it just denies access. Now, the backup session will inherit the permissions of that user instead of the &quot;backupuser&quot;.

4) This exercise was enough to convince me to dump the SnapServers and host everything on a Win2k box.