You need to fix that, listed in changes.
Update, just spun up another supervised install on vm, didnt seem any longer than usual
I think this is in the release notes.
It hasn’t worked for me since about 2016. I forgot it even exists.
It’s because @ character in your case is a separator between password and username in connection string.
Replacement of @ applies only to those characters which are part of password and username. (in fact it should be applied to all characters which could potentially break URI format, for example to colon, space etc - it’s not HA specific).
BTW it should be called “Connection URI” instead of “Connection string”. Both are different things.
Hem… I did not set up anything with MQTT since everything set up using integrations so confused on which part needs to be fixed.
As for Supervised on my end upon running the script and then go into port 8123, I got the 20minute preparation pages which I haven’t seen for a very long time.
i got the 20 minute page but it finished within 5 minutes
The problem is that the package repositories of the pi are a bit behind.
Here is a blogpost that I used to get the latest version of home assistant working on my raspberry pi 2.
Not only would you need to update libseccomp2 as @farmio said, but also the docker engine.
Starting the container in privileged mode is terrible advise if you ask me @ludeeus.
That might be, but that is how it should be done. see the ADR for container installation architecture/0013-home-assistant-container.md at 91ecbe4af814de6c06f3f98afc0920b2491a334c · home-assistant/architecture · GitHub
Hello
Before upgrading and as proxy change is present and confirmed in 2021.7, I would like to know how can I found which integration is using this ip reported in 2021.6 ?
log say:
A request from a reverse proxy was received from 172.30.33.6, but your HTTP integration is not set-up for reverse proxies; This request will be blocked in Home Assistant 2021.7 unless you configure your HTTP integration to allow this header
But I don’t have any http in configuration.yaml. I’m using Duck DNS in combination of NGINX Home Assistant SSL proxy.
This is the same approach to fix that before upgrading ?
Same here. What can we do?
Write this in configuration.yaml bat can´t access via duckdns to HA:
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1 # Add the IP address of the proxy server
I’ve never seen an example docker run or docker-compose with priviliged mode enabled and I didn’t know that was the only supported way.
Thanks for the link! 
Well you need one as per the release notes.
Our documentation show that for both 
I think I installed my home assistant a long time ago 
I´ve that configuration but can´t access via duckdns.
Getting I’m getting 400: Bad request
Thank you DavidFW1960 and all the communities which is soo great.
After reading a second time, it’s clear.
I’m getting 400: Bad request on my Kindle Fire tablet on the same network as HA. No proxying involved. My phone connects to the same address just fine. Where do I look to solve this?
So my guess is:
You have a trusted_proxy configured in your HTTP integration AND are using trusted networks.
The IP address of the tablet, matches both of those settings (which cannot be correct).
I’v solved this by adding all the cloudflare subnets to the trusted proxies.
server_port: 8123
use_x_forwarded_for: true
trusted_proxies:
- 172.30.33.0/24
- 173.245.48.0/20
- 103.21.244.0/22
- 103.22.200.0/22
- 103.31.4.0/22
- 141.101.64.0/18
- 108.162.192.0/18
- 190.93.240.0/20
- 188.114.96.0/20
- 197.234.240.0/22
- 198.41.128.0/17
- 162.158.0.0/15
- 172.64.0.0/13
- 131.0.72.0/22
- 104.16.0.0/13
- 104.24.0.0/14
Have opened a bug report, seems to be a few people experiencing this issue
https://github.com/home-assistant/core/issues/52718
I’m running the latest possible firmware and it’s still an issue.
Have opened an issue on github https://github.com/home-assistant/core/issues/52718