Using the duplicacy service (with VSS) to back up to a network share

[noel.t.forte]

I’d like to be able to use VSS (which of course requires admin permissions as described here: Duplicacy Issue: VSS in Windows?, or here: Vss option in Web Gui) to back up files in use on my computer, and saw that duplicacy has the ability to run as a service. Unfortunately, installing duplicacy as a service and then trying to access the network share presents this error:

Failed to check the storage at \\share\path\to\storage: Failed to load the file storage at \\share\path\to\storage: CreateFile \\share\path\to\storage: The user name or password is incorrect.

I’ve tried creating the storage when connected and running duplicacy as my own user account, that works fine, its just that as soon as I switch to using the service, it stops being able to connect. I haven’t tried running it as administrator though, would that be preferable?

Thanks for any help!

[saspus]

Admin/system account obviously does not have credentials to access the network path – only the user does. But this is just the tip of the iceberg. Even if you gave access to your share to admin account, you will hit another snag: window cannot keep connections to the same server with different credentials, so this is a no-go. This is not specific to duplicacy, it’s windows schizophrenics. CrashPlan at some point offered unsupported hacky workaround, but today they just say The Code42 app doesn’t support backing up mapped drives on Windows, including network drives that are mounted by a user. This is due to a restriction built-in to Windows at the operating system level.

Some backup tools workaround this limitation via some trickery: for example, ArqBackup launches the special process (arqreader) impersonating the user that mounted the share to fetch the data and pass it to the backup daemon that runs as a system account. Duplciacy does not do that, as of today.

What can you do?

1. Mount the share with some other protocol; say inside pre-backup script mount the share via SFTP, or WebDAV, or NFS, etc into temp location, backup, and then in post-backup script – unmount.
2. Run another instance of duplicacy under user account to backup the windows share, since you don’t need vss for that.

[noel.t.forte]

Was able to get it working by starting duplicacy web as the admin user rather than running it as a service. For whatever reason running as administrator in your own user account allows for credential manager to provide the credentials to the process but running as a service credential manager can’t. Tested a backup and restore with VSS and it worked fine, no issues.

[saspus]

You are essentially running as your own user account, but with elevated permissions, not as admin user per se. This will work of course, but only for this one user, you won’t be able to backup drives mapped by other users. If you are the only user that maps drives – then it’s the viable, albeit ugly workaround

[noel.t.forte]

Ah. That makes sense. Firstly, I’m backing up my own personal computer, so I’m the only user on the system. Second, I’m not mapping any drives to access the share, just connecting to the share URL directly from duplicacy. But good things to consider in case I ever have to do this in a multi-user environment!

[saspus]

@noel.t.forte

I’m not mapping any drives to access the share, just connecting to the share URL directly from duplicacy.

Just to clarify – the problem is not with mapping itself, but rather maintaining multiple connections to the same server with different credentials. Here is the support article about it Cannot use different credentials for a network share - Windows Server | Microsoft Docs. From the suggested workarounds there, you will see how idiotic the limitation is. (sorry for my wording, I simply can’t get over the fact that this is broken for years, and yet they still haven’t fixed it, even though it’s Microsoft who designed the SMB protocol in the first place. Ugh. Why fix it when you can just say “This behavior is by design.”. I’m so happy I don’t have to deal with windows on a daily basis :))