I have two scripts to write log entries to Windows event logs and (if applicable) close outlook prior to running the backup.
On this particular machine the scripts will run as system with no problem… they will run in a user space with no problem, but when run as a pre and post script for a Duplicati job, they create a failure in the Duplicati log with the result of “access is denied” and cause the job to have warnings.
These are the exact same scripts I have used on other Windows implementations of Duplicati without issue
I have attempted the following to resolve without success:
Allowed full permissions to the scrips folder to all users, system and admin users
Changed the user running the Duplicati service
Made sure there were no User session Duplicati instances running
Made sure System acount has full control to Duplicati folder in Program Files folder
Changed the contents of the script file to write log files when executed to see if there were any internal errors (no output redirected when run through Duplicati job)
Made System account interactive and then changed it back
I am at a loss as to where to go next… any help is appreciated.
I can run in either administrator or user space (with or without elevation), and the script throws no errors, completes the functions within the scritps (eventcreate & taskkill) and closes.
Only when run from a job is it apparently having a problem. I am starting to suspect that the launching of the job itself is actually the problem, not the script.
I have used process monitor before, but I am not certain how I would use it to troubleshoot this particular problem.
A little further troubleshooting information:
I modified the script to include one line… a REM statement. Nothing else. Same error:
2022-02-14 08:21:56 -05 - [Warning-Duplicati.Library.Modules.Builtin.RunScript-ScriptExecuteError]: Error while executing script “C:\Scripts\Duplicati_Pre.cmd”: Access is denied
I have to interpret this now as: I am sorry, Duplicati Service does not have the permissions to execute that script.
I had already removed the installed AV in an attempt to remove any impediment from a perceived technically bad standpoint (programs executing programs).
C:\Scripts>duplicati_pre
C:\Scripts>REM Testing Execution with no commands
C:\Scripts>whoami
nt authority\system
C:\Scripts>
Yep, I agree with your conclusion. It must be that it can’t launch the actual script.
Changed the contents of the script file to write log files when executed
And sorry, I just realized you actually already did the suggestion in my earlier message.
Allowed full permissions to the scrips folder to all users, system and admin users
Looks like you have Duplicati configured to run as LocalSystem, so having SYSTEM in the ACL with read+execute should be all you need.
The only other thing I can think of is maybe it is some sort of antimalware software that is preventing it from running. But that doesn’t really make sense since you can run it manually.
If you suspect a Duplicati access issue to a little-read file, maybe filter Path with a contains of script.
Process name filter might work too, but would give a lot more output, so might be a second approach.
I suppose you could Export As Command-line and run from there, if you haven’t tried that combination.
I’m not sure why it would differ from a service running as Local System account, but it’s another test.
There are some fine-grained views available. A lot of clicks, but right-click → Properties → Security → Advanced → (select a user) → View → Show advanced permissions. An example from my system is:
The only thing this tells me is that the file system tried to open the file and it got smacked down.
Since the ShareMode is Read& Delete, I wouldn’t think something had it stuck open in write mode.
I checked the RSOP style permissions check and the System account result was all permissions allowed.
I don’t think it’s a permissions issue.
WebRoot is installed, and right after this call (0.001 seconds later) so I put in an exception in webroot thinking maybe it was opening it for review while the access was attempting and it failed for some reason.
The only other oddity are the calls before this is a call from Duplicati to a registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Duplicati_Pre.cmd which it didn’t find, and just before that is six calls from Duplicati Service to open and read the script file that succeeded where the share mode was read, write, delete instead of just read, delete. Two opens, two functions, two closes.
6:32:07.9436942 PM
Duplicati.Server.exe
8444
CreateFile
C:\Scripts\Duplicati_Pre.cmd
SUCCESS
Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
If that looks too dangerous, you can safely check if your filter drivers look the same on different systems. You’re apparently having this run fine on others, but on this one it can do the backups but not the scripts.
How’s your PowerShell? I think it (like Duplicati) uses .NET Framework so might be able to repro issues. Start-Process might be similar to the Process.Start that Duplicati runs below before it gets the exception:
Now that Process Monitor is working, although still hard to interpret, you could try running something else, such as a harmless .exe file, perhaps a copy of some benign Windows command-line-suitable command. Looking in C:\Windows\System32 I see whoami.exe which is happy to run without any arguments. This is good because Duplicati can’t supply arguments, so usually people have to put the arguments in the script.
The .NET Framework program starter also prefers .exe files, but will do .bat files. I had to test if it could start a cmd file, and it did here, but you could check file associations and different kinds of program types.
Although it’s not the same as running a script, you could see if Duplicati can access the folder for backup and restore. You could also test other folders, maybe even test a FAT32 filesystem on a USB thumb drive.
NTFS is complicated and I don’t understand it completely, but you can get it out of the way by not using it.
I see another post being written now, so maybe it will do better than I’m doing.
Are the scripts you’re running PowerShell scripts and if so have you enabled the execution of scripts? set-executionpolicy remotesigned You can manually run a .ps1 without changing the policy but it won’t run on it’s own unless the executionpolicy has been changed from the default.
Did you have the service running under the “Local System” account or as the local “System” account? The first should just work, anything else would require a bunch of permission modifications and still probably won’t be enough, landing you right where you are.
I had installed Sentinel One days earlier as I didn’t see anything in the system tray on that device… My reference initially was to the removal of that product. It was only later (when looking at the Process Monitor output) that I realized they must have Webroot on there too (I just took over support of these computers). I am really glad that the double stack didn’t conflict (usually two stacks bring a system to a snail’s pace), but it left me with the incorrect impression there was nothing else installed.
I gained access to the WebRoot management interface for that company and saw that the agent was checking in.
Thank you for your patience and help, it is much appreciated.