Docker mount volume thêm; C vào cuối đường dẫn windows khi dịch từ đường dẫn kiểu linux


88

Tôi đã tìm thấy một số điều kỳ lạ thú vị khi cố gắng gắn một hình ảnh docker trên cửa sổ.

Tôi đã tạo một .shtập lệnh gắn thư mục dự án để chạy hình ảnh môi trường dành cho nhà phát triển của chúng tôi. Tôi muốn một tập lệnh mà mọi nhà phát triển đều có thể chạy, bất kể máy của họ là gì. Tất cả những gì nó làm là chạy docker với thư mục dự án hiện tại.

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

Chạy ổn. Bây giờ kế hoạch là gọi tập lệnh này từ npm, vì vậy tôi muốn nó hoạt động liên quan đến thư mục hiện tại. Hãy thử phiên bản khác.

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

Không thành công với:

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. Nó là gì ;Cvà nó đến từ đâu?

Vì vậy, tôi làm điều echo $PWDđó mang lại cho tôi /d/my/project/folder.

Thật thú vị, vì vậy $PWDgiải quyết đến đường dẫn chính xác ở định dạng đường dẫn linux và có vẻ như docker đang cố gắng dịch từ đường dẫn đó sang đường dẫn cửa sổ chính xác, ngoại trừ có điều này ;Cxuất hiện từ hư không. Và \/...

Chính xác thì chuyện gì đang xảy ra ở đây vậy?

Tôi nhận được kết quả tương tự trong git bash và powershell của VSCode.

Cập nhật: Tôi nhận thấy rằng chạy .shtrong thiết bị đầu cuối powershell của VSCode, sẽ mở ra một cmd.execửa sổ bảng điều khiển riêng biệt có vẻ như chạy tập lệnh trong git bash. Vì vậy, đây có thể là một vấn đề git bash.

Câu trả lời:


125

Vì vậy, với một số đào bổ sung, tôi đã tìm thấy ba chủ đề này, liên quan đến 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

Khi tôi tra cứu tài liệu của mingw về chuyển đổi đường dẫn mà git-bash đang sử dụng, tôi tìm thấy bảng cú pháp sau: http://www.mingw.org/wiki/Posix_path_conversion

Một trong số đó kết quả đầu ra trong định dạng: x;x;C:\MinGW\msys\1.0\x. Lưu ý ;Ctrong đó. Nếu git-bash đang cố gắng thông minh, nhồi nhét cú pháp và xuất ra một đường dẫn với định dạng này, thì điều này sẽ giải thích điều đó.

Giải pháp là thoát khỏi chuyển đổi đường dẫn bằng cách sử dụng tiền tố với /. Vì vậy, lệnh docker đang hoạt động để chạy docker từ git-bash với thư mục làm việc hiện tại:

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

9
Tôi thấy rằng tôi phải quấn thêm đường dẫn vào một chuỗi để"/${PWD}"
Bananaapple

11
$ docker run -p 8080:3000 -v /$(pwd):/var/www -w //var/www node npm start Cuối cùng tôi thấy rằng tôi phải sử dụng dấu gạch chéo đứng đầu với dấu ngoặc đơn thay vì dấu ngoặc nhọn. Ngoài ra, với thư mục làm việc, tôi cần hai dấu gạch chéo ở đầu. FYI: đây là lệnh tôi cần cho Docker cho nhà phát triển web trên Pluralsight
Andy2K11

Điều này phù hợp với tôi (trên Windows 10 git bash): docker run --name my-wordpress -v "/ $ {PWD} / wordpress": / wordpress_sources -p 80:80 -dk <image_name>
progonkpa

1
Cứu sinh. Windows10 và git-bash ở đây, tôi đã mất nhiều thời gian để thử gắn khối lượng mà không sử dụng docker-comp, cho đến khi tôi thấy bài đăng này. Bây giờ công trình này: docker run --rm -v /${PWD}/migrations:/flyway/sql --network xxx_default flyway. Cảm ơn bạn.
Emily

ĐỜI SỐNG. TIẾT KIỆM. +1000000
Jonathan Tuzman

3

Đối với tôi, giải pháp chỉ đơn giản là bao gồm một dấu gạch chéo /ở cuối bất kỳ đường dẫn nào .

Vd thay vì

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

...sử dụng

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


3

Việc gắn thư mục hiện tại vào vùng chứa Docker trong Windows 10 từ Git Bash (MinGW) có thể không thành công do chuyển đổi đường dẫn POSIX. Bất kỳ đường dẫn nào bắt đầu bằng /đều được chuyển đổi thành đường dẫn Windows hợp lệ.

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

Thoát khỏi các đường dẫn POSIX bằng cách bắt đầu bằng /

Để bỏ qua chuyển đổi đường dẫn, tất cả các đường dẫn POSIX phải được bắt đầu bằng dấu gạch chéo ở đầu ( /), bao gồm /$(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

Trong Git Bash, đường dẫn //data/test.txtkhông được chuyển đổi và trong Linux shell //(dấu gạch chéo kép ở đầu) bị bỏ qua và được xử lý theo cùng một cách /.

Tắt chuyển đổi đường dẫn

Tắt chuyển đổi đường dẫn POSIX trong Git Bash (MinGW) bằng cách sử dụng MSYS_NO_PATHCONVbiến môi trường.

Chuyển đổi đường dẫn có thể bị vô hiệu hóa ở cấp lệnh:

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

Chuyển đổi đường dẫn có thể bị vô hiệu hóa ở cấp shell (hoặc hệ thống):

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
Cảm ơn bạn đã cung cấp giải pháp này vì tính năng thoát không hoạt động với tôi, trong khi tắt chuyển đổi đường dẫn đã làm được.
Chanandler Bong

0

Bạn có thể thử lệnh dưới đây -

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

0

Tôi thực sự đã có cùng một vấn đề. Tùy thuộc vào việc bạn có đang sử dụng Git Bash mà lệnh này hoạt động hay không (sử dụng nginx làm ví dụ):

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

tất nhiên bạn có thể chỉ định cổng và thư mục như bạn muốn.


0

Tôi đã gặp vấn đề tương tự trên git bash và không phải dấu nhắc lệnh. Bạn có thể thay thế

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

0

Thẳng làm việc cho tôi bên dưới. chỉ cần không sử dụng biến động.

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
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.