Post-command Not working for scheduled Task without GUI

[Alberto]

Hello,

I’m using Hasleo Backup Suite V 5.9.2.4 (Free edition) on Windows 11 PRO 25H2, successfully since several months on 3 PCs for Home use.  Now I’m testing the Post-command.
 
When launching the backup task manually from Hasleo GUI it works well.  And my cmd script receives well the parameters including “/result={BACKUP_RESULT}”

When the backup task us launched by its scheduled time, but keeping the GUI open, the Post-command still works.

But if I close the GUI, that should be normal operation, the Scheduled Backup Task runs at its time BUT the Post-command IS NOT executed.

Tested several times.  It is reproducible.

Is this a bug?  Or is it a ‘feature’ of the Free edition that should work on a paid edition?

[garioch7]

@Alberto,

Welcome to the Hasleo and the Hasleo Forums.

A full comparison chart of the available paid and free versions, of the Hasleo Backup Suite can be found here: https://www.easyuefi.com/backup-software...rison.html.

I stand to be corrected because I am not as knowledgeable as my Forum Team colleagues on that issue since I never use it even though I do own a lifetime license to Hasleo Backup Suite Professional, with free lifetime upgrades, but I would guess that full command line capabilities are only available in paid versions, but I could be, and sometimes, am incorrect.

I would ask for your patience until a more knowledgeable Forum Team member is back online to authoritatively respond to your question.  I did, however, want to welcome you, and I am very happy to learn that your experience with the Hasleo Backup Suite has otherwise met your expectations. 😊

Have a great day, and once again, WELCOME.

Regards,
Phil

[Alberto]

@Alberto,

Welcome to the Hasleo and the Hasleo Forums.

I stand to be corrected because I am not as knowledgeable as my Forum Team colleagues on that issue since I never use it even though I do own a lifetime license to Hasleo Backup Suite Professional, with free lifetime upgrades, but I would guess that full command line capabilities are only available in paid versions, but I could be, and sometimes, am incorrect.

I would ask for your patience until a more knowledgeable Forum Team member is back online to authoritatively respond to your question.  I did, however, want to welcome you, and I am very happy to learn that your experience with the Hasleo Backup Suite has otherwise met your expectations. 😊

Have a great day, and once again, WELCOME.

Regards,
Phil

Thank you very much for the welcome.

But I have to remark that I’m not referring to the Command Line Interface (CLI), that I know is for Paid Versions.

I’m referring to the Task -> Backup Options -> Command where you can enable in the GUI the Pre-command and Post-command  for your own program or script to run before or after the backup.  In my case I have enable only the Post-command and as I said it works perfectly.  But is NOT run when the Hasleo GUI is closed and the Backup Task is launched by its schedule.

Regards,
Alberto

[garioch7]

@Alberto,

Thank you for your reply.  I will defer to my more learned colleagues to advise you on your issue.  I regret I lack the knowledge, yet, to assist you.

Have a great day.

Regards,
Phil

[al3x]

I’m referring to the Task -> Backup Options -> Command where you can enable in the GUI the Pre-command and Post-command  for your own program or script to run before or after the backup.  In my case I have enable only the Post-command and as I said it works perfectly.  But is NOT run when the Hasleo GUI is closed and the Backup Task is launched by its schedule.

Hi,

Depending on your script, this could be an NTFS permission thing or maybe missing credentials. What does your script try to do exactly?

When you run a backup task from the GUI directly, it is run with your current user (as far as I know). So it will also use your currently registered net shares and NTFS permissions for accessing folders on your PC or remote servers in your network. But when the task is run from schedule, it will be run via the service "HasleoBackupSuiteService", which runs as local system user (SYSTEM).

So if you try to access remote servers with your script, net shares that your current user can access won't be available. And folders might also not be accessible, depending on your NTFS permissions - "SYSTEM" should usually be included, though.

Do you get any errors? Have you tried running a simple script that just logs something to a file so you can check what was created and who's the owner of that log file?

Cheers,
al3x

[Alberto]

It is a simple script that just logs in a log file, such as:

>> "%LOG_FILE%" echo [%DATE% %TIME%] ===== START POST_COMMAND === TEST_MODE = %TEST_MODE% ==========================

and some more lines like this.

It ends with:

exit /b %RC%

with RC well defined before.

So, the issue could be that the process under Local System cannot access my script. It simply does not run. At least I cannot see any error or message nowhere. And looking into the logs at /bin/logs of Hasleo, dont find anything clear as they are 'for developpers...'

The coded paths are always Full paths. I will try with permissions or just locating another test script.cmd, as simple as possible, at another folder for testing. What can you recommend me?

[al3x]

I didn't try this for myself, but maybe just create a temp folder like c:\hbs_test\ and set NTFS permissions for that folder to Full for Everyone.

Then you could place a script there that just writes a log file:
echo just a test >>c:\hbs_test\log.txt

Then run your task once via GUI and check if the log file was created and who's the owner of that script.
Then delete the log file and rerun your task via schedule with a closed HBS.

Would be interesting to see if that succeeds and if yes, who's now the owner of that log file.

[al3x]

Ok, tried this myself in a VM now. This really seems to be a bug unfortunately.

When run from the GUI, the log file is written and the owner is "administrators".

When run from the background task, the backup task itself finishes but there's no log file written to disk. Also there's an error sound, probably there's some kind of error in the background, which is not shown due to the different user context.

I think this is something Hasleo has to check, I don't have an idea here how to further analyze this unfortunately. Hasleo is very active in this forum and I'm pretty sure @admin (Hasleo staff) can have a look at this soon.

Cheers,
al3x

[Alberto]

OK.  I just tried with a very simple script.cmd  at  c:\TEST\test.log  with permision  Everyone Allow  Full control  at the TEST folder and inherited to all subfolders an files.  As always it works with the GUI open, But  NOT run when GUI is closed.

It looks really like a bug, then, and I hope Hasleo staff could look at this.

What surprise me is that very few people may be using the Post-command if it fails to run in the backgroud. Otherwise it would be a very known issue.    Or that people that use Post-command  keeps the GUI Open?

Thanks @al3x for your check test.

regards,
Alberto

[al3x]

Yeah, I don't think a lot of people actually use scripting for their backups, so this pretty much flies under the radar I guess 

Btw, I was able to pin point the exact version this problem started:
- Up until v5.9.2.3: Everything works as expected, log file is created with normal user as the owner.
- v5.9.2.4: Post command is broken when run in background. When run from GUI, everything works, log file is created with normal user as the owner. No error sounds.
- v6.0.1.0 beta: Post command is broken when run in background. When run from GUI, everything works but log file is created with owner "administrators". Normal backups from GUI or from background play error sound on finish.

So, summing up:
- The post command problem started with v5.9.2.4, something was introduced that causes this error.
- Additionally to that, the current beta version plays an error sound whenever a backup finishes (even when post commands are disabled entirely).
- Also, the current beta version "touches" files with owner "administrators" instead of current user (maybe intentional, but different from v5.9.2.4 and earlier).

Let's wait for @admin to give feedback to the devs on this one 

*Edit: This error also affects pre commands. Exact same behavior.