Diagnosing permission problems with Cobian Backup to network share

Question

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 04: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 02:06

score 7 · Answer 1 · answered Sep 29 '12 at 09:28

7

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.

answered Sep 29 '12 at 09:28

Jack Johnson

71
1
2

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

score 2 · Answer 2 · answered Jan 02 '21 at 04:51

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.

This solved it for my QNAP NAS. – Pauloco Sep 24 '21 at 07:52 — Pauloco, Sep 24 '21 at 07:52

score 2 · Answer 3 · edited Sep 30 '12 at 18:56

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 01 '12 at 16:24

score 1 · Answer 4 · answered Jun 20 '17 at 14:31

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.

Robert · Answer 5 · 2021-02-08T09:39:29.483

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

the last option is "Advanced"

In the "Advanced" tab you can set the user for that task with the respective password

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

score 0 · Answer 6 · answered Oct 17 '14 at 14:30

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>

score 0 · Answer 7 · answered Apr 09 '15 at 20:34

0

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

answered Apr 09 '15 at 20:34

BDJ_Nerd

1

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

score 0 · Answer 8 · answered Oct 31 '15 at 23:38

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.

answered Oct 31 '15 at 23:38

Mohannd

119
4

score -1 · Answer 9 · edited Sep 02 '14 at 15:38

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

edited Sep 02 '14 at 15:38

89c3b1b8-b1ae-11e6-b842-48d705

1,465
1
13
22

answered Sep 02 '14 at 14:52

Arialy

1

score -2 · Answer 10 · answered Sep 29 '14 at 10:58

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.

Diagnosing permission problems with Cobian Backup to network share

10 Answers10

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