When I start a script in netwatch (UP or DOWN) with “/system script run 4” global variables are not taken into account or set. If the same script is run manually or via scheduler, they are. Is there anything to note here?
br, Richard
To be able to use the real global variables (whose values are listed under /system/script/environment/), the polices policy and test are required.
Netwatch is limited to read,write,test,reboot script policies. If the owner of the script does not have enough permissions to execute a certain command in the script, then the script will not be executed. If the script has greater policies than read,write,test,reboot - then the script will not be executed as well, make sure your scripts do not exceed the mentioned policies.
It is possible to disable permission checking for RouterOS scripts under /system/scripts menu. This is useful when Netwatch does not have enough permissions to execute a script, though this decreases overall security. It is recommended to assign proper permissions to a script instead.
If you want to access them through Netwatch, you should put your code in a script with the required policy checked, plus dont-require-permissions enabled on that script, see:
dont-require-permissions (yes no; Default: no) Bypass permissions check when the script is being executed, useful when scripts are being executed from services that have limited permissions, such as Netwatch.
Then Netwatch can call that script.
1 Like
Wrong from the start.
what is correct ?
intelligent reply/question
/system script run "script name"
But "/system script run 4” works also, so why “wrong from the start” ?
An that script runs, that’s not the problem. Global variables are not taken into account or set.
Because you don't really know (for sure) what "4" means, it happens to correspond to "script name" right now, but if you add/delete another script it may (or it may not) change and also a RouterOS upgrade/update or whatever may change the order of the scripts, so "4" may become pointing to something else.
1 Like
Ahhhhhh …. yes, of course the ID changes when I delete scripts in between, upgrade ROS, etc … I realize that. That was a first quick attempt to work with netwatch. I would have cleaned it up afterwards, but if working with global variables doesn't work, the whole thing is pointless anyway.
No, the ID remains the same until you delete the script (doing "undo" often results in the same ID as before, but it's not guaranteed).
4 is not an ID, it's a number, and it's the script number when you run "print"
And that's precisely why it's wrong to use "print numbers" when referring to an element.
Does the element have a name? Then use the name...
If you start from the wrong assumptions, you need to correct the initial errors, then look at the rest.
This may not be the case, but most of the time, the problems you encounter are due to previous mistakes that negatively impact the final result.
Solution:
And we are back to CGGXANNX's suggestion, you need another script (with the required permissions and run that script via Netwatch:
Scripts started with netwatch cannot process global variables? - #3 by CGGXANNX
P.S. Ooops sooy rexternded, cross-posting, anyway repetita juvant
1 Like
Not, just add dont-require-permissions=yes to script "4" on GUI or on CLI
/system script set "script name" dont-require-permissions=yes
@roe1974
Since RouterOS's behavior with respect to DHCP, security profiles, Netwatch, etc. scripts has changed several times,
it's ALWAYS recommended to specify which RouterOS version you're referring to...
We're all assuming it's 7.20+....
Sorry, yes i am using 7.20.8 LTS 
So the script “testscript” has “dont-require-permissions=yes”.
I now start the script with
/system script run testscript via netwatch
but it still doesn't work.
A simple script:
The global variable SettleTimeOK is set to “true” (by another script).
:global SettleTimeOK
:if ($SettleTimeOK = true) do={
:log info message="PASS"
}
PS:
:log info message=$SettleTimeOK is ““ (empty)
But SettleTimeOK has “true” in /system/script/environment
I'll check for a moment
In 7.20.8, accessing global variables from netwatch or from scripts launched (correctly) from netwatch no longer works.
I'll do some more testing.
It's the same as 7.21.3
They didn't do anything they promised.
Variables created within netwatch (sub-script included) are NOT seen by other users, and vice versa.
Working example using tmpfs that do not wear NAND or XOR flash....
Preparing virtual disk and file:
/disk
add slot=gv tmpfs-max-size=1000000 type=tmpfs
/file
add name=gv/SettleTimeOK type=file contents="test"
Scripts:
/system script
add dont-require-permissions=yes name=testscript1 owner=admin policy=reboot,read,write,test source=\
":local SettleTimeOK [/file get \"gv/SettleTimeOK\" contents]\r\
\n\r\
\n:log info \"testscript1: SettleTimeOK is >\$SettleTimeOK< and \$[:typeof \$SettleTimeOK]\"\r\
\n\r\
\n[/file set \"gv/SettleTimeOK\" contents=true]"
add dont-require-permissions=yes name=testscript2 owner=admin policy=reboot,read,write,test source=":local SettleTimeOK [/file get \"gv/SettleTimeOK\" contents]\r\
\n\r\
\n:log info \"testscript2: SettleTimeOK is >\$SettleTimeOK< and \$[:typeof \$SettleTimeOK]\"\r\
\n\r\
\n:if (\$SettleTimeOK = true) do={\r\
\n :log info message=\"testscript: PASS\"\r\
\n}"
/tool netwatch
add disabled=no host=127.0.0.1 name=testnetwatch test-script="# for test set it everytime to false\r\
\n/file set \"gv/SettleTimeOK\" contents=false\r\
\n\r\
\n:local SettleTimeOK [/file get \"gv/SettleTimeOK\" contents]\r\
\n\r\
\n:log info \"testnetwatch1: SettleTimeOK is >\$SettleTimeOK< and \$[:typeof \$SettleTimeOK]\"\r\
\n\r\
\n/system script run testscript1\r\
\n\r\
\n:set SettleTimeOK [/file get \"gv/SettleTimeOK\" contents]\r\
\n\r\
\n:log info \"testnetwatch2: SettleTimeOK is >\$SettleTimeOK< and \$[:typeof \$SettleTimeOK]\"\r\
\n\r\
\n/system script run testscript2\r\
\n\r\
\n:set SettleTimeOK [/file get \"gv/SettleTimeOK\" contents]\r\
\n\r\
\n:log info \"testnetwatch3: SettleTimeOK is >\$SettleTimeOK< and \$[:typeof \$SettleTimeOK]\"" type=icmp
Hey @rextended
Thank you sooooo much for your solution 
It's a shame that you have to build something so “complicated” here, when it would be easier if variables were treated the same across the entire OS 
.
But maybe Mikrotik is reading this .
br, Richard
1 Like