# WSL2 & Docker-compose **URL:** \ **Category:** Ignition\ **Tags:** ignition80\ **Created:** [September 3, 2021, 9:15pm UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615 "2021-09-03T21:15:02Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [September 3, 2021, 9:15pm UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/1 "2021-09-03T21:15:02Z")
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 @kcollins 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: ```auto version: "3.8" services: ignition: image: kcollins/ignition ports: - "4000:8088" volumes: - "./template_backup.gwbk:/restore.gwbk" - ignition_data:/var/lib/ignition/data environment: GATEWAY_ADMIN_PASSWORD: password IGNITION_UID: 1000 IGNITION_GID: 1000 volumes: ignition_data: driver: local driver_opts: 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 ---
**Author:** ![Kevin.Collins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.collins/32/13497_2.png) [@Kevin.Collins](https://forum.inductiveautomation.com/u/Kevin.Collins)\ **Post date:** [September 6, 2021, 4:31am UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/2 "2021-09-06T04:31:57Z")
Good day! 👋 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](https://github.com/thirdgen88/ignition-docker), you could create your own image where `ignition` user would be a custom UID/GID. With `kcollins/ignition:8.1.9` (see [PR #75](https://github.com/thirdgen88/ignition-docker/pull/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](https://github.com/tianon/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! 🕶 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! ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [March 22, 2022, 9:47pm UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/3 "2022-03-22T21:47:13Z")
By any chance do you know the timeline for these to be added to the `inductiveautomation/ignition` image? On a Mac my life is easy and MacOS creates all files under `:staff`, same with docker on windows `:` However when you go to do this on linux, it decides to make everything `root:root`, and so we are forced to use your `kcollins/ignition` image and provide `1000:1000` for the UID and GID. Without doing that, it makes version control really difficult in mounted volumes, because either you sudo every command you run, or you get permission denied errors all over the place. ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [March 23, 2022, 2:53pm UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/4 "2022-03-23T14:53:25Z")
We’ve had this in the backlog for a while. In the meantime, I’ve successfully implemented a good solution in `kcollins/ignition` as you mention. I’ve went ahead and updated the ticket here on our side with some of the updated thinking on this–hopefully we can get to it sooner vs later. It will likely be opt-in for `inductiveautomation/ignition:8.1.x` (i.e. if you don’t specify anything, it will continue to run as-root like today). ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [April 2, 2022, 2:52am UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/5 "2022-04-02T02:52:28Z")
> [@kcollins](#): > > I’ve went ahead and updated the ticket here on our side with some of the updated thinking on this–hopefully we can get to it sooner vs later. It will likely be opt-in for `inductiveautomation/ignition:8.1.x` (i.e. if you don’t specify anything, it will continue to run as-root like today). Saw this on another forum post and thought, hmm why does that sound ironically familiar? 😂😂 > [@\[Bug-5368\] Ignition Gateway Service User](https://forum.inductiveautomation.com/t/bug-5368-ignition-gateway-service-user/57914/1): > > Our team is following this article:[Ignition Security Hardening Guide | Inductive Automation](https://www.inductiveautomation.com/resources/article/ignition-security-hardening-guide) > > ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/8/0805836ebafe56a6993411065d135dc4370cb848.png) ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [April 2, 2022, 2:54am UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/6 "2022-04-02T02:54:47Z")
The good news is that the addition of `IGNITION_UID` and `IGNITION_GID` environment variables in `inductiveautomation/ignition` image just got merged today and should be in the `nightly` tag tomorrow! It pretty much works the same as `kcollins/ignition` image. EDIT: Thankfully, the bug in that post regarding `-1 * 100` ending up being reported for the process CPU load doesn’t seem to manifest when using a standard user account on Linux. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [April 2, 2022, 3:03am UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/7 "2022-04-02T03:03:04Z")
> [@kcollins](#): > > The good news is that the addition of `IGNITION_UID` and `IGNITION_GID` environment variables in `inductiveautomation/ignition` image just got merged today and should be in the `nightly` tag tomorrow! Woohoo! Question, will this back port to versions older than 8.1.17 containers? so that the developers who are stuck on something like 8.1.15 gateways for a while can use this feature as its version agnostic? Separately, a more linux question, when re-creating a container with this, prior to rebuilding the container should all files in the data folder (or wherever a bind mounted volume may be) be modified for use by the desired group? Currently the rough solution I have been using is a `chmod -R a+rwX directory/path` on the folder being used. In this case we would either want to set the GID to 1000 so it acts as the user, or put the user and the gateway in a common group and perform `chgrp -R group_name directory/path`? ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [April 2, 2022, 3:12am UTC](https://forum.inductiveautomation.com/t/wsl2-docker-compose/50615/8 "2022-04-02T03:12:54Z")
> [@kgamble](#): > > Question, will this back port to versions older than 8.1.17 containers? so that the developers who are stuck on something like 8.1.15 gateways for a while can use this feature as its version agnostic? We won't be back-porting this and rebuilding+pushing older Ignition versions back up to Docker Hub, no. However, once this gets to release, I'd be happy to put together a derived image that can be built against one of those older upstream images to _shim_ in this functionality. It will look very similar to what is mentioned [here](https://forum.inductiveautomation.com/t/specifying-modules-on-gateway-docker-compose/50361/3). > [@kgamble](#): > > Separately, a more linux question, when re-creating a container with this, prior to rebuilding the container should all files in the data folder (or wherever a bind mounted volume may be) be modified for use by the desired group? Currently the rough solution I have been using is a `chmod -R a+rwX directory/path` on the folder being used. In this case we would either want to set the GID to 1000 so it acts as the user, or put the user and the gateway in a common group and perform `chgrp -R group_name directory/path` ? With this new configuration, the entrypoint script still runs as root and will automatically `chown -R` (for the most part, there is some advanced handling built into there for symlinks, too) files under `IGNITION_INSTALL_LOCATION` (including under any bind-mounts or volumes in the tree) to the target `UID:GID` specified. It will not modify permissions, just ownership.