VSCode Devcontainer error "A mount config in is invalid."

[vansen]

Describe the bug
When trying to reopen the container in vscode I get a popup showing the following error: "A mount config is invalid. Make sure it has the right format and a source folder that exists on the machine where the Docker deamon is running."

Could someboby please provide guidance - much appreciated. Thanks!

To Reproduce
Steps to reproduce the behavior:

1. Open VSCode where the .devcontainer folder is present.
2. VSCode offers to load the devcontainer, confirm
3. Popup with error is shown

Expected behavior
Devcontainer should open without error

Screenshots
None, error shown as popup with above message

Desktop (please complete the following information):

• OS: Windows 11
• VSCode 1.91

Additional context
I am running this on a Windows machine.

[jgbradley1]

Is Docker installed and turned on on your machine? Is WSL installed and setup as well?

[shyamsridhar123]

I am having the same issue as well. WSL installed for ubuntu and configured with my docker desktop

[lijq111]

I had the same issue before. Change the mount .ssh path to absolute .ssh path works for me. Hopefully we can get official solution.

[eyast]

In my case (Using windows + WSL and Docker), I had to make few modifications to get the deployment to work:

1. change devcontainer.json so that both mount points point to a folder on my machine, by making the lines look like this ${localEnv:USERPROFILE} (because apparently on Windows, the home folder is called USERPROFILE.
2. Not related to this post but speaking about getting things to work on Windows (with an old git configuration), I had some .sh files where I needed to change the end of line from CRLF to LF. I did that with notepad++ by searching for \r\n and substituting that with \n. The two files I modified were entrypoint.sh and deploy.sh

[jgbradley1]

Thanks @eyast.

1. This makes sense. The goal is for the devcontainer to be platform-agnostic so we’ll have to look into it and see what can be done to express the mount points in a generalized way (or perform some kind of check for UNIX vs Windows platform and set the mount point accordingly).

2. I thought we took care of the LF vs CRLF issue already by using a .gitattributes file. But it looks like a couple more settings are needed to enforce LF across the entire repo. We may have missed some *.sh files when we normalized all files in the repo to use LF.

[jgbradley1]

@eyast regarding the line endings issue, I previously read this article when trying to figure out how to enforce LF across the repo.

I think we're doing it correctly but that article also suggests adding a .editorconfig because some editors in Windows don't respect the .gitattributes file. It's hard for me to test as I don't have the same setup as you but I started a branch here with the .editorconfig file added. Can you checkout that branch and see if you still see CRLF line endings on the files you changed?

Tip: you can run git ls-files --eol at the root of the repo for a faster way to check line endings. When I run it on my Mac, I don't see any files with CRLF.

[eyast]

Hi @jgbradley1 Thanks for sharing - I didn't know either. I definitely have had that issue with other repos before, but I never looked at a long term solution other than modifying the files on my machine. I just looked at the branch and it still appears as CRLF (as per the vscode icon in the status bar + inspection in Notepad++). I tried building the devcontainer but it failed. For reference, that's how the deployment fails when it's CRLF:

Running git ls-files --eol returns this:

C:\myprojects\graphrag-accelerator-crlf>git ls-files --eol
i/lf    w/crlf  attr/text=auto          .azdo/azure-pipeline.yaml
i/lf    w/crlf  attr/text=auto          .devcontainer/Dockerfile
i/lf    w/crlf  attr/text=auto          .devcontainer/devcontainer.json
i/lf    w/crlf  attr/text=auto          .devcontainer/entrypoint.sh
i/lf    w/crlf  attr/text=auto          .dockerignore
i/lf    w/crlf  attr/text=auto          .editorconfig
i/lf    w/crlf  attr/text=auto          .gitattributes
i/lf    w/crlf  attr/text=auto          .github/ISSUE_TEMPLATE/bug_report.md
i/lf    w/crlf  attr/text=auto          .github/ISSUE_TEMPLATE/feature_request.md
i/lf    w/crlf  attr/text=auto          .github/dependabot.yml
i/lf    w/crlf  attr/text=auto          .github/workflows/dev.yaml
i/lf    w/crlf  attr/text=auto          .gitignore
i/lf    w/crlf  attr/text=auto          .pre-commit-config.yaml
i/lf    w/crlf  attr/text=auto          .secrets.baseline
i/lf    w/crlf  attr/text=auto          CODEOWNERS
i/lf    w/crlf  attr/text=auto          CODE_OF_CONDUCT.md
i/lf    w/crlf  attr/text=auto          CONTRIBUTING.md
i/lf    w/crlf  attr/text=auto          LICENSE
i/lf    w/crlf  attr/text=auto          README.md
i/lf    w/crlf  attr/text=auto          SECURITY.md
i/lf    w/crlf  attr/text=auto          TRANSPARENCY.md
... (more files that all have the same value for the first 2 columns)...
i/lf    w/crlf  attr/text=auto          infra/deploy.parameters.json
i/lf    w/crlf  attr/text=auto          infra/deploy.sh
i/lf    w/crlf  attr/text=auto          infra/helm/graphrag/.helmignore
... (more files)...

[HAFNIAxSimon]

Hey, I have the same issue. Running the DevContainer on a windows machine (Azure DevBox)

1. Solved the issue: replace with USERPROFILE
2. I tried to checkout your branch @jgbradley1, but still appear as CRLF.

[jgbradley1]

I've started a PR that may address these issues. Please take a look at the branch now and let me know if the issues still persist.

Note: According to my research, Windows does not create a HOME environment variable unless it's been explicitly created by the user...but USERPROFILE is created. I also wonder if we chose to not use either ENV variable and instead referenced a user's home directory with~ if that would be more platform-agnostic.

[jgbradley1]

Taking a suggestion from this article, can one of you try to clone the repo down with the following command:

git clone <repository> --config core.autocrlf=true

And see if the line ending issue exist?

If this works, I can update the documentation for Windows users to clone the repo down correctly. For your existing git installation, I think you can configure git globally so this is no longer a problem for future git clones by running git config --global core.autocrlf true.

[HAFNIAxSimon]

Hey @jgbradley1, did not seem to work. I still had to update the 2 scripts mentioned by @eyast with LF end of line sequence.