Visual Studio Code Dev Containers file permissions

[jdh80]

While running dev containers in this configuration:

• Docker Desktop running with WSL backend
• Enhanced Container Isolation (ECI) enabled

Following these steps:

1. Starting a container of my own
2. Asking VSCode to create a dev container
3. Stopping the container in step 1
4. Asking VSCode to rebuild without cache the dev container

We receive the following error:

Failed to save 'test.txt': Unable to write file 'vscode-remote://dev-container+7b22686f737...65227d7d/workspaces/eci-test/test.txt' (NoPermissions (FileSystemError): Error: EACCES: permission denied, open '/workspaces/eci-test/test.txt')

After investigation, it is determined that this error occurs due to a limitation of Windows WSL, as it does not occur on Hyper-V or Mac/Linux. The 9p filesystem has a limitation where it does not yet support idmapping, which would allow the files to show up with proper ownership inside the ECI-backed container. Because of this, files show up as nobody:nogroup when rebuilding the dev container without cache.

This is the recommended workaround and it works for files created via the command line and the UI:

Place this Dockerfile inside the .devcontainer dir in the workspace:

# NOTE: Replace with desired dev container image
FROM [mcr.microsoft.com/devcontainers/javascript-node:1-18-bullseye](https://mcr.microsoft.com/devcontainers/javascript-node:1-18-bullseye)

# Substitute /bin/sh with /bin/bash (because we need it to read the umask from /etc/profile)
RUN echo '#!/bin/bash\nexec /bin/bash "$@"' > /bin/new-sh && \
    chmod 755 /bin/new-sh && \
    mv /bin/new-sh /bin/sh

# Append umask configuration to relevant shell profiles
RUN for f in /etc/profile ~/.profile ~/.bashrc ~/.zshrc; do \
        [ -f "$f" ] && echo -e '\n# Set umask to allow 0777 permissions\numask 000\n' >> "$f"; \
    done

Then configure the devcontainer.json file in that same directory as follows:

    // Comment out the base image; we will use a Dockerfile instead.
    //"image": "[mcr.microsoft.com/devcontainers/javascript-node:1-18-bullseye](https://mcr.microsoft.com/devcontainers/javascript-node:1-18-bullseye)",
	
    "build": {
        "dockerfile": "Dockerfile",
        "context": "."
    },
	
    // This tells VSCode to set the BASH_ENV=/etc/profile variable in "docker exec" commands it issues; it's 
    // needed so that when VSCode starts the code-server inside the dev-container, the server picks up the
    // modified umask in /etc/profile. This ensures files created via the VSCode UI pick up the umask.
	"containerEnv": { "BASH_ENV": "/etc/profile" },

Since this is a Windows host using WSL, the workspace is mounted from the Windows C:\ drive so all files show up with 0777 permissions anyway because Windows does not have the same file permission framework as Linux where running this would make all new files accessible to everyone.

We would like the documentation updated to reflect the above findings and look forward to 9p supporting idmapping in the future.

Cheers,

Docker Support

[ntrogh]

@chrmarti Can you look into this issue and confirm the changes needed to the container docs?

[chrmarti]

@jdh80 This only affects setups where the container bind mounts a Plan 9 filesystem and enhanced container isolation is enabled?

[jdh80]

Hey @chrmarti It affects any bind-mounts that reside on a filesystem that does not support the Linux idmapped mounts mechanism. For WSL, with kernel 5.15 (the current default), only ext4 and xfs filesystems support idmapped mounts, so any bind-mounts residing on other filesystems (e.g., 9p or others) will show up with nobody:nogroup inside the ECI protected container

[chrmarti]

@jdh80 Thanks for documenting the workaround. I think for now we should keep it in this issue to avoid making the documentation harder to go through. If this becomes a wide spread issue, we should also investigate a solution in code.

[ntrogh]

Added a link to the issue to our docs for users encountering this issue and looking for a workaround.