Due to a recent containerd 1.7.24 update, your /dev/net/tun:/dev/net/tun mapping needs to be moved from the volumes section to the devices section.
Don’t be like me and realize this AFTER you leave home for the holidays.
Thank you for your sacrifice. It will not be forgotten.
Let this be a lesson to implement a change freeze 1 week before leaving home for a holiday/trip/etc. 😁
Luckily I realized that I could Cloudflare-tunnel my Portainer UI out to a long random-nonsense subdomain name.
That allowed me to fix it (and then immediately kill the tunnel – not a fan of exposing Portainer to the internet).
Adding this device this also appeared to fix my https://github.com/haugene/docker-transmission-openvpn container that recently died. (And not simply giving it elevated privileges, as was previously recommended)
https://github.com/haugene/docker-transmission-openvpn/issues/2883
It appears that these issues all originate from an update to runc (which is used by containerd): https://github.com/containerd/containerd/issues/11078
Kind of crazy it wasn’t like this from the start.
Luckily my stack is only auto updating every month and only my downloader was impacted by this breaking change.
This is the kind of bullshit I don’t have time for, when shit gets broken in userspace because someone wanted to change the location of something.
Makes sense to move it where it’s appropriate.
No one forces unattended updates. And containerd is already living in the userspace.
If every dev would live on a kernel level stability approach we’d will not have a containerd release at all.
