Well, isn’t that frustrating…
That’s typically not how things work, especially when you are getting errors due to a configuration mistake. Those typically don’t (never…?) just fix themselves.
But it’s good that it’s working.
Ok, I already opened an issue .
Thanks for your support
What was the issue you opened?
If you don’t know what fixed it how do you know what to report?
1 Like
Nothing fixed something.
There is an issue reportet by the checker but nothing gives an idea, where to search for it or what to do.
Because when restarting HA, the log doesn’t report anything.
Thats the issue in my opinion. Either it is a bug in the checker or it is something, which should be pointet out a little bit more. Maybe I can update to 0.96. and ignore the checker result, but then there should be also an advice or something.
then these two statements are mutually exclusive…
So…if, in fact, the config check still shows “an issue” then did you actually do what I suggested above to try to narrow it down to the problem area?
ok, did it. I commented out the customize.yaml and checked again. Now against Version 0.97.0
interesting result:
INFO:homeassistant.util.package:Attempting install of colorlog==4.0.2
Testing configuration at /tmp/config
INFO:homeassistant.util.package:Attempting install of blinkpy==0.14.1
INFO:homeassistant.util.package:Attempting install of mutagen==1.42.0
INFO:homeassistant.util.package:Attempting install of gTTS-token==1.1.3
INFO:homeassistant.util.package:Attempting install of home-assistant-frontend==20190805.0
INFO:homeassistant.util.package:Attempting install of hass-nabucasa==0.16
INFO:homeassistant.util.package:Attempting install of aioharmony==0.1.11
INFO:homeassistant.util.package:Attempting install of holidays==0.9.11
INFO:homeassistant.util.package:Attempting install of pyfttt==0.3
INFO:homeassistant.util.package:Attempting install of fritzhome==1.0.4
INFO:homeassistant.util.package:Attempting install of aiohttp_cors==0.7.0
INFO:homeassistant.util.package:Attempting install of herepy==0.6.2
INFO:homeassistant.util.package:Attempting install of schiene==0.23
INFO:homeassistant.util.package:Attempting install of xmltodict==0.12.0
INFO:homeassistant.util.package:Attempting install of psutil==5.6.3
INFO:homeassistant.util.package:Attempting install of sqlalchemy==1.3.5
INFO:homeassistant.util.package:Attempting install of netdisco==2.6.0
INFO:homeassistant.util.package:Attempting install of distro==1.4.0
INFO:homeassistant.util.package:Attempting install of pyatmo==2.2.0
INFO:homeassistant.util.package:Attempting install of fritzconnection==0.6.5
INFO:homeassistant.util.package:Attempting install of alexapy==0.7.0
INFO:homeassistant.util.package:Attempting install of pyowm==2.10.0
INFO:homeassistant.util.package:Attempting install of aiofiles==0.4.0
INFO:homeassistant.util.package:Attempting install of backoff==1.8.0
INFO:homeassistant.util.package:Attempting install of packaging==19.0
INFO:homeassistant.util.package:Attempting install of speedtest-cli==2.1.1
INFO:homeassistant.util.package:Attempting install of python-pushover==0.4
Failed config
homeassistant:
- not a directory @ data['whitelist_external_dirs'][1]
- auth_providers: [source /tmp/config/configuration.yaml:12]
- type: homeassistant
- trusted_networks: [source /tmp/config/configuration.yaml:15]
- 192.168.178.0/24
- 46.88.232.0/24
- 79.240.7.0/24
- 127.0.0.1
type: trusted_networks
elevation: 45
latitude: 51.2686305
longitude: 6.6173445
name: ZuHause
time_zone: Europe/Berlin
unit_system: metric
whitelist_external_dirs: [source /tmp/config/configuration.yaml:8]
- /config
- /share
Successful config (partial)
homeassistant:
It seems from my point of view, that the whitelist entry causes this problem.
hmmm. I don’t understand the problem…will have to examine what the problem is.
because both directories are there and in use
I found an old thread with the same problem: Hassio share directory access
But I’m not shure if a simple reboot of the system will really help…
I just looked at your config you last posted and I think you need to have the two entries under the whitelist_external_dirs line indented two more spaces. And put quotes around the entries
whitelist_external_dirs:
- '/config'
- '/share'
Once you do that try the config check again.
If that still gives an error then comment out all three lines and try the config check again.
Ok, I have to comment out the /share. then everything works
Unfortunately I store my blink videos and photos in subfolders of /share.
The plan is now:
-wait for 0.97.2
-comment out /share and the automations/scripts storing their files there
-execute the update
-activate everything again
-restart.
Generally spoken, I’m wondering if even the share folder makes problems. It seems to be an older problem. The HA in principle has no problems with it. No warnings or errors after restart.
I will keep my issue in the checker forum open, because there could have been some less confusing messages when customize.yaml is not commented out. I can still reproduce this behavior
Thanks for your help.
Is share inside or outside your config folder?
its outside
I believe you need to specify the whole path then.
good point. will try that.
But why does it work in day to day business and is only a problem for the checker?
Another question: share is like config from Hassio point of view a root, right? How shold a complete path look like?
I find it strange that you need to whitelist your config directory in the first place. I would think that by default hassio has to have access to that directory in order to even run.
What made you think that you needed to do that?
And, that said, I’m really not sure that you need to whitelist the share folder either (I don’t use hassio so I don’t know what directories it has access to).
Have you tried to remove both entries from the whitelist section and see if you can access things stored there from HA?
Whitelisting is so that components can use those areas. By default, config is not whitelisted, meaning some random component cannot read/write to that directory though an automation of some sort. That doesn’t mean the component itself cannot write to it.
Just like how you can’t use a resource outside the www folder for lovelace. Well, you can, you just need to whitelist it.
I think it’s for security. I’m not really sure why it’s this way otherwise 
Ah, I didn’t realize that.
I know I’ve had to whitelist a couple of sub-directories under the config folder. I guess now that I think about it it’s probably for the same reason.
On that same note tho, maybe the config checker is complaining that the whole /share directory is listed instead of any specific sub-directories. Maybe there is something screwy there that it doesn’t like/understand when whitelisting the whole thing instead of just parts of it?
Honestly, I have no clue. The whole whitelisting thing is annoying because you ahve no idea if a component uses it or not. All these random components that people make may or may not use the function to validate the directory. It’s hit or miss and very annoying!
hell, i might even be wrong about it’s uses. It may be related to only ‘using resources’, not saving a file.
No, I think you’re right about that.
That’s the reason I had to whitelist one of the directories. I was writing a camera capture file to a sub-directory under /www and it wouldn’t let me do it until I whitelisted it.
Well then, it’s just as annoying as I thought. I guess I should write up issues against components that don’t use it properly.
This script does not work without whitelisting the folder:
get_garten_snapshot:
sequence:
- service: blink.trigger_camera
data:
name: "Garten"
- delay: 00:00:05
- service: blink.blink_update
- service: camera.snapshot
data_template:
entity_id: camera.blink_garten
filename: "/share/camera/garten_snapshot_{{ now().strftime('%Y%m%d_%H%M%S') }}.jpg"