Hello, I have had Duplicati 2.0.5.104 running as a service for some time now, making daily backups to a network share. This week my computer updated to Windows 10 release 2004, and ever since then Duplicati is unable to connect to any Samba shares, including the one it had previously been working with. If I stop the Duplicati service and run Duplicati as under a user account instead, I am able to connect to two different file servers on the network without problem. But not when running as a service. I tried updating to 2.0.5.107 to see if that would help, but no dice. Backups are running fine to a remote OneDrive for Business account.
Does anyone have any any tips?
Does Duplicati use its own Samba drivers or does it use the built-in Windows SMB platform?
Hi there, it runs as LocalSystem, which is was set up at the beginning (and was working until this week).
I have restarted my computer a couple of times and restarted the remote device, but nothing seems to make a difference. It doesn’t seem to be able to authenticate or something: when I go into the “Destination” screen and click “Test connection,” the system says “Folder … does not exist. Create it now?” But the folder does exist. And neither can it create new folders. Duplicati just doesn’t seem to be able to read the remote share at all, regardless of the username or password I enter (all good usernames and passwords).
LocalSystem typically does not have access to any network resources. But it MAY work if the network share allows anonymous or guest access.
You could try tying the service to a certain local user account, one that is valid on the remote network resource (eg, same username/password is on the remote machine/device). It may be more reliable.
Interesting. I guess this brings up a big question. What SMB stack is being used by Duplicati on Windows when connections are made? If it is using built-in authentication, how does the configuration allow for alternative usernames and passwords? I can confirm that these alternative usernames and passwords do allow you to make SMB connections on accounts other than those made by the OS. Let me use a scenario to illustrate how this is happening…
I start by using Windows Explorer to open a remote folder USER1-SHARE on REMOTESERVER under the remote user account USER1. However, all of my backups are stored in a different remote user’s shared folder, USER2-SHARE, and USER1 can’t access the USER2-SHARE. So in Windows, I can open REMOTESERVER\USER1-SHARE and browse the folders. But if I try browsing to REMOTESERVER\USER2-SHARE, access is denied, of course, since my SMB connection was initially authenticated through USER1.
However…in Duplicati, I have configured the backup to network path \REMOTESERVER\USER2-SHARE and set authentication user/password to USER2, and the backup runs fine. Until last week, this had been working fine using the LocalService account. That’s one strangeness that I don’t understand. The other weird thing is that when I run the service under my own user account, whose connection to REMOTESERVER is already authenticated under USER1, I can run the backup job using the USER2 connection, and it works fine.
So this leads me back to my question: does Duplicati use its own Samba drivers to make these connections? Or is it using Windows’ SMB stack? Based on my illustration above, it appears that Duplicati is launching its own SMB connections which bypass Windows built-in authentication, and this would explain why I was able to do these backups before under the LocalService account and why it also works with a separate user account when running the service under my own user account.
I apologize, for some reason I was thinking you were backing UP network shares (remote data). I see you are backing up TO a network share
I believe that should still work even if Duplicati is operating as LocalSystem as you are setting credentials on the “Destination” page of your backup configuration.
Duplicati is just using the underlying Windows OS to handle reading/writing data to the “Local folder or drive” type destination, which does support UNC paths on Windows. Duplicati does not contain its own SMB implementation (eg, Samba).
Okay. So any tips on how to get this working again under the LocalSystem service account? I don’t know why it suddenly stopped working after the update.
I don’t believe that is the problem. SMBv1 is disabled by default on fresh Win10 installs since 1709, I believe. In any case it’s more likely something doesn’t work by having it disabled (if the remote side doesn’t know how to speak SMBv2 or 3).
In my case I reproduced the problem with a NAS on the remote side that knows how to speak SMBv2-3.
I have tried it with and without SMB 1.0 and it didn’t seem to make a difference. At any rate, the service works when running under my own user account, with or without SMB 1.0, even when I use a different username and password to make Dulicati’s connection to a share that is inaccessible on the desktop due to Windows Explorer being logged into the file server under another account.
I am having the same problem. Definitely started after a windows update.
Duplicati, running as a service, can no longer connect to my configured destination. When I try “Test Connection”, it says the destination does not exist, asks me if I want to create it. If I reply yes, it errors out. And when running the backup I get Duplicati.Library.Interface.FolderMissingException
However, I have no problem connecting from a command window using net use \\myshare\mylocation password /user:myuser to connect with the configured credentials (which is different than the logged in user).
The same configuration was working fine two weeks ago. I had upgraded to Windows 2004.
