grvn

I now see that I was very late to the party when I created https://forums.unraid.net/topic/152340-support-rootless-podman-as-container-runtime/ a year ago. Since I created the RFE I've been trying to get "rootless" to work. I can't say I'm an expert but I'm interested and would really like this to work. So far, I haven't been able to get docker rootless to work, it seems to be up and running and the daemon is working, but trying to start a container fails because of permissions. I've had more success with podman but there are still things to do before I would call it "stable and ready".

I've been playing around a bit in unRAID and containers, both with podman and with docker. One key feature I would like to achieve is running "rootless". This is for my home use, I might be called a "power user" but for my home use I want something stable, easy and secure. The secure part is the biggest driving factor why I created this RFE but I've also seen what happens when the "single point of failure", the docker daemon, breaks or becomes unstable. docker seemed to be quite straight forward, Clean out everything docker and do a fresh install of it Edit /boot/config/go to create files touch /etc/subuid /etc/subgid Add one line at the end of /boot/config/docker.cfg DOCKER_OPTS="$DOCKER_OPTS --userns-remap=default" The problem that arises is that no container can be created. try starting a container without explicit --userns=host failes with docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "proc" to rootfs at "/proc" So far, I haven't been able to figure out the problem... it might be something with how unRAID handles users and permissions in its special way. I thought podman was going to be trickier, To install the package I first needed to find it or compile it myself... I've done both ways by now. ( installed the one from https://forums.unraid.net/topic/152340-support-rootless-podman-as-container-runtime/#findComment-1365777 ) Installation was very straight forward, I followed https://serverlabs.com.au/blogs/guides/installing-slackware-packages-on-unraid... some dependency hell later ( i forgot to install all dependencies ) and podman was working. Running podman without any configuration at all worked ( could be because step 2 from the docker installation was still present in /boot/config/go ), the container got downloaded and hello-world was displayed. Then came the configuration, everything done from /boot/config/go. Create user, create /etc/{subuid,subgid}, copy configurationsfiles from /boot/config/* to their proper places. I also created an alias for docker that points to podman... but that got a little bit tricky since unRAID seemed unsure if docker was started or not... and integrating with the webGUI is not something I got working yet. More work needs to be done before I can say "I got podman fully working on unRAID" but it seems doable.

Docker Inc. was the first company to give the users an easy-to-use way to isolate processes through Linux namespaces, cgroups etc. But its implementation came with a lot to desire when it comes to security and stability. docker runs as a daemon with root access, which means that the daemon is a single point of failure and the security has been applied as an add-on. Since docker was released other companies has implemented similar kind of easy-to-use way of isolating processes, but have taken the lessons learned from Docker Inc.s' implementation and done more stable and secure implementations. The most common one being podman. Podman is created as a drop-in replacement for docker. You can create an alias "docker" that points to the podman binary and most things will work right out of the box. Unlike docker, podman doesn't use a daemon and can run completely rootless. By giving the users of unraid the ability to use rootless podman instead of docker, you will give the users a more secure and stable platform than the alternative while still giving use the ability to run containerized workloads.