This is utter horseshit.
There are many failures that can occur in the middle of reading a file when some content but not all has been read.
yep, that’s what I did in the end. I already had an override for openhab2.service to tidyfy openhab2 starts and in fact already had a touch … line there. Added another and it helps.
So, no need to use at or care for timing.
What happens if variables are added to the exec command ?
Does the white list have to contain every possible combination or can the whitelist contain a placeholder?
- the current (or last) command to the input channel (see below, example:
%2$s)note - if you trigger execution using interval or the run channel, the
%2substitution will use the most recent command (if there has been one) sent to the input channel.
I’ve rolled my openHAB2 instance back to V2.5.1-2
my commands have variables, those %2$s - and I added those in the whitelist, successfully.
I just copy&paste the command from the thing to the whitelist, including the variables.
Is that what you meant?
If not, you could check the log of the exec binding, you find the warning/complain by the binding of what is “not” in the whitelist and copy&paste that.
Or maybe I missunderstand, but more variables than that is unknown to me.
1 Like
That’s excellent advice.
Thanks
Help I don’t understand where the problem is
I have such a thing
Thing exec:command:apc [command="cat /sys/class/thermal/thermal_zone0/temp", interval=15, timeout=5, autorun=false]
I followed the instructions given here
so I have a file /etc/openhab2/misc/exec.whitelist like 
cat /sys/class/thermal/thermal_zone0/temp
I emptied OpenHAB, emptied the caches and relaunched Openhab
but I still get the following error:
12:39:31.975 [WARN ] [ing.exec.internal.handler.ExecHandler] - Tried to execute 'cat /sys/class/thermal/thermal_zone0/temp', but it is not contained in whitelist.
help me because i don’t understand
Thank’s
So now you need to touch or resave the whitelist file while openHAB is running.
I tried as above: I first modified the exec.whitelist file while openHAB was running and I still got the error “is not contained in whitelist” I then deleted it and re-created with openHAB which worked and always the same !!!
Heres my full understanding and solution (on a Linux system… with a suggestion for Windows machines).
- You HAVE to create the misc folder manually in the same location as your rules, sitemap, transform etc folders reside. Within the misc folder you will also have to create the file exec.whitelist
- The commands AND ONLY commands you need to put in here are ones in your THINGS which you can see in Paper UI or look in your manual Things files.
All the exec commands and bits like that in your RULES files, should run absolutely fine WITHOUT having to add anything to the whitelist file… to repeat…ONLY the THINGS exec commands need to be added.
- From what I can tell you need to specify the EXACT path and full command line in the whitelist file. e.g. I was running the “nc” command as “nc -v -z -w 1 192.168.1.101 9295” however I had to modify my Thing and add the full path to “nc” … so that command became "/bin/nc -v -z -w 1 192.168.1.101 9295"
And YES you do put the FULL command in… not just the path the executable. So for example, in my exec.whitelist, I have
/bin/nc -v -z -w 1 192.168.1.101 9295
as one of my lines, which is an exact match for what is listed in the Thing exec command line.
- I cant say that I had any success creating the exec.whitelist file in Notepad++ on a PC and saving it over the network to my misc folder. As such I create a new file in the misc folder, while actually locally logged into my Linux Openhab system and then used NANO to edit the file in the terminal window e.g. nano /etc/openhab2/misc/exec.whitelist
I was able to copy/paste line by line my commands into this new file and save it (ctrl+o), which the file then worked great!!
- Apart from, there appears to be a problem with the file needing to be touched on a reboot, which is going to be resolved (so I gather) but for now, you can add the following to a rule file:
rule "exec whitelist workaround"
when
System started
then
executeCommandLine("/bin/touch /etc/openhab2/misc/exec.whitelist")
end
WINDOWS/Linux - Obviously, you can only use touch on Linux systems, you might… on a WINDOWS machine be able to make a batch file that runs on boot to copy a copy of the exec.whitelist over the top of the exec.whitelist file e.g. Make a copy of your exec.whitelist and call it exec.whitelist.boot and then have a batch file that does copy exec.whitelist.boot exec.whitelist (in your misc folder location) or something like that… though I dont run Openhab on a windows system, so I cant test.
- Some people have mentioned that there could be a permission issue, which could be for a variety of factors based on your file system setup, how you created the file (inherited permissions) etc.
Its suggested to allow your Openhab user account to take control of the file. Assuming the user account your Openhab installation is using, is called “openhab” you would do something along the following lines:
sudo chown openhab exec.whitelist
or
sudo chown -R openhab:openhab /etc/openhab2/
to ensure that permissions are flushed onto the file or the entire folder structure. Of course, your path to the folders/files may be something different than /etc/openhab2 … so change things where necessary.
You do still get 1 or 2 “Tried to execute XXXXXXXXXX but it is not contained in whitelist” on system startup… but thats about it… and you will see the “executed commandLine ‘/bin/touch /etc/openhab2/misc/exec.whitelist’” appear in the log files, then the errors will go away.
After doing all that, my system is working fine with exec commands.
Hope that helps someone!
8 Likes
So the touch trick after the restart was working for a while.
But now it allows the execution of ONE command only 
and ignores the rest.
No logs are generated… WTF!
Also, noticed that with this upgrade the memebr upgrade/ received update rules are compeltely ignore
Member of gXXXXXX received update
Frankly, thats the worst update I have ever experienced in 2 years of using OH.
I think as people pointed out before on here and in other posts (as well as mine) there is some kind of formatting issue with that file and how Openhab is parsing the file.
Not sure if you want to try (or did) what I suggested in step 4 of my above post and use Nano to create the file in entirety (not just edit an existing file, as it may be the wrong text encoding type in some way… though I think mine is UTF-8 without BOM).
My whitelist is renaming stable so far, with all commands running ok… though I did use Nano to create the file.
I tried more or less EVERTHING suggested above. NOTHING works, all exec commands are still rejected. I’ve put EXACTLY the string from the log into the whitelist, it did not work. I touched the whitelist while openHAB was running, no luck. Changed from CRLF to LF and back, no luck.
Checked file and folder permissions and such, did not help.
As stated above, the WORST update experience ever. And I did not even update on purpose, just stopped openHAB, cleared cache and temp (for other reasons) and started again. And to my surprise I got an non-working exec binding! Thank you very much 
At least there is no supposed security risk anymore. Absolutely NOTHING is executed, so there’s no security risk 
I don’t think you can blame others for that.
To fix after trying everything above, openhab didn’t have access to the whitelist file. Not sure if that was mentioned here or not, but I did the following which resolved for me:
sudo chown openhab exec.whitelist
1 Like
You probably enabled remote downloads for your addons so on (re)start you got the latest version installed so OH just did what you told it to.
1 Like
Yes, if it’s the setting in PaperUI under “Configuration > System > Access Remote Repository”. The description says “Defines whether openHAB should access the remote repository for add-on installation.” I would not expect this to install a NEW version of an add-on just by clearing the cache and tmp-folders and restarting openHAB. But I would have upgraded to 2.5.2 anyway, so I don’t really blame anyone for this.
The fact is that the current state of this whitelist seems to be somewhat broken if so many people have problems with it. The biggest problem is probably that the binding does not log anything out of the box about the whitelist file itself, if it can find the file (or not), if it can read it (or not) and so on. It just tells later when a script should be executed that it cannot find the script in the whitelist.
And in my case the script to be executed really is in the whitelist, but I have no idea if the whitelist was ever found and read…
2 Likes
@ewrw - Thanks for this. I created the exec.whitelist file with nano adding in all commands from
grep ‘command":’ /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.Thing.json
I had to make the /etc/openhab2/misc folder so also ran
chown -R openhab:openhab /etc/openhab2/
I have added the touch rule exactly as you have listed it. Restarted openhab and watched it touch the whitelist. Previously without the whitelist touch rule the exec commands would fail to work dispite the whitelist being present.
With your touch whitelist rule it all works again.
Thanks for your efforts.
Good work!!
3 Likes
Ill add that onto the list of possibles!!
Painful as it might be… Id be temped to backup your config to a ZIP with the Openhab Backup utility (link below).
Uninstall the Opehnab installation with whatever package manager your system has (Logged in as the Openhab user account you are using). Then reinstall it, which should reset/flush all file level permissions on the folders. (should take about 5 to 15 minutes depending on your devices speed).
Then restore the backup which takes about 3 minutes… reboot… and possibly re-create the whitelist if it doesnt work.
Mind you, my experience of doing this that on the 1st boot of Openhab, it takes a while to download/install any other add-ons/bindings… or shift them around in the folders… so whilst you may be able to see the Openhab interface etc… it might take it another 10 minutes before all is working… at least… my MQTT bits didnt work for 10 minutes or so on 1st boot… but have been perfect since, including on reboots.
That would be my attack method at least… Its a bit aggressive, but should get everything back to square one, and if it still doesnt work after that… I think you need to get the devs to take a look.
Thanks
Will