I would like the spring-boot gradle plugin to support writable volumes within the BootBuildImage Task. There should be some way to configure the task, such that a volume can be written by a non-root user used in the container.

I am aware, that this problem probably goes beyond a simple implementation, and would maybe require discussion, or maybe would possibly need a solution 'upstream' (paketo) solution. My knowledge of the topic is limited, so I do not dare to propse a full solution - I am just here to draw attention to this use case - it seems to me that this should not be an uncommon one.

Motivation:

The microservice I am working on needs write Access to some directory on the host. In a docker environment, this directory should be a volume. For the sake of the argument let's assume it is supposed to be mounted to /var/mypath within the container. When created by docker, this volume is owned by the root user and group:

cnb@fe6a02b48653:/$ ls -la /var/mypath total 8 drwxr-xr-x 2 root root 4096 Apr 27 05:43 . drwxr-xr-x 1 root root 4096 Apr 28 05:28 ..

The bootBuildImage allows me to create an OCI. The spring boot application is then run by a cnb user - which can not write to /var/mypath.

My Related SO post: https://stackoverflow.com/questions/67280070/write-access-on-volume-for-cnb-docker-image Another one: https://stackoverflow.com/questions/64353768/can-bootbuildimage-create-writeable-volumes

Solution attempt 1: Manuyally chown the volume to the cnb user from within the container after it was created by docker. It appears that only works in some environments - doesn't work for me.

chown cnb /var/mypath/ chown: changing ownership of '/var/mypath/': Operation not permitted

Hacky solution 2: run the container as root. This is of course not desirable.

The 'typical' solution: If the dockerfile was written manualle, one would probably add something like

RUN mkdir -p /var/mypath; chown -R cnb:cnb /var/mypath

at the top of the docker file, but that does not seem like an option, if it is possible at all. A point of the CNB is to not have to write the docker file.

Another solution: make a docker layer - as suggested by the user Stuck in the second SO post linked above. More Details from the same user in another SO post here: https://stackoverflow.com/questions/65013814/error-failed-to-launch-determine-start-command-when-there-is-no-default-proce

Requiring the user or CI to execute another docker build on top still seems like it is not optimal - maybe there another solution. However, if this in fact is the solution, maybe it would have to be integrated into the builder image - in that case please point it out and my apologies - then maybe I could open an issue on the paketo gradle builder instead, but this one could at least be referred to.

Comment From: wilkinsona

There has already been some discussion of this on Gitter. With that and your existing question on Stack Overflow, this issue is only going to dilute the discussion further.

IMO, the problem you are facing is really a Docker problem. As discussed on Gitter there are various ways that people have solved it such as chowning the volume or mounting it beneath a path already owned by the required user. The former didn’t work for you for some reason, but perhaps the latter will work.

When you build an OCI image with the bootBuildImage task it is built using cloud native buildpacks. If the approaches recommended by the Docker community for mounting a volume for a particular user are not working, it’s possible that’s due to how the image is created. You may want to reach out to the buildpack community on Slack. If you do so, please cross-reference all the existing discussions to provide context and avoid duplication of effort.