Windows Task Scheduler can't write to folder even when run as Admin

Question

I backup my Windows system partition using Macrium Reflect 6's backup schedule. The software adds an entry to Windows Task Scheduler and the backup usually runs without trouble. Since the backup location is a folder on an always mounted hard drive -- F:\Files --, I risk backup corruption if my computer gets infected (ie ransomware) before I can copy the files to an external drive. To deal with this, here is what I've done:

• I use the PC as a standard (non-administrator) account
• I've right-clicked the backup folder, gone to Properties >> Security >> Edit permissions, and clicked "Deny" under the "Write" permission for users belonging to the Users group.

My intent is to make it impossible for non-admin users -- and hence most malware -- to overwrite or corrupt the backup files. The restriction took effect as I expected: for instance I now need to enter an administrator password if I wish to write a file to F:\Files. The problem is that the backup job now fails. In Macrium UI, here is the error I see:

Backup aborted! - None of the specified locations could be written to

I'm surprised by this error because I think the task is set to run as the Admin account; when I setup the backup job in Macrium I was explicitly asked which user account should be used, and to enter that user's password so I chose Admin. As a result I expected the software to have no problem writing to the backup folder even after I revoked write permissions from non-admins. If I open up Task Scheduler and look at the task details, here is what is shown under Security options:

As you can see, the task is run as Admin. The author of the task (not shown in the screenshot) is also Admin. The action of the task is:

C:\...\Reflect.exe 
   -e -w "F:\Files\Schedule.xml" -inc -g {some long token here}

Am I overlooking something or is this a bug with my backup software? The last run result in Task Scheduler shows simply (0x1)

---

Upon further investigation, I discovered that if I log in as Admin and try to write a file to the restricted folder, I can't. Denying Write perm for the Users group also denied it for the Admin account. This is probably why my backup job is failing. The image below shows the Effective Permissions for Admin after I deny write permissions to the Users group.

I also discovered that although blocked accounts could not save a new file to the folder, they could still delete the files already present. So I was still vulnerable to malware deleting these files. I needed more restrictive permissions. I also need to find a way to deny perms for all non-admin users, but allow it for admins.

Here is what I did

Instead of denying permission for the entire Users group, I decided to try denying permission for only the account I use day-to-day.

From the folder Properties screen (right click the folder and select Properties):

1. click Advanced
2. click Change Permissions
3. click Add
4. type the account username I want to restrict
5. click Check Names: the fully qualified username (eg: MyPC\John) should auto-populate the textarea
6. click OK
7. A popup that allows to set permissions granularly for the selected users should open. Here is what I did with mine:

Most importantly, I denied all Write, Delete, Change permissions and Take ownership permissions. Now things seem to be working as intended. With my day-to-day account I can neither write, nor delete files in the backup folder. However as Admin I can do both. A manual backup just completed successfully as well so things seem to be OK. I'll know tomorrow whether the scheduled task runs without trouble.

This is still not the fix I'm looking for

What I'd like is for all non-admin users to be restricted. My solution blocks just one non-admin -- MyPC\John -- but if another non-admin profile were created (or maybe even if my username changed?) the restrictions would be bypassed. I'm looking for something closer to the protection on C:\Program Files directory: I'm always blocked from making changes there if I'm not an admin.

Solution 1

Instead of trying to block certain user accounts, just give permissions to the accounts you want to run the backup task. You can allow the entire Administrators group, or only certain administrative accounts to run the backup tasks. In other words, there's no reason to DENY any account, or group of accounts, because they will already be denied if there's no entry in the permission list giving them access.

Solution 2

What is happening? (Part 1)

“Deny” is very dangerous.  If a user / process has both “allow” permission and “deny” permission, it is denied access.  The problem here is that your Admin account is covertly a member of the Users group.  You can see this if you run whoami/groups from a Command Prompt running as Admin.  (You may find the output more readable if you type whoami/groups /fo list.)  I say it “is covertly a member of the Users group” because I found two or three other ways of checking which users are in which groups, and they didn’t show that the Admin user is in the Users group.

What is happening? (Part 2)

Take a closer look at the permissions on the directory now.  I found this for the root directory of my C: drive:

          

“Authenticated Users” have a lot of access!

What to do?

Use kreemoweet’s answer.  But first, figure out why you have write permission to F:\Files.  Look at its permissions , and those of the root directory, F:\.  Look for “Everyone” entries and “Authenticated Users” entries, and find the entry that’s giving you write permission (through checked “Allow” checkboxes) and uncheck them.  Do not check “Deny” checkboxes.

Let me expand on that.  You will probably find an access control entry for F:\Files that gives you write access.  If it’s “<not inherited>”, you should be able to edit it directly.  If it says it’s inherited from F:\, you’ll probably find that you can check checkboxes that are blank, but you can’t clear any of the ones that are already checked (and they are grayed out to indicate that).  Uncheck the box that says “Include inheritable permissions from this object’s parent”:

If you get a pop-up like this:

      

select “Add”.  You should now see that all the permission entries for F:\Files are “<not inherited>” copies of the entries that were there before.  Now you’ll be able to fully and freely edit those permissions, and uncheck the boxes that are giving you write access.

Then, when you’ve turned off write access for non-administrator users, go in (to the same ACL; i.e., for F:\Files) and add an entry to give write access to the “Administrators” group.

An alternative
I haven’t tried this, but: in addition to the “Admin” account you created when you booted into Windows for the first time, there is a builtin account called “Administrator” that is disabled and hidden by default.  Instructions to unhide and enable it are easy to find, here on Super User and elsewhere.  You might find that “Administrator” is not a member of the Users group, and that you can run your backup as “Administrator”.  But try kreemoweet’s answer first; I don’t know whether this one will work.

Comments

[Ramhound]

Provide the path your trying to write to.

[BeetleJuice]

@Ramhound F:\Files

[Moab]

Are you running Macrium Reflect as Admin? Right click on the program executable and select properties, Select compatibility Tab and tick the "run this program as an administrator" hit ok to save changes, see if this solves your issue.

[BeetleJuice]

@Moab The backup is run as a Task Scheduler task, not from the Macrium UI. Macrium is not even running when the task is launched. It is the task that starts the Macrium process, and the task is set to execute that process as Admin

[Moab]

I would still do as suggested, Taskscheduler sill runs the MR executable.

[BeetleJuice]

@Moab I'm sorry but your suggestion didn't work because even the Admin account did not have permission to write to the folder, so the backup failed anyway.

[Moab]

Change permissions on the folder it is trying to write to.

[BeetleJuice]

Yes you're right @Moab; I've already done that though (take another look at my question); that's how I ran into my original problem while trying to restrict write access. So the question is "how should I set permissions?" The answer I wrote up provides one solution that works.

[Ramhound]

@Beetlejuice - The answer you wrote up was deleted. Most users can't even see it. The reason it was deleted is because, you provided the solution, then indicated "it wasn't what you were looking for". Answers are answers, if you find yourself asking new questions in your self-answer, don't add those questions.

[BeetleJuice]

This is a bit confusing. Before I started denying folder permissions, all accounts could modify the backup directory or run backup task. I never needed to actually give permission to run the task. Thus if I remove my "deny" rule, there will be no restriction on who can corrupt the files.

[BeetleJuice]

Also please note: if I don't deny any permission, then regardless of who actually runs the backup job, the regular user account would have full access to the backup files. Any malware -- acting as the current user -- would be able to corrupt or delete my backups. This is what I was trying to avoid in the first place.

[Ramhound]

@Beetlejuice - Which is the reason you should allow access to specific users instead a user group. Of course you do understand, none of this, will prevent ransomware from still running. If you download and execute ransomware its already to late to prevent it.

[BeetleJuice]

I understand it won't prevent ransomware from running. But if the ransomware is acting as the logged in user, this would prevent it from encrypting my backups. So although I wouldn't have prevented the ransomware, I would be able to recover from it pretty easily by restoring from backup. As for "allow access to specific users instead of a user group", please explain with an answer if you care to. I never proactively allowed any user group; by default, users can modify the folder -- so this advice confuses me a bit.

[BeetleJuice]

Thanks for the write-up Scott. If I uncheck Allow at the drive root F:`, wouldn't it prevent non-admins from modifying files anywhere within that drive? I'm trying to restrict only the backup directory F:\Files`.

[Scott - Слава Україні]

@BeetleJuice: I have edited my answer to clarify that. … … P.S. Use double backticks (e.g., ⁠`⁠`F:\`⁠`⁠) to get a code-formatted backslash (\) in a comment; e.g., F:\.  The facts that comments follow different formatting rules from posts, and that there is no preview for comments, are long-standing problems here.