Spring build step fails to copy resources to target folder

pgRouting pgrouting-users
1

Hello!

I have a Java project that builds with Maven and uses pgrouting/pgrouting:16-3.4-3.6.1 Docker image as a resource. The app runs fine on Mac but when running on Linux I get failed with AccessDeniedException when Maven tries to copy resource files into the /target folder. This seems to be because the files created by docker compose command is owned by some system/root user. Especially the .s.PGSQL.5432.lock file is owned by user dnsmasq and has permissions 600, meaning only that user can read the file. I’m not sure if this is an error on my side, some configuration for the Docker compose yml, or (more unlikely) a bug. Since the image runs fine on Mac I’m guessing there is some difference with file system handling on Mac vs. Linux. I have not seem this kind of error before and do not know where to look for an answer… Anyone here have a suggestion?

My docker-compose.yml:

services:
  pgrouting:
    image: pgrouting/pgrouting:16-3.4-3.6.1
    ports:
      - "5432:5432"
    volumes:
      - ./db/data:/data
      - ./db/logs:/logs
      - ./db/var:/var
      - ./db/tmp:/tmp
    environment:
      - POSTGRES_DB=local_db
      - POSTGRES_USER=local_user
      - POSTGRES_PASSWORD=ct_admin_ui_local_password

My workflow is to start docker by docker compose up -d in the src/test/resources dir and then run the Spring app. When the build is done Spring tries to copy all resources into /target and this is where it fails, due to incomplete permissions for the above mentioned file.

2

I haven’t had a chance to test this out on my linux dev.

Can you try one more test. Want to confirm this isn’t an upper stream issue. The pgrouting builds are built against postgis docker build postgis/postgis:16-3.4

Can you try that images and see if you run into same issues launching

3

I’m not familiar with how spring apps are set up, but I was able to launch with your docker-compose script just fine in an ubuntu 24.04.

docker-compose up -d
docker-compose exec pgrouting psql -U local_user -d local_db

I assume that worked too for you.

I do confirm that the ./db folder gets owned by root and not editable by my account that I launched docker-compose with. I have same behavior using the base postgis/postgis:16-3.4 and image postgres:16-bullseye.

I don’t have a mac so can’t compare and I’m pretty green with docker and never try to copy anything into a postgres docker volume.

Is there a particular reason why you need to copy things into the postgres docker volumes? @sanak any thoughts on this?

4

I indeed see the same behaviour when running the postgis image postgis/postgis:16-3.4 so maybe this belongs to upstream community, then.

5

The compose file works for me too, there is no issue with the image itself. It’s rather how Spring work with it that seems to be causing these problems for me. This workflow has worked for us before, with other images, hence I am investigating what could have caused it now. Spring apps (Maven, in this case) works by compiling all class files into /target folder and as one of the last steps it also copied all relevant resources to the /target folder so to make sure resource references are still valid, I guess.

I’m actually not sure why we have these volume mounts in the compose file, I am not the original author of the docker set up but merely copied it from another project with the same requirement and function. I have asked a colleague for more information on this, waiting for the reply…

6

Apparently my colleague use these volume mounts to persist data on the local machine between docker images. I don’t see this need for me at the moment but for the future it might be good to have that possiblity! For now I will remove the mounts and the app will work fine without them. And since my colleague use Mac it’s not a problem there. :person_shrugging:

Would you suggest checking in with the postgis-people instead?

7

I have the same issue with the postgres:16-bullseye image which is upstream from the postgis/postgis:16-3.4 so I think ultimately the problem with permissions is upstream from postgis too. There is a lot going on in the postgres official dockers - https://hub.docker.com/_/postgres

According to this it looks like you might be able to do this by explicitly running as a user as documented here - docs/postgres/README.md at master · docker-library/docs · GitHub.

I also read here - how to do it in docker-compose, but those instructions didn’t seem to work for me, so I guess I’m missing something - Using current user when running container in docker-compose - Stack Overflow

8

Thank you for those posts, now I actually understand the problem. I will close this issue, :pray:

1 Like