I’m using docker-compose having the same problem (docker-compose is so wonderful to use though… in general)
Yes and the problem still exists with the latest “stable” docker-compose 2021.7.2
I implemented what @Nakazen explained and it worked for me on my RPI4 self-managed container.
Now, the “funny” fact is that I have an rpi3 with a supervised installation and I didn’t have the issue when upgrading. I always assumed the “container” and “supervised” installation used the same image 
Nevermind. Another workaround is to run the container “privileged”, and the supervised install runs all containers as privileged.
You just saved my day 
Thx for posting the solution 
The problem still exists with the latest “stable” docker-compose 2021.7.3 even with
privileged: true
in my docker-compose.yml file
Should I start a separate thread in this forum?
1 Like
Many thanks to everyone on this thread. Banging my head all morning and into the afternoon trying to figure out what was going on and how to fix. Finally did a search that yielded this thread (previous searches didn’t turn it up till I tried just the right criteria). Thought I was stuck in the mud. Again, THANK YOU all.
Basic question, if anyone cares to answer. I’ve never had to roll back an upgrade. I use portainer. I am obviously missing something because every time I tried to go back to the safety of my 2012.06.x image, Portainer restarted with the 2021.07.x image I pulled today, even after I deleted it. If anyone has a pointer on rolling back, I’d appreciate it. I’m assuming it is easy and I’m just missing it.
Thank you m8, i had the same issue and I solved with those steps
I will try Stefano’s answer which looks like the way to go, although not sure on my pi 3. In the meantime, on my raspberry 3 I got it working by using the seccomp=unconfined option. I assume that disables all the extra security so be aware of that.
See this: Seccomp security profiles for Docker | Docker Documentation
In my docker compose file it was this:
version: '3'
services:
homeassistant:
security_opt:
- seccomp:unconfined
using libseccomp2 buster-backports breaks networking on a docker cluster, causing randomly reboot in containers like traefik, rabbitmq, etc…
More informations here: https://github.com/alpinelinux/docker-alpine/issues/135
Any other way around this ?
1 Like
Thanks all who posted here. I ran into this issue when I updated my instance this morning and was able to fix it by pulling the .deb for the updated library and installing per kwende’s (Ben Rush’s) instructions.
It was a bit of a challenge to figure out which solution to try first. Not all posts referenced the OS in use. I saw the ones that specified buster backports but the first line referenced an Ubuntu server so I didn’t read on but skipped to the next post. In retrospect, I would have preferred configuring backports rather than just downloading the .deb since it would have kept me within the package system a little more.
Anyway… problem solved (at least for now.) There are a number of distros that can run on a Pi (Raspbian 32 and 64, Debian, Arch …) it would be helpful to know which environment a particular fix worked on.
Thanks!
Edit: I too wonder if I should be fetching images from Docker hub or Github.
Tip: Make sure you are using the latest Docker.
I have two RPIs and @sReggy answer worked on one and not the other.
I did docker --version and realized that my apt upgrade wasn’t updating it. I’m still not sure why, but I used get.docker.com and it worked perfectly.
Thanks, the missing library solved my problem.
Also tried with apt-get update/upgrade but wasn’t solving
For everyone coming here from IOTstack, this fix worked for me to get Home Assistant Docker running in IOTstack 
found for me too. It started after installing the libseccomp2 on rpi3
Thankyou so much for documenting this fix.
1 Like