5

I'm running the latest Cobian 11. I have a Synology DS412 NAS. All of my machines (Mac and Windows) access this just fine when I'm logged in and I browse to it manually.

I have Cobian installed as a service on two Windows machines: WinXP SP3 and Win7 x64. On both machines, the service is set to log on with my user account which is in the Windows administrator group. Backups on both machines fail with the message "Couldn't create the destination directory "\\nas1\backups\foo\bar\": The filename, directory name, or volume label syntax is incorrect".

  • I have tried setting the NAS's share to allow anonymous read/write access but it made no difference. Although I want the backups to run unattended in the middle of the night, I have tested them by running them manually while I'm logged in but no luck.
  • Before starting that, I make sure that I can browse to the NAS with Explorer to ensure that any authentication session with Windows and the NAS has not expired. Still no luck.
  • I have tried creating that destination directory both on the NAS before the backup and deleting it so the backup job could create it with the client's credentials but no luck.

The usual answer in the Cobian support forums is that there is a permission problem. I agree. But at this point, what can I do to diagnose this further?

  • is nas1 one the actual server name or is that a subdir? if it is the nas server name then mabye it should be \\nas1.. not \nas1 – tony roth Jun 15 '12 at 20:06
  • That must be a paste error on my part. I'll edit the question to correct that. Yes, nas1 is the hostname and the path given to Cobian begins with \\nas1. Just to see if there was some Cobian bug about path handling, I changed it to \\\\nas1 and reran it but this time it told me that "network path was not found". This tells me that it does find \\nas1. – DaveBurns Jun 15 '12 at 21:36
  • ok as your account can you do a "md \\nas1\backups\foo\bar\somedirname" – tony roth Jun 16 '12 at 4:03
  • @tonyroth - Yes. The mkdir succeeded, I can list the directory contents and move files into it. Immediately after the mkdir, I tried running the backup and it failed with the same error. My guess is that there's still something different about running it as a service, even though I've given it my same account to run as. Any other thoughts? – DaveBurns Jun 16 '12 at 14:29
  • 1
    the only difference between the two (service vs local account) is that the service would present a different security descriptor. Typically non microsoft devices do not respect the differences and I kinda feel like the synology wouldn't either. So far I don't have an answer. – tony roth Jun 17 '12 at 2:06
6

It is because you are running the program as a SERVICE. By default Cobian installs as a SERVICE. Re-install the program as a APPLICATION and the problem will go away.

NOTE: If you have created a few tasks make sure you Save/export them from the file menu before you uninstall Cobian so you can re-import them after the uninstall re-install.

  • Jack, thanks. Why would this be? I told Cobian to log the service in under my account, i.e. the same account that I log into interactively and can do all the things I mentioned above. – DaveBurns Sep 29 '12 at 16:50
  • BTW, I made progress with this problem by reinstalling Cobian as an application but the problem didn't go away 100%. My credentials still timeout after a few days and Cobian gives an error. The way to solve it is to log in interactively and go to \\nas1 which then asks me to manually authenticate. That lasts for a few days. It's better than it was but still isn't a proper solution. – DaveBurns Sep 29 '12 at 16:53
2

I am having the same problem. I found a ugly workaround, but works for me.
If anyone's interested, it's below, copied from here.

Hi !

To circumvent the Cobian behavior [to replace a foldername with it's UNC representation for a destination] one can do this:

Part 1, some config:

  • CD into the Cobian installation folder

  • create a directory, say mnt [like unix mount]

  • Use Cobian, open a task and change/create the destination as usual, to "C:\Program Files (x86)\Cobian Backup 11\mnt\toBackup" [don't worry ;-)]

  • after this, remove the "toBackup" folder in windows explorer

Part 2, create s pre/post job for the task.

a) pre-event

  • map a network drive, but just the UNC name, WITHOUT directory, like this:

    net use \remServer\remShare /user:username password [one may verify this through >net use]

  • use LINKD to map this network connection into the previosly created subdir [mnt]:

    mklink /d "C:\Program Files (x86)\Cobian Backup 11\mnt\toBackup" \remServer\remShare [regard the identical name for the "toBackup" destination]

If this has beeen executed in the pre-event, Cobian see's the remote drive in the local subfolder [for which it was configured].

b) post-event

  • rd /s /q "C:\Program Files (x86)\Cobian Backup 11\mnt\toBackup" [dont worry: This does not delete your files! {1}]
  • net use \remServer\remShare /d /y

Keep these commands in exact this order.

Everythings runs fine this way, because the cobian process does not need authentication. Note: This needs Windows7 or Windows Server 2008 R2.

An ugly workaround, but does the job. I can not understand, why Cobian can not directly open network connections to a server under a specific username. It is not that complicated.

Best regards,

++mabra

{1} Make proper tests. I'll not give any guarantee here. It was just working properly for me.

  • Mabra - thanks for the detailed comment. I'll give it a try. – DaveBurns Oct 1 '12 at 16:24
0

I found the solution on the Cobian Backup forum: Cannot create the destination directory - Results in "The filename, directory name, or volume label syntax is incorrect".

Make Windows open the share using credentials with write permission. This can be done as pre-backup event in the Cobian backup task definition.

To do this open a command prompt and type the following string - note values enclosed in <> are to be modified to suit your needs:

net use </PERSISTENT:YES> \\<SERVERNAME>\<SHARENAME> /user:<USERNAME> <PASSWORD_OR_*_FOR_PROMPT>
0

This worked simply by running the task using the administrator credentials. Find that in the Advanced options of your task. :)

  • Perhaps better to create an account with only needed permissions rather than let something run with Admin rights. As @curts notes, the vendor has a simple solution. – Dave M Apr 10 '15 at 15:25
0

Just add username and bassword to the "run task as another user" and enter the same username and password for the user that have write privilege. forum.cobiansoft.com.

0

I can solve the problem like this way:

http://www.cobiansoft.com/cobianbackup_faq.htm#24

Q: Installing the program as a service, I get an error in the log file. 
    The program cannot access a network drive. Why?

A: In order to access a network resource, the service cannot be running 
    as the local system account. One way to fix this problem:
  * Uninstall the program.
  * Install it again, but select the option "Use the following account".
  * Then you can enter a valid user ID and a password. This account must 
    have permission to access the network drive.

The other way:
  * Just go to the Options dialog box and re-enter the logon settings there.
-1

I resolved it by right clicking on the task, then Edit task, Advanced, Run the task with another user. Then I put username, domain, and password again, my Cobian started with this error when I changed the user password, before that it was ok.

-2

The same problem. It happend when a I lost my network connection to NAS. (reason was different time, Thecus vs. MS Server)

Try to restart servicees in Cobian menu

Menu/Tools/Options/Global/Button-ServiceAndAplicationCOntrol

stop/start - shadow copy - Mains systém services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.