This might be more of a Windows issue versus Duplicati, but sharing anyway.
I shared a folder in Windows across two users. User A has full control = allow. User B has full control = deny.
In my Duplicati backup, I opted to test permissions by setting it to use user B’s credentials. Oddly, I’m still able to write to the directory as if the deny permissions aren’t in effect. How can this be?
FWIW, I’ve restarted Windows multiple times.
If I try to view the shared directory via Windows Explorer, the permissions do work correctly (user A = full access, user B = “Windows cannot access [share name]”). Is Duplicati connecting differently than Windows Explorer would?
I tested some additional configurations:
“Everyone” only - full control = deny (results: Duplicati fails)
User B only - full control = deny (results: Duplicati fails)
User B - full control = deny AND user A - full control = allow (results: Duplicati writes…)
User A only - full control = deny (results: Duplicate writes…)
What user is Duplicati running as? If it’s running under User A, it should have access. Only if Duplicati was running as User B should the deny permissions take effect.
What are you trying to prevent User B from doing?
Is the share the source or destination?
Along with what besweet asked, I wasn’t quite sure what this statement meant. What was set to user B’s credentials? Where/How?
I don’t recall any questions in the restore process about user. I’d double check but my Windows Duplicati instance is currently doing a purge of some files that is taking days (3000 versions to work through!)
Ah, got ya. Hopefully someone on here knows more about how Duplicati’s backup setup user/password get used in the backup operation when the destination is “local” storage that happens to be a share.
How are your users set up on the server (that is exporting the share) vs the Windows system? Depending on how you’ve got that and the share setup (especially if they’re feeding off the same source for authentication), looking at who owns the backup files on the share may tell you something about what Duplicati is doing.
It’s a standard Windows 10 Pro PC with a specific drive configured as a network share where one user has full allow access and another user with full deny access. That’s about it.
Duplicati is doing exactly what it should, the SYSTEM account bypasses all ACLs. You’ve limited User B but Duplicati is running as SYSTEM which is a completely different account with significantly different rights. Please for your computers sake, do NOT try to muck with SYSTEM rights, that’s not going to be the fix.
Sadly, there is no easy way to prevent a user on the localhost from accessing the GUI (short of password protecting Duplicati’s GUI but that’s not really secure anyways). A local proxy or maybe some good ol’ host file entries but off the top what you’re trying to achieve, will take more than just modifying user folder permissions.
If Duplicati was running under each respective user (User A & User B) vs as a service then the folder restrictions would take place because Duplicati would be just as limited as the user. The GUI would still be available as before but User B wouldn’t be able to write to the destination or possibly more important wouldn’t be able to delete the contents of the share.
I configured Duplicati as a service which uses SYSTEM by default. I did this so that I can set --snapshot-policy = required allowing locked files to still be backed up.
What other user can the service run as in order for this to keep working? Note that user A is never meant to be logged into via Windows, leaving user B as the one that can actually sign in (but doesnt have any access rights to the shares).
Actually (thinking out loud)… I believe I can input the credentials for user A while configuring the service, so i think it should work regardless of whether anyone signs in.
The computer I’m backing up to (over the network) is the one with the SMB shares and doesn’t even have Duplicati installed. The one I’m back up from has Duplicati running as a SYSTEM service.
Are you saying that any Duplicati client on the network that’s running as a SYSTEM service can force-write to any SMB share regardless of ACL permissions?
if you want to backup the computer and do snapshots on it you have to get admin (or backup) rights, so SYSTEM account is the default option. However it is making unwieldy, if possible at all, to access a remote share.
I have my ready to sell solution: don’t use SMB at all. It’s possible (it is said so at all, I have only done it on Windows servers) to install SSH on Win10 pro. With SSH comes SFTP. Unless you need extreme performance you could be better off with this solution. And it gives some additional protection against your computer being hacked and starting to encrypt the disk AND accessible shares, because there is no share for backuped data.
I actually really like that idea. I dont need the greatest performance since, aside from the initial backup, future incremental ones are typically going to be relatively small (probably under 100MB). Thanks.
I probably should have asked if this was a domain environment or a peer-to-peer workgroup. I’m presuming p2p and p2p security is generally horrible as both users need to have matching usernames/passwords to gain properly defined access to secured resources.
If you didn’t define matching users and passwords on the SMB host machine then you’re gaining access to the share via some other permission like Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings\Password protected sharing, which if disabled, by-passes user checks, explaining why it works regardless of who is running the job.
The SYSTEM account is local to each host and is not used for any kind of network authentication, this further points to the likely hood that Password protected sharing is disabled and that’s how access is being granted and denies being ignored.
I’d love to see both the share and file ACLs on the host machine but I think @gpatel-fr makes a very good suggestion that’s probably much easier to implement and maintain.
This morning, I considered going the SSH route, but I think I’ll leave the set-up as is (SMB). It’s all used for a personal home setup where several computers copy files to this centralized location. Nothing is accessible outside of the network and there’s nothing confidential / mission critical available (plus, all the backups are encrypted and all passwords involved are complex) so I’m not worried about anything malicious happening.
Looks like this is all set, but for completeness - I think the original confusion was “Why isn’t Duplicati doing its backup using the user specified in the backup destination configuration screen?”
Presumably the answer is that Duplicati uses that user/password to connect to a share if the share is not already mounted on the system running Duplicati, vs doing its work as that user. Some similar discussion (and that answer) here: [Cannot access network folder - #5 by JonMikelV]
Nice level of discussion. Not my expertise, but I’ll throw in some opinions and things that I found on it.
I think I’ve hit that pain point. I don’t have a domain at home, but your question on that is great as well.
This is definitely more predictable (in my little experience) than trying to do SMB. A service gets worse, and authentication gets worse than that, and trying to switch authentications is another layer of trouble.
I suppose you could try that on Options screen 5 (screen 3 tends to lose options) to see if anything changes, but also make sure the one-and-only service process winds up with right identity on SMB.
The equivalent of force-smb-authentication could probably also be done with scripting options.
That helps, because a multi-user system using Duplicati that needs to run VSS snapshots requires privileges with broad local access as well. I think even Administrators group gets a lot of access, because typical ACLs on Windows are set that way. This can be changed, but who’s going to do it?
You can only use one set of credentials to connect to SMB Shares from the one session. Clearly Duplicati is connecting using UserA credentials. This establishes a connection to the share from UserB Profile with UserA credentials. If user B opens the share from Explorer windows will use the already established connection under UserA credentials
To workaround call a script before and after using net use to create and the then delete connections to the share.
that code is done at Pre authentication. This will close any current connections to the share and connect using UserA credentials for Duplicati backup job to run.
Once the backup completes the connection needs to be disconnected as well. I dont think this happens by default thus leaving an open authenticated connection to the share on the system until such time as UserB logs off the system.
