O volume montado no Docker adiciona; C ao final do caminho do Windows ao traduzir do caminho do estilo Linux


88

Eu encontrei algumas estranhezas interessantes ao tentar montar uma imagem docker no Windows.

Eu criei um .shscript que faz uma montagem da pasta do projeto para rodar nossa imagem de ambiente de desenvolvedor. Quero um script que todo desenvolvedor possa executar, independentemente de sua máquina. Tudo o que ele faz é executar o docker com a pasta do projeto atual.

#!/usr/bin/env bash
docker run -it --rm -v D:\my\project\folder:/wkDir $IMAGE_TAG yarn dev

Funciona bem. Agora, o plano é chamar esse script de npm, então gostaria que funcionasse em relação à pasta atual. Vamos tentar outra versão.

docker run -it --rm -v $PWD:/wkDir $IMAGE_TAG yarn dev

Falha com:

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from 
daemon: Mount denied:
The source path "D:/my/project/folder;C"
doesn't exist and is not known to Docker.

Wat. O que é ;Ce de onde veio?

Então eu faço o echo $PWDque me dá /d/my/project/folder.

Interessante, então $PWDresolve para o caminho correto no formato de caminho do Linux, e parece que o docker está tentando traduzir desse para o caminho correto do Windows, exceto que há isso ;Cque aparece do nada. E o \são /...

O que exatamente está acontecendo aqui?

Eu obtenho o mesmo resultado no terminal git bash e powershell do VSCode.

Atualização: notei que rodar o .shterminal do VSCode no PowerShell abre uma cmd.exejanela de console separada que parece rodar o script no git bash. Portanto, este pode ser um problema do git bash.

Respostas:


125

Então, com um pouco de escavação extra, encontrei estes três tópicos, relacionados ao git-bash mucking up docker mount:

https://forums.docker.com/t/weird-error-under-git-bash-msys-solved/9210 https://github.com/moby/moby/issues/24029#issuecomment-250412919

Quando procuro a documentação do mingw sobre a conversão de caminho que git-bash está usando, encontro esta tabela de sintaxe: http://www.mingw.org/wiki/Posix_path_conversion

Uma das quais saídas no formato: x;x;C:\MinGW\msys\1.0\x. Observe o ;Cnele. Se git-bash está tentando ser inteligente, enchendo a sintaxe e produzindo um caminho com este formato, isso explicaria.

A solução é escapar da conversão de caminho, usando prefixando com /. Portanto, o comando docker de trabalho para executar docker a partir de git-bash com o diretório de trabalho atual:

docker run -it --rm -v /${PWD}:/wkDir $IMAGE_TAG yarn dev

9
Descobri que precisava também envolver o caminho em uma string, então"/${PWD}"
Bananaapple

11
$ docker run -p 8080:3000 -v /$(pwd):/var/www -w //var/www node npm start Acabei descobrindo que precisava usar a barra inicial com parênteses em vez de colchetes. Além disso, com o diretório de trabalho, eu precisava de duas barras iniciais. Para sua informação: este é o comando que eu precisava para o Docker para desenvolvedores da Web no
Pluralsight

Isso funcionou para mim (no Windows 10 git bash): docker run --name my-wordpress -v "/ $ {PWD} / wordpress": / wordpress_sources -p 80:80 -dk <image_name>
progonkpa

1
Poupança de vida. O Windows10 e o git-bash aqui levaram muito tempo para tentar aumentar o volume sem usar docker-compose, até ver este post. Agora isso funciona: docker run --rm -v /${PWD}/migrations:/flyway/sql --network xxx_default flyway. Obrigado.
Emily

VIDA. SAVER. +1000000
Jonathan Tuzman

3

Para mim, a solução foi simplesmente incluir uma barra de fechamento /no final de todos os caminhos .

Por exemplo, em vez de

/opt/apache-atlas-2.0.0/bin/atlas_start.py

...usar

/opt/apache-atlas-2.0.0/bin/atlas_start.py/


3

A montagem do diretório atual em um contêiner do Docker no Windows 10 a partir do Git Bash (MinGW) pode falhar devido a uma conversão de caminho POSIX. Qualquer caminho que comece com /é convertido em um caminho válido do Windows.

touch test.txt
docker run --rm -v $(pwd):/data busybox ls -la /data/test.txt
# ls: C:/Git/data/test.txt: No such file or directory

Escape dos caminhos POSIX prefixando com /

Para pular a conversão de caminho, todos os caminhos POSIX devem ser prefixados com uma barra extra ( /), incluindo /$(pwd).

touch test.txt
docker run --rm -v /$(pwd):/data busybox ls -la //data/test.txt
# -rwxr-xr-x    1 root     root             0 Jun 22 23:45 //data/test.txt

No Git Bash, o caminho //data/test.txtnão é convertido e nos shells do Linux //(barra dupla inicial) é ignorado e tratado da mesma maneira que /.

Desative a conversão de caminho

Desative a conversão de caminho POSIX no Git Bash (MinGW) usando MSYS_NO_PATHCONVa variável de ambiente.

A conversão de caminho pode ser desativada no nível de comando:

touch test.txt
MSYS_NO_PATHCONV=1 docker run --rm -v $(pwd):/data busybox ls -la /data/test.txt
# -rwxr-xr-x    1 root     root             0 Jun 22 23:45 /data/test.txt

A conversão de caminho pode ser desativada no nível do shell (ou sistema):

export MSYS_NO_PATHCONV=1
touch test.txt
docker run --rm -v $(pwd):/data busybox ls -la /data/test.txt
# -rwxr-xr-x    1 root     root             0 Jun 22 23:45 /data/test.txt

2
Obrigado por fornecer esta solução, pois o escape não funcionou para mim, enquanto a desativação da conversão de caminho sim.
Chanandler Bong

0

Você pode tentar o comando abaixo -

docker run -it --rm -v %cd%:/wkDir $IMAGE_TAG yarn dev

0

Na verdade, eu tive o mesmo problema. Dependendo se você está usando Git Bash, esse comando funciona (usando nginx como exemplo):

docker container run --name container-name -v `pwd -W` / html: / usr / share / nginx / html -p 8000: 80 -d nginx

é claro que você pode especificar a porta e o diretório que desejar.


0

Eu tive o mesmo problema no git bash e não no prompt de comando. Você pode ao invés

docker run -it --rm -v "/${PWD}/D:\my\project\folder":/wkDir $IMAGE_TAG yarn dev

0

Straight trabalhou para mim abaixo. apenas não use variável dinâmica.

docker run --rm -u root -p 8080:8080 -v jenkins-data/:/var/jenkins_home -v /var/run/docker.sock/:/var/run/docker.sock -v /Users/<YOUR USER NAME>/:/home jenkinsci/blueocean
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.