Dockerizing Spring boot application getting permission denied

Question

I am trying to dockerize a spring boot application through mvn command

mvn spring-boot:build-image

but I am getting permission denied error.

[INFO]     [creator]       Spring Cloud Bindings 1.7.1: Contributing to layer
[INFO]     [creator]         Downloading from https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.7.1/spring-cloud-bindings-1.7.1.jar
[INFO]     [creator]         Verifying checksum
[INFO]     [creator]         Copying to /layers/paketo-buildpacks_spring-boot/spring-cloud-bindings
[INFO]     [creator]     unable to invoke layer creator
[INFO]     [creator]     unable to link /layers/paketo-buildpacks_spring-boot/spring-cloud-bindings/spring-cloud-bindings-1.7.1.jar to /workspace/BOOT-INF/lib/spring-cloud-bindings-1.7.1.jar
[INFO]     [creator]     symlink /layers/paketo-buildpacks_spring-boot/spring-cloud-bindings/spring-cloud-bindings-1.7.1.jar /workspace/BOOT-INF/lib/spring-cloud-bindings-1.7.1.jar: permission denied
[INFO]     [creator]     ERROR: failed to build: exit status 1
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

Answer 1

There seems to be some issues with file permissions, which is preventing the symlink o be created.

If you are building a Linux container from a Windows machine (which has no notion of Linux file permissions) and there are COPY or ADD directives in the Dockerfile then that could be the problem.

If that is the case you could add a RUN directive after the COPY directive of the Dockerfile that sets the permissions of the copied files, for exmaple:

COPY . /path/to/target # Copies current directory to /path/to/target in container
RUN chmod -R 777 /path/to/target # Recursively set file permissions

The RUN command that sets the file permissions create some extra layers in the final image, if you want a "cleaner" image with fewer layers you can utilize multi-stage builds and do the file permission changes in a separate image before you copy to the final one. To do this, add the following to the top of your Dockerfile

FROM ubuntu:latest as permissions
COPY . /files
RUN chmod -R 777 /path/to/target # Recursively set file permissions

# Add COPY and RUN commands for all files/folders copied into the image

In the rest of the Dockerfile update your COPY statements to copy from the temporary permissions image instead of directly from the host:

COPY --from=permissions /files /path/to/target

Another option if you are building from a Linux shell (if you are on a Linux machine or are using for example wsl in windows) is to just set the file permissions correct before invoking mvn spring-boot:build-image, like below

chmod -R 777 .

Without seeing the Dockerfile it is not possible to know for sure though

Answer 2

To me it seems that there is a conflict between your spring boot and spring cloud versions, or there is a conflict between spring boot and build-image plugin.

This file might not exists, or there is a version conflict.

spring-cloud-bindings-1.7.1.jar

Sometimes "permission denied" might also mean that the file is not found.

I suggest you to try "com.spotify" "dockerfile-maven-plugin" instead:

            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>dockerfile-maven-plugin</artifactId>
                <version>1.4.13</version>
                <executions>
                    <execution>
                        <id>default</id>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <repository>skyglass/${project.name}</repository>
                    <tag>${project.version}</tag>
                    <skipDockerInfo>true</skipDockerInfo>
                </configuration>
            </plugin>

Make sure you adapt plugin configuration correspondingly.

In the above example configuration, when you run:

mvn clean install

it will automatically build docker image with the name:

skyglass/${project.name}:${project.version}

I always build docker images with this plugin, and never had any issues. This is one of my spring boot projects, where I use it: https://github.com/skyglass-examples/customer-management-keycloak

You can find full pom.xml there.

If it doesn't solve your issue, or you can't use "com.spotify" "dockerfile-maven-plugin" for some reasons, then I suggest you to share your "pom.xml" file, maybe it will help to find the reason.

P.S. I actually once had some security permissions error with docker, using "com.spotify" "dockerfile-maven-plugin", but I'm not sure it was similar to your issue.

In my case, I had to remove "/Users/dddd/.docker" folder on my MacOS machine (or rename it to ".docker.tmp") and it solved the issue. You can also try to rename ".docker" folder to ".docker.tmp" and see if it helps. But this is just a wild guess.

Answer 3

You shoud post your Dockerfile or any other info related to that image building first.

things you should consider:

1. Usually when people build images on their hosts they have their "username" included into "sudo" group and "their user" group. not the same in your image.
2. Sometime in docker building process you should specify another user aside from your root, since users in your host are not on image or container. (you can run "docker run -u ..." ie)
3. Sometimes packages manager also have a group and user. Not sure about maven, (you should also have that user or group in your container)
4. Is not only "who owns a directory" but "when is owned when task is executed"
5. Is not about just setting file permission but also ownership.
6. always check what user in your container to compare with your host "docker exec -it cat /etc/passwd"

to check differences between what that image built use "docker exec -it ls -lah /dir" with that you can list specific folders are affected in this process.

Answer 4

I had the exact same issue, and was able to resolve it by simply upgrading the docker engine used to build the image. In my case, the old docker version that did not work was 17.10. My current version is Docker version 20.10.9, build c2ea9bc, and the build works.