DevLab in Windows "Invalid bind mount spec"

[aliig]

Running Windows 10 Pro, Docker 1.12.5, and DevLab 3.1.1.

I get an error when attempting to start containers with DevLab in Windows (from cmd, git bash, or powershell). I have shared the C: drive.

Here's the output error (personal info substituted with asterisks):

> lab install

√ Starting services rabbitmq, postgres
√ Running command: env
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
docker: Error response from daemon: Invalid bind mount spec "/C/Users/****/server:C:\\Users\\****\\server": invalid mode: \Users\****\server.
See 'docker run --help'.
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
× Command failed

Here's my config file:

from: busybox
services:
  - rabbitmq:
      from: gonkulatorlabs/rabbitmq
      expose:
        - 5672:5672
  - postgres:
        from: kiasaki/alpine-postgres
        env:
          - POSTGRES_USER=postgres
          - POSTGRES_PASSWORD=password
          - POSTGRES_DB=dev
        expose:
          - 5432:5432
expose:
  - 9000:9000
quiet: false
forward: true
tasks:
  env: env
  clean: npm run clean
  install: env
  test: npm run test
  lint: npm run lint
  build: npm run build
  start: npm start
  ci: |
    npm run lint 
    npm run test 
    npm run build

I can't tell for sure, but it seems like there is a problem with msys path conversion with docker, but I can't (or don't know how to) control what's passed to docker while using DevLab. I know there are some workarounds recommended with docker (a seemingly related issue) but I'm not sure how I'd implement these suggestions when DevLab is executing the Docker commands. I'm new to DevLab and Docker, so I apologize if I'm way off the mark here.

[ksafranski]

So the clear issue here is passing Windows pathing into a linux container. To maintain consistency Devlab mounts the volume of your working directory and paths it the same inside the container as it is on the host, so if you're working in C:\some\path it would mount that same path internally which isn't valid on *nix hosts.

My thought is that we could just path statically, i.e. we always have Devlab map to /app as the working directory in the container.

My hesitation here is that error messages that include the path would not be consistent, so if (for instance) a test or linter fails instead of echoing a path, file and line number like /path/to/project/file.js:43 it would echo out /app/file.js:43.

I'm not totally against this idea, and it's not a difficult change, however, I'd like to run it by some other people first.

If you want to fork and try it out on your system just change this line:

- let args = primary ? [ 'run', '--rm', '-it', '-v', `${cwd}:${cwd}`, '-w', cwd, '--privileged' ] : [ 'run', '-d', '--privileged' ]
+ let args = primary ? [ 'run', '--rm', '-it', '-v', `'${cwd}':/app`, '-w', '/app', '--privileged' ] : [ 'run', '-d', '--privileged' ]

then just run it from inside your project via node /path/to/devlab-fork/index <TASK>. That would at least give us an idea of if this corrects the issue for you.

[aliig]

Getting closer--here's the new output:

- docker: Error response from daemon: Invalid bind mount spec "/C/Users/****/server:C:\\Users\\****\\server": invalid mode: \Users\****\server.
+ docker: Error response from daemon: Invalid bind mount spec "'C:\\Users\\****\\server':/app": invalid mode: /app.

I can try fiddling with it a bit to see if I can get it to work right. As far as a more permanent solution goes, it does seem like inconsistencies in path/line-number output would be inconvenient--maybe a fix could be implemented specific to Windows paths (even something simple like a path parser and a conditional statement in the same place we're working).

[ksafranski]

Just from looking around at similar problems it appears msys is trying to convert those paths, maybe try:

let args = primary ? [ 'run', '--rm', '-it', '-v', `'${cwd}':'/app'`, '-w', '/app', '--privileged' ] : [ 'run', '-d', '--privileged' ]

[aliig]

- docker: Error response from daemon: Invalid bind mount spec "'C:\\Users\\****\\server':/app": invalid mode: /app.
+ docker: Error response from daemon: Invalid bind mount spec "'C:\\Users\\****\\server':'/app'": invalid mode: '/app'.

[ksafranski]

well that's not what I was expecting...

I'm going to try to nab a Windows system. For the time being, could you try to determine what the docker run command looks like that works to mount, i.e.:

docker run -it -v 'C:\\Users\whatever':'/app' -w '/app' busybox /bin/sh

[ksafranski]

Just found this: moby/moby#12751 (comment), maybe try changing it to:

let args = primary ? [ 'run', '--rm', '-it', '-v', `'${cwd}'`, '-w', `'${cwd}'`, '--privileged' ] : [ 'run', '-d', '--privileged' ]

[aliig]

Alright, after a bunch of trial-and-error, I was successful using this at the command line:

docker run -it -v C:/Users/****/server:/app -w "/app" busybox /bin/sh

Getting the "let args" line right in command.js has been a bit trickier, so I thought I'd report my progress in case you solve it before I do. Turns out the double quotes instead of single quotes on -w "/app" is important (also works without quotes).

EDIT: when I do console.log(args) after the let args line, this is the output of ${cwd}/app:
C:\\Users\\****\\server/app

EDIT2: and docker run -it -v C:\\Users\\****\\server:/app -w /app busybox /bin/sh happens to also work, so not sure why I can't get the let args line right.

EDIT3: Alright @Fluidbyte , this seems to work (comparing to original). Thanks for your help troubleshooting this

- let args = primary ? [ 'run', '--rm', '-it', '-v', `${cwd}:${cwd}`, '-w', cwd, '--privileged' ] : [ 'run', '-d', '--privileged' ]
+ let args = primary ? [ 'run', '--rm', '-it', '-v', `${cwd}:/app`, '-w', '/app', '--privileged' ] : [ 'run', '-d', '--privileged' ]

[ksafranski]

Interesting. Let me think about a possible approach to fix this.

[TomFrost]

We may be able to mark this as fixed, as of the addition of the workDir feature released back in 5.0.0. Specifying workDir: /app at the top level of your binci.yml should have the same effect as the change outlined above.

@mgleed, are you able to confirm that this takes care of the issue? I don't have a win environment to test, but I think we're safe to close this in absence of more info, as any additional windows-related issues are likely to be different.