(I know Windows support is not on the table right now, but thought I would note this exception here for others)
When running the unit tests on Windows (after patching for #62) I came across this problem. Looks like this is a relevant related issue: https://github.com/docker/docker/issues/12751.
org.rnorth.ducttape.RetryCountExceededException: Retry limit hit with exception
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:83)
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:107)
at org.testcontainers.containers.GenericContainer.starting(GenericContainer.java:423)
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:28)
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:31)
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:31)
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:31)
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:31)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: org.testcontainers.containers.ContainerLaunchException: Could not create/start container
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:166)
at org.testcontainers.containers.GenericContainer.lambda$start$0(GenericContainer.java:110)
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76)
... 26 more
Caused by: com.github.dockerjava.api.InternalServerErrorException: Invalid bind mount spec "/C:/dev/testcontainers-java/core/target/test-classes/mappable-resource/test-resource.txt:/content.txt:ro": volumeinvalid: Invalid volume specification: '/C:/dev/testcontainers-java/core/target/test-classes/mappable-resource/test-resource.txt:/content.txt:ro'at com.github.dockerjava.jaxrs.filter.ResponseStatusExceptionFilter.filter(ResponseStatusExceptionFilter.java:53)
at org.glassfish.jersey.client.ClientFilteringStages$ResponseFilterStage.apply(ClientFilteringStages.java:134)
at org.glassfish.jersey.client.ClientFilteringStages$ResponseFilterStage.apply(ClientFilteringStages.java:123)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:171)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:251)
at org.glassfish.jersey.client.JerseyInvocation$2.call(JerseyInvocation.java:683)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:424)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:679)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:435)
at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:338)
at com.github.dockerjava.jaxrs.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:32)
at com.github.dockerjava.jaxrs.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:14)
at com.github.dockerjava.jaxrs.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:23)
at com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:33)
at com.github.dockerjava.core.command.CreateContainerCmdImpl.exec(CreateContainerCmdImpl.java:142)
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:132)
... 28 more
Thanks for raising this - good idea to get the Windows issues out in the open even while the support is sadly not there.
I've raised #85 to act as the main ticket for tracking Windows support.
No problem. If I get a chance I will help out with support.
On Tuesday, 1 March 2016, Richard North [email protected] wrote:
Thanks for raising this - good idea to get the Windows issues out in the
open even while the support is sadly not there.I've raised #85
https://github.com/testcontainers/testcontainers-java/issues/85 to act
as the main ticket for tracking Windows support.—
Reply to this email directly or view it on GitHub
https://github.com/testcontainers/testcontainers-java/issues/84#issuecomment-190756830
.
Luckily I came across this ticket and it seems I am not the only one having problems with Docker and Windows. I have already reported this error message "Invalid bind mount spec" in context of Windows 2016 TP4 and Docker as well as Windows Containers: http://superuser.com/questions/1051520/docker-windows-container-how-to-mount-a-host-folder-as-data-volume-on-windows
hey @v-schulz ,
How is Windows support going? I see some changes from you on it in your fork, will you send them back?
hi @bsideup ,
@rnorth and I are discussing the upcoming steps in the other thread about windows support. I think before I can merge the changes we need to resolve the CI issue. Atm there is no possibility to test the code on Windows. Another temporary possibility may be to ignore Windows-specific CI until it is possible.
@v-schulz we started to use TestContainers on Windows today and discovered that it's not working (at all), so your changes (with some minor fixes) looks good even without CI at this moment, at least they will not break Windows support because there is no such :D
@x97mdr @mathiasconradt just to let you know, we have Windows support as an alpha release now - please see docs here if you're interested: http://testcontainers.viewdocs.io/testcontainers-java/usage/windows_support/
Thanks Richard!
Will try it shortly
On Monday, 25 April 2016, Richard North [email protected] wrote:
@x97mdr https://github.com/x97mdr @mathiasconradt
https://github.com/mathiasconradt just to let you know, we have Windows
support as an alpha release now - please see docs here if you're
interested:
http://testcontainers.viewdocs.io/testcontainers-java/usage/windows_support/—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/testcontainers/testcontainers-java/issues/84#issuecomment-214153758
@bsideup Following up our discussion in pro.jvm I have the exact same issue as the topicstarter here.
So the error comes when testcontainers makes the startup checks and tries to mount C:\Users\user\AppData\Local\Temp\.testcontainers-tmp-6153256460751889885:/dummy:ro
Error from docker daemon is:
{"message":"invalid volume specification: 'C:\\Users\\user\\AppData\\Local\\Temp\\.testcontainers-tmp-6153256460751889885:/dummy:ro'"}
My setup is:
OS Windows 7 x64 7601.
docker-machine 0.7.0 with virtualbox driver.
docker client 17.09.0-ce
docker daemon 17.11.0-ce
testcontainers 1.6.0
However the exact version don't matter much here.
To work around this error testcontainers can check if there is a docker-machine environment and translate windows paths to boot2docker ones when mounting. This is possible because docker-machine mounts C:\Users to VM as /C/Users unless --virtualbox-no-share flag was specified while creating a machine.
So in this case path will be /C/Users/user/AppData/Local/Temp/.testcontainers-tmp-6153256460751889885.
In fact for now I don't actually need mounts now, so I just turned off the startup checks and everything else works like a charm, so it's not so critical for me. Moreover I hope soon I will move to windows 10 with normal docker-for-windows support.
@genuss thanks for a report! 💪
I wonder if you want to contribute this small change yourself (since you have an environment to test it)? 🤓
OK, will try to do that. Could you help me with where to look for this path generator in source code?
I've encountered the same issue as @genuss; however, disabling startup checks doesn't seem like a viable workaround. Am I missing something?
It seems like I still get the same error because the ryuk container attempts to mount the volume regardless of whether or not the checks are run:
https://github.com/testcontainers/testcontainers-java/blob/87e22ec774e4c6b3899166eb27f262c721e0895f/core/src/main/java/org/testcontainers/utility/ResourceReaper.java#L80-L81
@trevorpgray indeed that's true. For a workaround you can just downgrade to 1.5.1 version. There is no ryuk container there.
@trevorpgray Would you like to raise a seperate issue regarding Ryuk container in Docker-Toolbox (?) environments on Windows < 10? I'll try to setup a Windows 7 VM with Docker-Toolbox soon, to have at least a testing environment available.
Most helpful comment
@bsideup Following up our discussion in
pro.jvmI have the exact same issue as the topicstarter here.So the error comes when testcontainers makes the startup checks and tries to mount
C:\Users\user\AppData\Local\Temp\.testcontainers-tmp-6153256460751889885:/dummy:roError from docker daemon is:
My setup is:
OS Windows 7 x64 7601.
docker-machine 0.7.0 with virtualbox driver.
docker client 17.09.0-ce
docker daemon 17.11.0-ce
testcontainers 1.6.0
However the exact version don't matter much here.
To work around this error testcontainers can check if there is a docker-machine environment and translate windows paths to boot2docker ones when mounting. This is possible because docker-machine mounts
C:\Usersto VM as/C/Usersunless--virtualbox-no-shareflag was specified while creating a machine.So in this case path will be
/C/Users/user/AppData/Local/Temp/.testcontainers-tmp-6153256460751889885.In fact for now I don't actually need mounts now, so I just turned off the startup checks and everything else works like a charm, so it's not so critical for me. Moreover I hope soon I will move to windows 10 with normal docker-for-windows support.