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" 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