OneDev does not support rootless mode yet. I am changing this as an improvement request.

This is now possible in build #3680 by specifying appropriate docker sock path in more settings of a docker executor.

I have the same problem while using a kubernetes executor. Is there any advice?

This feature is not available for k8s executor. Does k8s even has the rootless option to run pod?

Yes, kubernetes does provide functionality for this. Im im not wrong, just change the /root/auth-info/ dir to the current user & change the working directory to /tmp or the user home with rwx perms. Alternatively you can add another functionality where your init container modifies the rwx permissions in the original container.

But first option is way better & more secure. Tell me if you need some help on the kubernetes site ;)

Im missing all the time to open this issue, in this one.

Thanks for the info. Running as normal user inside container needs some substantial change to OneDev CI process.

My understanding is that as long as docker daemon itself runs as normal user, it is safe even if OneDev runs as root inside container (and all files it creates/touches will be under normal user at host machine).

Yes, but host and container are sharing the same kernel. As an example for a simple database. It mounts persistent folders into the hostsystem. Writing is on both sites allowed. The container runs inside with user root ( postgres process) and modifies data. Hostsystem sees: GID/UID 0:0 (typical root) modified data in this mounted dir. If you now spin this backwards:

You mounted a folder from host to container. The folder you mounted is as example /etc. This folder is by default for root only 0rw:0rw Your process inside the container is run as a nonroot user. Then the process is not permitted to read this file.

--> Permission denied.

Alwas run with the lowest required privileges ;)

Thanks for detailed info. Will investigate more on this.

Big appreciate! I can give you more details if you need them

State changed as code fixing the issue is committed (6ff40b2c)

State changed as build #4781 is successful