Whitelist_external_dirs: and the Fatal error while loading config: 'packages' problem

Installation Home Assistant OS
1

So to be able to store a snapshot from my web camera in the ‘share’ folder found in HASSIO I have found I need to have the share folder whitelisted in the Homeassistant: section of config like thus:

  whitelist_external_dirs:
    - /share/snapshots

Which fixed this message below from my log if I have not got that whitelist in place when the snapshot is called by camera service, which makes sense to me.

2018-08-04 14:46:32 ERROR (MainThread) [homeassistant.components.camera] Can't write /share/snapshots/snapshot_camera.front_camera.jpg, no access to path!

However THAT fix now creates log errors of it’s own like this below !

ERROR:homeassistant.scripts.check_config:BURB
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/scripts/check_config.py", line 207, in check
    res['components'] = check_ha_config_file(hass)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/scripts/check_config.py", line 328, in check_ha_config_file
    del core_config[CONF_PACKAGES]
KeyError: 'packages'
Fatal error while loading config: 'packages'
Failed config
  General Errors: 
    - 'packages'
Successful config (partial)

So it’s catch 22 here, to use the share folder for image storage I need to whitelist it, but the whitelisting creates a fatal error, removing the whitelist leave me unable to store images from the camera, and around it goes…

Does somebody know what’s wrong with whitelisting currently ?
Is it broken, or has the syntax changed, or is there a better way/place to store camera snapshots in the first place ?

2

Have you managed to solve this? I’m running into the same problem…

3

Ok, I managed to get it working thanks to this post: post

homeassistant:
 whitelist_external_dirs:
 - '/share'

and then a full reboot off your system, not a reboot of the host systerm

4

Not for me unfortunately.
If I add the whitelist directory into my config then HA server fails to load after rebooting (a full power off reset on RPi). I then have to edit the config on the SD via SAMBA and power reboot again to recover.

I have not tried it for a couple of HA updates (as it not fun anymore to endlessly research these bugs).
I’ll try it now again though and report…

5

Hey what hardware and OS are you running HA on ?

6

I tried again with updated HA 0.75.3. It does start HA properly now after a power reboot with a White_listed directory in config, and my camera image snapshots are available again (for now anyway).

BUT it still will not restart HA with a white_list directory via the ‘general configuration’ server restart GUI button. So it’s another cludge in my growing list of HA cludges to document and remember and still is a bug…
What is really bad about this bug is that nothing in the error log actually points to the white_list as a source of the problem, so as new HA users try to white_list they get no useful information.
Here is what I get from a GUI restart attempt.

Sat Aug 18 2018 10:57:43 GMT+0930 (Australian Central Standard Time)

Testing configuration at /config
ERROR:homeassistant.scripts.check_config:BURB
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/scripts/check_config.py", line 207, in check
    res['components'] = check_ha_config_file(hass)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/scripts/check_config.py", line 328, in check_ha_config_file
    del core_config[CONF_PACKAGES]
KeyError: 'packages'
Fatal error while loading config: 'packages'
Failed config
  General Errors: 
    - 'packages'
Successful config (partial)
7

Yes I also still have the same problem. Did not try to restart again through the GUI…

I’ve checked the Issues and there are more with the same problem. Please check this issue https://github.com/home-assistant/home-assistant/issues/13247 and comment so I may get more priority

edit: Ok see now that you already commented on this…

8

BTW I’m using raspi 3 with HassOS 0.75.1

9

Yep same hardware here. I wonder if the reason this issue is so rare is because it’s dependant on only people with that hardware type and also a reason to need to white_list.