WSL2 & Docker-compose

I am working with one of my engineers on trying to resolve an issue with VSCode, WSL & Docker fighting each other and I am not sure if my issue at this point is related to the docker image file permissions, vscode or linux, but hopefully @kcollins1 you might can help this will solve the issue for others in the future here.

They are running a compose network in WSL, and interacting with it through VSCode for direct file manipulation and source control management. However we are having issues where the WSL file permissions on the generated content are all switched to the ignition GID:UID and VSCode isn’t able to save anything, without resetting the ownership on each new file created. As well all version control doesn’t work without changing ownership, because git can’t create its necessary files without constantly sudoing

We tried setting the GID:UID to 1000 (to match the user) but that didnt seem to solve it, and we are not exactly sure on how to allow for the direct file interaction while not screwing up the container permissions.

This is our docker-compose, using the bind mount so that we can achieve direct file access in the local directory:

version: "3.8"
    image: kcollins/ignition
      - "4000:8088"
      - "./template_backup.gwbk:/restore.gwbk"
      - ignition_data:/var/lib/ignition/data
      IGNITION_UID: 1000
      IGNITION_GID: 1000
    driver: local
      type: none
      device: "./ignition_data"
      o: bind

The end goal here is the ability to run multiple gateways in a network, with the data directories all mounted into sibling folders, to manage the entire architecture.

Note: This practice has frequently had me shaking my fist at the sky and wishing this developer was also on MacOS/Linux instead of windows

Good day! :wave: First off, I see your use of IGNITION_UID and IGNITION_GID in the environment. These are were only available as build arguments when creating the image. By adjusting these with a docker build --build-arg IGNITION_UID=1000 --build-arg IGNITION_GID=1000 ... against kcollins/ignition, you could create your own image where ignition user would be a custom UID/GID.

With kcollins/ignition:8.1.9 (see PR #75 for details), the container now starts as root and the entrypoint takes care of synchronizing filesystem permissions (while root) before stepping down to ignition user for the actual running of the container. This is a typical practice in most modern container images nowadays, via the gosu (there are also other alternatives) utility.

So, the good news is that if you change your image tag up there to image: kcollins/ignition:8.1.9, those environment variables will now actually take effect! :sunglasses: You’ll see some informational output in the logs that lets you know that filesystem permissions are being adjusted–this step can take a little bit of time, but is only required the first time you start a new container.

Let me know if you have any further questions or issues!

1 Like