Script after Job not working

[FrankBl]

Hi all,

maybe someone of you got an idea.

I am trying to run a batch file before and after the backup job, but this only works partially.
The batch before the job starts wake up the NAS with Wake on LAN on which the repository is located - this also works perfectly, also the timeout of 300 seconds so that the NAS can boot up works, when the backup job starts the NAS is ready, so far so good.
But the script to shut down the NAS after the backup does not work if I run it as a batch via Veeam - if I run it manually with a double click, or if I call it manually via a command line, then it works.
Even if I convert the script into an exe with BatToExe and store it in Veeam, it does not work.

The used batch:
set ip=***.***.***.***
set nutzer=*******
set passwort=********

echo echo -e "%passwort%" ^| sudo -S -i poweroff > befehl.txt
plink.exe -batch -ssh %nutzer%@%ip% -pw %passwort% -m befehl.txt
del befehl.txt

I can't really figure out where the problem is located, cause, as written before, using the batch manually via mouse-click oder command-line, ist works.

Kind regards, Frank

[david.domask]

Hi Frank, welcome to the forums.

When running via Veeam, pre and post job scripts will run as the service account the Backup Service runs with. Typically this is the SYSTEM account for the system, and to test properly you must test with the SYSTEM account as well. You can start a powershell session and load cmd with PSEXEC, there is a flag you can pass to start as system; WHOAMI must show that you're running as the local SYSTEM account, not as a user, for the proper test.

As for the script itself, as I get it, you:

1. Write the script to befehl.txt
2. use plink.exe to read from the befehl.txt file and then pass the commands with -m flag to the NAS
3. delete the befehl.txt

I would try the plink line from a shell running under SYSTEM account, see what happens. Likely that's the difference. Similarly, you might consider using the full path for plink as well as the full path for the file -- I think by default system will use C:\windows\system32 for it's working directory, so it's possible it just cannot find one or both of the items.

[FrankBl]

Hi David,

sorry for the very late reply, haven't got the time to come back to the forum.
Many thanks for the hint, I will try it as soon as possible and post the outcome, but this will take some time.

Kind regards, Frank