I feel this may be more widely wanted than the two topics mentioning “UNC source” may indicate.
I don’t even know it this is possible to implement and I know it’s not very efficient (what with having to copy entire changed source files to the local box for having) AND there have been issues with the GUI during restore (Restore GUI not working correct with UNC source) but I figured I’d bring it up to see how much interest there really is in using UNC as a source.
+1
It would be a very handy feature so that devices such as NAS shares could be backed up.
+1
I’m using UNC source ( \\ network Windows share) on domain computers with AD permisons and it’s working fine.
But if I could specified credentials, I could use same scenario for example on Synology install. And that would be very useful.
Good point - I should clarify that this doesn’t mean UNC sources don’t work at all right now, just that they need something else (such as Active Directory) to handle the authentication.
I’ve had some luck on tray icon just filling out “Optional authentication username” and “Optional authentication password” on the “Local folder or drive” destination. With Windows Service though, THAT challenge creeps in. Basically I’m curious how @mr-flibble is running, and whether @JonMikelV has no success with my method.
@ts678 In default setting, service runs under SYSTEM account.
SYSTEM account act on network on another devices as COMPUTERNAME$ accout (with dolar sign)
You can share folder to this account and Duplicati in service mode can acces it.
Another way is change service account to something else.
@ts678
That’s interesting. I just tried that on Synology, sadly it did not work. Maybe I would need another syntax for the shared folder path. BUT you give me the idea how to do it on Synology.
I can mount CIFS folder and then select mounted folder as backup source - and it’s works 
Thanks 
Jon is right. Only AD authenticated shares will work and shares which are authenticated by having their credentials saved in the Operating System credential manager or key-chain work at this stage. This is because the SMB protocol has its own authentication mechanism and that isn’t implemented into Duplicati at this stage. My work around for this is to use the ‘cmdkey’ command in Windows in a pre and post backup script to temporarily add and delete the credentials during backup run time.
So you’re using something like this in your pre/post scripts and just taking the hit on password being in script files?
net use \\myServer\myShare /user:myUser password
net use \\myServer\myShare /delete
Have you tried saving it in the Windows key manager to avoid needing the scripts? (Granted that lets the account access the share even when not backing up so I understand if that’s not your goal.)
Control Panel → Users → Windows Credential Manager & enter credentials with the device name (myServer)
I have an issue with my NAS where I have shares which are accessed by different users. Saving them in the credential manager makes my jobs to fail. So I use the above from my management server which only I have access to.
Maybe workaround for some NAS devices could use some other service than SMB as source? For example FTP?
SMB is what the users access on various workstations on the network. But all the shares get backed up from a central server and while I could muck around with different protocols, it seems it would be just as messy as my solution where I back up each share as a separate job with pre/post scripts.