microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.67k stars 290 forks source link

Clone repository in container volume with Docker Compose fails due to permissions for non-existant folder #5388

Open Chuxel opened 3 years ago

Chuxel commented 3 years ago

Version: 1.59.0-insider Commit: e8a59bc6f920e731b47f0bc72263e82aba8b796e Date: 2021-07-22T05:13:00.851Z Electron: 13.1.7 Chrome: 91.0.4472.124 Node.js: 14.16.0 V8: 9.1.269.36-electron.0 OS: Darwin x64 20.5.0

Steps to Reproduce:

  1. On macOS, verify your local docker file share configuration does not include the /workspace folder. image
  2. Create a repository with a .devcontainer folder in it based on Docker Compose. e.g. pick Python 3 + Postgres from here: https://github.com/Chuxel/empty/tree/python-postgres
  3. In a new window in VS Code, run "Clone repository in container volume..." on the repository

Expected: Docker Compose-based dev containers start Actual: Errors. What appears to be happening is the existing "workspace folder" mount point in the docker compose file is still there, but ends up using the path inside the container instead... which is not allowed by Docker so a permissions error appears.

Starting empty_devcontainer_app_1 ... error

ERROR: for empty_devcontainer_app_1  Cannot start service app: Mounts denied: 
The path /workspaces/empty is not shared from the host and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> Resources -> File Sharing.
See https://docs.docker.com/docker-for-mac for more info.

ERROR: for app  Cannot start service app: Mounts denied: 
The path /workspaces/empty is not shared from the host and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> Resources -> File Sharing.
See https://docs.docker.com/docker-for-mac for more info.
ERROR: Encountered errors while bringing up the project.
[7584 ms] Command failed: docker-compose --project-name empty_devcontainer -f /workspaces/empty/.devcontainer/docker-compose.yml -f /tmp/docker-compose.repositoryContainer.yml up -d

Earlier in the log file you can see this path in the output:

[6533 ms] services:
  app:
    build:
      args:
        INSTALL_NODE: "true"
        NODE_VERSION: lts/*
        USER_GID: '1000'
        USER_UID: '1000'
        VARIANT: '3'
      context: /workspaces/empty
      dockerfile: .devcontainer/Dockerfile
    command: sleep infinity
    labels:
      vsch.local.repository: https://github.com/chuxel/empty
      vsch.local.repository.folder: empty
      vsch.local.repository.volume: empty-2ac6de8b1d5867ef93cf7058ea7e0781
    network_mode: service:db
    volumes:
    - /workspaces/empty:/workspace:cached
    - empty-2ac6de8b1d5867ef93cf7058ea7e0781:/workspaces:rw
  db:
    environment:
      POSTGRES_DB: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
    image: postgres:latest
    restart: unless-stopped
    volumes:
    - postgres-data:/var/lib/postgresql/data:rw
version: '3'
volumes:
  empty-2ac6de8b1d5867ef93cf7058ea7e0781:
    external: true
    name: empty-2ac6de8b1d5867ef93cf7058ea7e0781
  postgres-data: {}

In this case the docker-compose.yaml file includes the following:

    volumes:
      - ..:/workspace:cached

...which is required for the non-volume case.

If you add /workspace to your share config, it works even though the folder doesn't exist.

image

Chuxel commented 3 years ago

//cc: @bamurtaugh as well

EvanSchalton commented 2 years ago

I'm still experiencing this issue (even after adding the imaginary /workspaces dir in the docker dashboard) Anyone had any luck?

cyndi5 commented 2 years ago

Appreciate the workaround @Chuxel . That workaround works for me, macOS, non-root user vscode. I'll watch the repo for updates. 🙌

ijaouani commented 2 years ago

@Chuxel This workaround does not seem to work anymore on MacOS (we was using it since a long time) with latest version of Docker Desktop (4.12.0).

Have been able to repro using both 0.251.0 and prerelease v0.252.0 on a from scratch repo using nodejs-postgres devcontainer definition.

[7086 ms] Start: Run: docker-compose --project-name platform_devcontainer -f /workspaces/platform/.devcontainer/docker-compose.yml -f /tmp/docker-compose/docker-compose.devcontainer.containerFeatures-1663144450524.yml up -d --no-recreate
Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Starting platform_devcontainer_app_1 ... error

ERROR: for platform_devcontainer_app_1  Cannot start service app: error while creating mount source path '/host_mnt/workspaces/platform': mkdir /host_mnt/workspaces: input/output error

ERROR: for app  Cannot start service app: error while creating mount source path '/host_mnt/workspaces/platform': mkdir /host_mnt/workspaces: input/output error
ERROR: Encountered errors while bringing up the project.
[7938 ms] Error: Command failed: docker-compose --project-name platform_devcontainer -f /workspaces/platform/.devcontainer/docker-compose.yml -f /tmp/docker-compose/docker-compose.devcontainer.containerFeatures-1663144450524.yml up -d --no-recreate
[7939 ms]     at pF (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:222:2970)
[7939 ms]     at processTicksAndRejections (internal/process/task_queues.js:95:5)
[7939 ms]     at async dF (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:206:2361)
[7939 ms]     at async DF (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:263:2177)
[7939 ms]     at async to (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:263:3110)
[7939 ms]     at async Ak (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:383:8108)
[7939 ms]     at async Ok (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:383:7864)
[7959 ms] Exit code 1

I also tried with Docker Desktop For Linux (Ubuntu) with exactly the same symptom. The only diff is there is no way to put a fake path (it prevent Docker Desktop to actually start) so I have tried with / in File Sharing settings.

For now the only workaround that works for me was to remove these lines from docker-compose.yml def (since we are always cloning in a container volume and not using Open Folder in Container) :

volumes:
  - ..:/workspace:cached

But I think the root cause should be address.

coreyperkins commented 2 years ago

@Chuxel This workaround does not seem to work anymore on MacOS (we was using it since a long time) with latest version of Docker Desktop (4.12.0).

Have been able to repro using both 0.251.0 and prerelease v0.252.0 on a from scratch repo using nodejs-postgres devcontainer definition.

[7086 ms] Start: Run: docker-compose --project-name platform_devcontainer -f /workspaces/platform/.devcontainer/docker-compose.yml -f /tmp/docker-compose/docker-compose.devcontainer.containerFeatures-1663144450524.yml up -d --no-recreate
Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Starting platform_devcontainer_app_1 ... error

ERROR: for platform_devcontainer_app_1  Cannot start service app: error while creating mount source path '/host_mnt/workspaces/platform': mkdir /host_mnt/workspaces: input/output error

ERROR: for app  Cannot start service app: error while creating mount source path '/host_mnt/workspaces/platform': mkdir /host_mnt/workspaces: input/output error
ERROR: Encountered errors while bringing up the project.
[7938 ms] Error: Command failed: docker-compose --project-name platform_devcontainer -f /workspaces/platform/.devcontainer/docker-compose.yml -f /tmp/docker-compose/docker-compose.devcontainer.containerFeatures-1663144450524.yml up -d --no-recreate
[7939 ms]     at pF (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:222:2970)
[7939 ms]     at processTicksAndRejections (internal/process/task_queues.js:95:5)
[7939 ms]     at async dF (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:206:2361)
[7939 ms]     at async DF (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:263:2177)
[7939 ms]     at async to (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:263:3110)
[7939 ms]     at async Ak (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:383:8108)
[7939 ms]     at async Ok (/root/.vscode-remote-containers/dist/dev-containers-cli-0.251.0/dist/spec-node/devContainersSpecCLI.js:383:7864)
[7959 ms] Exit code 1

I also tried with Docker Desktop For Linux (Ubuntu) with exactly the same symptom. The only diff is there is no way to put a fake path (it prevent Docker Desktop to actually start) so I have tried with / in File Sharing settings.

For now the only workaround that works for me was to remove these lines from docker-compose.yml def (since we are always cloning in a container volume and not using Open Folder in Container) :

volumes:
  - ..:/workspace:cached

But I think the root cause should be address.

I also am running into this since upgrading to 4.12. With 4.11 I was able to remove the volumes from the docker-compose.yml but with 4.12 that does not work.

ERROR: for platform_devcontainer_myapp_1 Cannot start service myapp: error while creating mount source path '/host_mnt/workspaces/platform': mkdir /host_mnt/workspaces: input/output error

daniellaera commented 2 years ago

same error on macOS with node-postgres. any update?

chrmarti commented 2 years ago

A more robust workaround is to change the bind mount in the docker-compose.yml to:

    volumes:
      - ../..:/workspaces:cached

and the workspace folder in the devcontainer.json to:

    "workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}",

This way the extension overwrites the mount point at /workspaces. The extension always mounts the volume at /workspaces because it initially (when it needs to know) doesn't know the contents of the devcontainer.json and the docker-compose.yml yet.

daniellaera commented 2 years ago

thank you @chrmarti! works well on MacOS

Chuxel commented 2 years ago

@bamurtaugh @samruddhikhandale @joshspicer We may want to update our Docker Compose templates to mirror this since I think it's also the Codespaces default behavior, so we'd be more consistent too.

arianitu commented 1 year ago

@chrmarti do you happen to have a workaround for when you pick a different workspaceFolder?

In our case, we have this config:

"workspaceFolder": "/var/www/html",

But I cannot get Clone in Volume to work with this setup and the only examples I see are for /workspaces example. The only thing I can think of is to symlink /workspaces to /var/www/html but it's a bit odd since it works fine with mounted git files, it only fails with Clone in Container Volume.

Does workspaceFolder not work for Clone in Container volume?

arianitu commented 1 year ago

I was able to get it work by doing this (not the cleanest method, honestly would prefer if workspaceFolder worked):

    "postAttachCommand": "rm -r /var/www/html && ln -s /workspaces/${localWorkspaceFolderBasename} /var/www/html"

Unfortunately I could not find a way to use workspaceFolder directly for both Mounted and In Volume methods. The In Volume method would always fail if I specified /var/www/html as the workspaceFolder. I do think that's a bug tho?

Dzivo commented 1 year ago

A more robust workaround is to change the bind mount in the docker-compose.yml to:

    volumes:
      - ../..:/workspaces:cached

and the workspace folder in the devcontainer.json to:

  "workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}",

This way the extension overwrites the mount point at /workspaces. The extension always mounts the volume at /workspaces because it initially (when it needs to know) doesn't know the contents of the devcontainer.json and the docker-compose.yml yet.

This was a workaround but this can not be the end solution :) thx for your hard work

alexandrosraikos commented 10 months ago

Any updates on this?

tamazon commented 3 months ago

I tried OrbStack instead of Docker Desktop on macos and it solved the issue for some reason. I guess this is a bug in Docker Desktop.