MichaIng

Defined here: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi#L1008-L1014 Hence the overlay would be: ``` /dts-v1/; /plugin/; / { fragment@0 { target = ; __overlay__ { status = "okay"; pinctrl-names = "default"; pinctrl-0 = ; };...

Use `RUN_UID` and `RUN_GID` instead: https://github.com/motioneye-project/motioneye/blob/main/docker/Dockerfile#L4-L6

Ah yeah right, that only works when generating a new image. motionEye (and `motion`) within the container runs as `motion` user, mapped to UID/GID 0 within the container, by default,...

Docker containers run always as root anyway. There is a limited option to run it as different user (including the Docker daemon) though: https://docs.docker.com/engine/security/rootless/ But the access of the container...

In the end the question is what you want to protect from what: in case of camera recordings, usually they are somewhat sensitive, may violate local privacy regulations if made...

Did you run the commands in my last post of https://github.com/MichaIng/DietPi/issues/7830#issuecomment-3587120625 to really update Portainer? I.e. can you verify it is v2.33.5?

I see the new Portainer starting, up, so that part looks good: ``` Dec 03 14:56:32 dell1 a25d81cda5c6[17856]: 2025/12/03 10:56PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:636 > starting Portainer | build_number=243 go_version=1.24.9 image_tag=2.33.5-linux-amd64 nodejs_version=18.20.8...

I am also no Portainer expert: So stacks are automatically generated when starting containers with Docker Compose, as far as we just tested. And in your case, it seems like...

Makes sense that pulling again all images/stacks solved it. A bit radical, but probably easier than re-attaching each container manually to the related stack. I am glad this solved it...

This issue is solved with the motionEye 0.43.y hence the edge container builds from [here](https://github.com/motioneye-project/motioneye/pkgs/container/motioneye), right?