Scheduled task not working on Windows

[v-tron]

Created a scheduled task on Windows which does appear in task Scheduler but does not seem to do anything. Running the task manually shows its running but there is no indication in the logs that the task has been run. I am using the GUI exe.

I had to alter compatibility settings of the exe to run as administrator since it kept throwing VSS errors when run without admin permissions.

Also can someone tell me where the Installer went thats referenced in some older versions of the Readme? I would like to install the program into program files.

Version 3.0.4

[deajan]

Greetings, User !

I'd need to get a bit more context for the scheduled task.
Did you create it as admin user ?
What user does it run as ?
Could you perhaps export the task as xml and post it here ?
Could you provide the corresponding logs ?

With all this, I could get a CLU of what happens.

For the installer, I removed it since it was merely another python script that copies the files to Program Files.

[v-tron]

Hi, sorry for not getting back to you in a while. I have obtained the XML of the scheduled task that the NPBackUpGUI.exe created:

<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2023-01-01T13:37:00.1234567</Date>
    <Author>NetInvent Opensource Initiative</Author>
    <URI>\NPBackup Client - Backup repo_name default</URI>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT30M</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2026-01-21T22:37:06</StartBoundary>
      <ExecutionTimeLimit>P1D</ExecutionTimeLimit>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>P1D</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>"C:\Users\Admin\Desktop\npbackup-gui\npbackup-gui.exe"</Command>
      <Arguments>-c "C:\Users\Admin\Desktop\npbackup-gui\npbackup.conf" --backup --run-as-cli --repo-name default</Arguments>
      <WorkingDirectory>C:\Users\Admin\Desktop\npbackup-gui</WorkingDirectory>
    </Exec>
  </Actions>
</Task>

Task was created by the exe run as Admin. After creation it showed as being run as the SYSTEM user. I changed it to the Admin user for testing but nothing changed.

I might have changed one or two settings of the task to try to get it to work but nothing that should break something. When starting the task manually the status changes to running but nothing is happening (as far as I can tell). I do not currently have easy access to the machine so any additional info you need please outline clearly and extensively so I can plan accordingly.

[deajan]

For instance I need the corresponding logs which I asked in the first response.
You could also provide an anonymized configuration file.

[moritzthecat]

I tried NPBackup on Win 11 and did run in same issue.
maybe I can help out...

the task is created to run as SYSTEM, which has highest priviledges but it cannot access stored SMB credential, which would be a security breach.

attached is the log running as SYSTEM

2026-02-22 23:11:01,193 :: INFO :: npbackup 3.0.4-windows-gui-x64-public-3.13-c 2025101701 - Copyright (C) 2022-2025 NetInvent running as NT-AUTORITÄT\SYSTEM
2026-02-22 23:11:01,206 :: INFO :: Loaded config EB455A00 in C:\Users<user>\Downloads\npbackup-windows-x64-gui-public\npbackup-gui\npbackup.conf
2026-02-22 23:11:01,238 :: INFO :: Running backup of ['C:/Users//Documents/cloud-/Projekte'] to repo default
2026-02-22 23:11:01,239 :: INFO :: Using VSS snapshot to backup
2026-02-22 23:11:01,457 :: ERROR :: Stat() failed: CreateFile \<user>\File-Backup\NPBackup\Win11-\config: Zugriff verweigert
Fatal: unable to open config file: CreateFile \<user>\File-Backup\NPBackup\Win11-\config: Zugriff verweigert
Is there a repository at the following location?
\<user>\File-Backup\NPBackup\Win11-

• 2x repeating

2026-02-22 23:11:01,458 :: ERROR :: Operation finished with failure
2026-02-22 23:11:01,458 :: INFO :: Runner took 0.221424 seconds for backup
2026-02-22 23:11:01,458 :: ERROR :: Operation finished
2026-02-22 23:11:01,462 :: INFO :: ExecTime = 0:00:00.270403, finished, state is: errors.

Now I have modified the task to run as elevated user, same use which is used to trigger backup and which can access the SMB share. This runs OK, because it has same user context.

026-02-22 23:16:00,415 :: INFO :: npbackup 3.0.4-windows-gui-x64-public-3.13-c 2025101701 - Copyright (C) 2022-2025 NetInvent running as PC-WIN11<user>
2026-02-22 23:16:00,427 :: INFO :: Loaded config EB455A00 in C:\Users<user>\Downloads\npbackup-windows-x64-gui-public\npbackup-gui\npbackup.conf
2026-02-22 23:16:00,455 :: INFO :: Running backup of ['C:/Users//Documents/cloud-/Projekte'] to repo default
2026-02-22 23:16:00,456 :: INFO :: Using VSS snapshot to backup
2026-02-22 23:16:10,514 :: INFO :: Backend finished with success
2026-02-22 23:16:10,514 :: INFO :: Restic output:
using parent snapshot 2b6a12e2
creating VSS snapshot for [c:]
successfully created snapshot for [c:]

Files: 0 new, 0 changed, 7399 unmodified
Dirs: 0 new, 0 changed, 1221 unmodified
Added to the repository: 0 B (0 B stored)

processed 7399 files, 11.405 GiB in 0:09
snapshot c9997e91 saved

2026-02-22 23:16:10,516 :: INFO :: Processed 11.4 GiB of data
2026-02-22 23:16:10,516 :: INFO :: Operation finished with success
2026-02-22 23:16:10,516 :: INFO :: Runner took 10.062322 seconds for backup
2026-02-22 23:16:10,517 :: INFO :: Processed 11.4 GiB of data
2026-02-22 23:16:10,517 :: INFO :: Operation finished
2026-02-22 23:16:10,523 :: INFO :: ExecTime = 0:00:10.111177, finished, state is: success.

[deajan]

@moritzthecat Thank you for the details.

There's a reason why NPBackup creates the tasks as SYSTEM account.
Creating the task as "current user" or "admin user" will create a situation where no backup will happen if user is not logged in, which we don't want. The other way is to save current user credentials, which is a security failure and also a problem once said credentials expire.

I expect people who want to backup data from a SMB share to directly install npbackup on server that holds said SMB shares, which would make more sense then fetching data from network, especially when SMB does not support VSS.

Hence it's a design decision to run as SYSTEM, which is the only user that guarantees there is no problem.

Surely enough, this can be discussed if there are better ideas, or made more clear in wiki.

[moritzthecat]

Creating the task as "current user" or "admin user" will create a situation where no backup will happen if user is not logged in, which we don't want. The other way is to save current user credentials, which is a security failure and also a problem once said credentials expire.

this is only part of the problem and depends on use case; also may have advantages. Imagine a user is not logging on for period of time. Then this causes no data to be changed by this user and thus does not need backup. Also retention rules might be problematic for time period with limited changed data.
I am on your page that using SYSTEM (e.g. SYSTEM service) is preferred to access the data. But accessing the data to be backed-up and storing onto and restoring from target SMB share are different things which need to be refelected as well.

I expect people who want to backup data from a SMB share to directly install npbackup on server that holds said SMB shares, which would make more sense then fetching data from network, especially when SMB does not support VSS.

That is completely different use case. In our case we need to backup Windows multi-user machines to SMB share. Also this is why VSS is important. Thus we need to have access to the target SMB shares.

Hence it's a design decision to run as SYSTEM, which is the only user that guarantees there is no problem.

SYSTEM can acceess all data for sure but there is to my best knowledge no simple way to store SMB share credentials and have users restore from those. SYSTEM has it´s own credential store. The common way of other backup solutions is to implement a SYSTEM service, which can be accessed by all clients/users. Examples I have tried before are UrBackup, Duplicati and Veeam recently. They store SMB share credentials inside the application to hide the Windows complexity from user. Windows 11 isolates credentials across logon sessions, tokens, and elevation contexts. It even makes a difference if user has local account of Microsoft account.

Surely enough, this can be discussed if there are better ideas, or made more clear in wiki.

Maybe you have a good solution, which I have overlooked and which could be shared as how to setup multi-user Win11 backup up to SMB shares using NPBackup, including scheduling, SMB credential management and user level restore. Appreciate also to clarify target use case in the documentation.

[deajan]

@moritzthecat I've redesigned the task scheduling in NPBackup v3.1 to allow schedule multiple tasks at once and see previously scheduled ones. You can have a look at the current beta builds if you want.

On Windows, one needs to be administrator to be able to schedule a task, even for a standard user task, so that's contrary to the fact that I don't luanch NPBackup as admin on purpose, in order to allow "mere mortals" to setup backup processes of at least their own files. Since I don't ask for privilege elevation (and I cannot ask this once the program is running), I cannot guarantee that task creation succeeds (you will get a popup with the most probable reason).

I'm still considering how to properly setup scheduled tasks and satisfy most needs.
Could you explain what would be the "perfect" solution to you, as long as the solution can apply to both windows and linux ?
I'm really up for good ideas ;)

[moritzthecat]

On Windows, one needs to be administrator to be able to schedule a task, even for a standard user task, so that's contrary to the fact that I don't luanch NPBackup as admin on purpose, in order to allow "mere mortals" to setup backup processes of at least their own files. Since I don't ask for privilege elevation (and I cannot ask this once the program is running), I cannot guarantee that task creation succeeds (you will get a popup with the most probable reason).

I think this is more complex as tried to outline above. Again running NPB and defining and accessing credentials from NPB are different things, which in my use case to store backup on SMB share need both to work. I also provided OSS solution examples, which you could inspect for possible improvements.
The Windows details can be found in "Windows Internals" (tokens + LSA chapters) from Mark Russinovich / Microsoft, which is often recommended but might be heavy. Maybe with help from AI this could be more effectiv to pinpoint to relevant issues. AI is at least aware of these issues and I do not believe that there is same solution possible for Linux, and Windows; architecture is too different. Maybe the reason why other programs store credentials internally. Unfortunately I am not Windows expert either and just discovered this mess.

[deajan]

@moritzthecat I'm pretty sure we misunderstood. I was asking what would be the perfect solution for you from the UI point of view, eg what would be a fair basic setup for you ?
I think something like "Run task as" combo box with "SYSTEM/root" as default and "Specify user" as second option (only on windows, on linux we already have write permissions to user crontab).
In the windows case setting up the task as user would ask for user credentials, which will be saved into the scheduled task, enabling SMB access.

There's no big need to deep dive into windows internals, since task scheduler already does the heavy lifting of impersonation when setup properly.
As for linux, I would need to use user crontabs to mimic the same behavior.

The only "bad" point I see comes from security concerns. Storing user credentials in a scheduled task is a bad practice.
I could come up with an alternative solution (ie store user credentials in config file as encrypted data and later use user impersonation.

I'm weighting the most "secure" way of doing, but still would like your point of view on how it should be presented to the user.
I think in both scenarios where NPBackup or the task scheduler stores credentials, there should be a big warning popup that explains that this is not a recommended behavior.

And my first point stays valid. You still need to run as administrator on windows even to setup a non-privileged user task.

[moritzthecat]

@deajan

I'm pretty sure we misunderstood. I was asking what would be the perfect solution for you from the UI point of view, eg what would be a fair basic setup for you ?
I think something like "Run task as" combo box with "SYSTEM/root" as default and "Specify user" as second option (only on windows, on linux we already have write permissions to user crontab).
In the windows case setting up the task as user would ask for user credentials, which will be saved into the scheduled task, enabling SMB access.

if you want to do it the right way on Windows - suggest to split service and client as per the provided examples.
then client connects to the service. client shall store needed credentials e.g. SMB share access.

There's no big need to deep dive into windows internals, since task scheduler already does the heavy lifting of impersonation when setup properly.

By my experience is not a valid perception. Windows and task scheduler e.g. behave different depending if local account or Microsoft account are used. You may underestimate permutation of user setups in Windows, which impact authentification, token and logon sessions. System error "share is already connected ..." are easy to happen.

The only "bad" point I see comes from security concerns. Storing user credentials in a scheduled task is a bad practice.
ideed, this must be avoided.

I think in both scenarios where NPBackup or the task scheduler stores credentials, there should be a big warning popup that explains that this is not a recommended behavior.

Agree for task scheduler but storing credentials encrypted within NPB is inline with many backup programs as examples provided.

And my first point stays valid. You still need to run as administrator on windows even to setup a non-privileged user task.

Not true in case of system service / client split up as suggested before. Only the system service needs admin rights to install. This is where system service has its strengths.

I do not think that I can be of any help further since my arguments might not have been well perceived.

[deajan]

@moritzthecat Don't get me wrong, I do appreciate this idea exchange.

if you want to do it the right way on Windows - suggest to split service and client as per the provided examples.
then client connects to the service. client shall store needed credentials e.g. SMB share access.

Unfortunately this isn't going to happen anytime soon, since I'd need to develop a windows service especially for this task only.
I am still thinking of creating a service in order to totally get rid of task scheduling and use the service for that, but the next couple of months are already planned for some other features people requested.

By my experience is not a valid perception. Windows and task scheduler e.g. behave different depending if local account or Microsoft account are used. You may underestimate permutation of user setups in Windows, which impact authentification, token and logon sessions. System error "share is already connected ..." are easy to happen.

To be honest, I never ever used a windows account and personnaly don't want one, so I might need to do some research before implementing this properly.

I might have an idea that could perhaps resolve my issue in a more or less elegant way:

• Use SYSTEM as account for running tasks
• Optionally specify a username & password which will be saved and encrypted by NPBackup
• Spawn the actual restic backend with user impersonation to run the backend as specified user, while still running the main app as SYSTEM when launched as task

I'm not really sure if I can pull this off without major drawbacks, but I'll have a quick PoC and report back.

[deajan]

In order to handle the side effect of creating a scheduled windows task, I can add an optional UAC when launching the app. That could perhaps suffice, or even a button "rerun as admin". Not decided what would be best in terms of UX.

[deajan]

@moritzthecat So it has been a real pain to get NPBackup to elevate after launch for task reading / creation.
So far, I've implemented UAC elevation, and the possibility to run task as another user, which should solve a couple of smb reading problems.

I've tried to play around with impersonation, but that doesn't do the trick for the way I'm launching my executable, which needs to pipe stdout and stderr.
Also, running as service might be a good idea (it's actually on my todo list), but this has to be implemented right, since there will only be one service, and multiple repositories might need to run as different users, which would still be a problem.
Anyway, the windows service can be reconsidered once next developments are out.

Hope you'll get to play with latest beta6, and hope it might solve your issue.
Perhaps you could keep me informed ? Thanks.