# Diagnosing permission problems with Cobian Backup to network share

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
• 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

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

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

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.


If you are using a cloud storage device, like WD Cloud, instead of a domain related server, all you have to do is make sure to match the SAME username AND password on both systems. That is, create a LOCAL user, like "BackupUser" with a password, set that as the login user for the Cobian service, then go to the cloud device and configure the SAME username and password there as well when securing your cloud shared folder. This allows Cobian to run as a Windows service, which is better because a local user doesn't need to be logged in to keep your machine backed up.

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>


• 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

## Cobian 11 how to backup on NAS share and any other network share

Just wanted to remember all of you that in each and every single Cobian' backup task

Note: not necessary to have that user name in the current Windows environment

If these fields are filled, in the log you'll read THIS user loggin into the remote share

No matter if you run Cobian as Service or as Program

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.

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