Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1365
  • Last Modified:

SyncBackSE Scheduled task fails, but running the task manually does not?

I have a Windows 2003 server with 4TB data that I want to Sync with a NAS on a daily basis after our daily backups have run. By suggestions from EE I have bought SyncBackSE and I do like the program for it's versatility and ease of use.

There is just one issue. I created a task for Sync of our development data and ran a test. It went fine with no errors (except of course access to open files since I was running the test in working hours). I have tried running the task Friday afternoon when noone was left in the office and that went fine too, and copied all the files to the NAS.

When I scheduled the task to run, I get the below error in the log:

Log Report: Overview  
Profile Name: Development to NAS Type: Mirror Right
Unattended: Yes
Username: MyDomain\DomainUserName Computer Name: SERVER
Log Report Errors and Warnings:
"Cannot connect to NAS : Logon failure: unknown user name or bad password."

Now that in itself is quite explicit as an error message, but I can't figure out where the difference is, from SyncBackSE's point of view, in the credentials it usses on a job started manually, and one that is Scheduled.

this is the crux of the erro as I see it, but maybe I'm just looking in the wrong direction.

As you can see from the log message, we have a Domain, and the username for the scheduled task is currently mine (will be changed to a static account once this is up and running) and the access to the NAS is with the admin password I created for the NAS (same as i used to map the NAS as a Network drive).

When I setup the job, I had the NAS mapped as a Network drive on the Server that has the data for replication and has SyncBackSE installed, and when I selected the destination drive as the mapped NAS drive, SyncBackSE suggested a UNC path instead, and I followed that advice and let it keep the converted destination name.

I have a very annoying feeling that this has an very easy fix, but I just can't see it...

Best Regards
Panthom
0
Panthom
Asked:
Panthom
  • 6
  • 4
2 Solutions
 
noxchoGlobal Support CoordinatorCommented:
Hi Panthom, is the task handled via Windows Task Scheduler?
If yes then find there in Task Scheduler your task and specify there Run As options. You will need to provide admin or another account with admin rights. Since then when the task time comes it will login as admin user and perform the necessary sync. I have never use SyncBackSE but most of similar applications work this way.
0
 
PanthomAuthor Commented:
Hi Noxcho

Apologies for the late reply.

It does indeed run via the Windows Task Scheduler, but the user we use is a domain user we use for static operations.
Are the permissions the ones needed to execute a Scheduled task on the server, or the permissions to access the NAS (which is not in the domain).?

Best Regards
Panthom
0
 
noxchoGlobal Support CoordinatorCommented:
Task scheduler runs under definite user. If you give to this user (lets create additional user and give it permissions of administrator plus permissions to write\read to share on NAS) proper rights then it should work.
0
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

 
PanthomAuthor Commented:
Hi Noxcho

Since the NAS is not in the domain the user/pass typed in the run_as field in scheduled tasks cannot be the one to authenticate towards the NAS.
But in SyncBackSE you type in credentials for the target destination folder, so one would think that the scheduled task only asks SyncBackSE to perform "duty - sync" after which the actual settings typed into SyncBackSE should take over... yes?

Best Regards
Panthom
0
 
noxchoGlobal Support CoordinatorCommented:
I think the Task Scheduler settings ignore the SyncBackSE settings.
Again give to the user you run task under the read\write permissions to NAS. Or map the share and see if it works.
This is just suggestion.
0
 
PanthomAuthor Commented:
Hi Noxcho

When setting up the Sync job in SyncBackSE, I choose the mapped network drive that I made for testing connectivity and permissions to the NAS. SyncBackSE then converts that to a \\NAS\Folder\Subfolder address and since this works manually, I don't see what to change about that.

Best Regards
Panthom
0
 
noxchoGlobal Support CoordinatorCommented:
So manually it works. But fails to run scheduled works. Dig into Task Scheduler. Do you specify the same user in Task Scheduler you do in Sync?
0
 
PanthomAuthor Commented:
Hi Noxcho

I'll look into this some more Monday, or maybe this weekend if I can free some time for it.
There is a message in SyncBackSE stating that the user credentials are not the same, but they are if I use my username/password, so that message only corresponds to the currently logged in user.

Best Regards
Thomas Petersen
0
 
PanthomAuthor Commented:
The problem was caused by a "ghost" mapping from a remote login session on the server, that also had credentials for the NAS registered, which Task Scheduler chose to use instead. I could reproduce the problem by logging in remotely again, and map the NAS.
If I left the session without logging out, the SyncBackSE scheduled task would fail again.

This issue is resolved.
0
 
PanthomAuthor Commented:
This question was a long time in completing because I haven't had time available to dedicate to this issue before now.
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now