I am using visual studio 2019 to build .NET CORE web api.
When i build the application with docker via VS2019, i am getting the error:
"Docker command failed with exit code 125".
Any idea what is the cause?
This is the Output:
1>d2c0ee48dbf44507b3dee44a17ab8b8186fe4ec59c283af834191e8f3c902f1a
1>C:\Users\97254\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.9.5\build\Container.targets(196,5): error CTC1015: Docker command failed with exit code 125.
1>C:\Users\97254\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.9.5\build\Container.targets(196,5): error CTC1015: docker: Error response from daemon: hcsshim::CreateComputeSystem d2c0ee48dbf44507b3dee44a17ab8b8186fe4ec59c283af834191e8f3c902f1a: The request is not supported.
1>C:\Users\97254\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.9.5\build\Container.targets(196,5): error CTC1015: (extra info: {"SystemType":"Container","Name":"d2c0ee48dbf44507b3dee44a17ab8b8186fe4ec59c283af834191e8f3c902f1a","Owner":"docker","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\Docker\\windowsfilter\\d2c0ee48dbf44507b3dee44a17ab8b8186fe4ec59c283af834191e8f3c902f1a","Layers":[{"ID":"51d2ce01-5190-5398-8d36-73a41302a60e","Path":"C:\\ProgramData\\Docker\\windowsfilter\\47c9023ce74aa96d2e5002cdf0f7e354f5de55b217e08498dda14e1be5d6998f"},{"ID":"c6ab7d12-aab5-5873-9f2e-0ec11613a58d","Path":"C:\\ProgramData\\Docker\\windowsfilter\\035fac58f721cc9c158ef24fdb84a7e74eb4eea2cf29421a3744241cc62eabe7"},{"ID":"cdf32ccb-53d2-56ad-8b1d-9dfa6ae076d7","Path":"C:\\ProgramData\\Docker\\windowsfilter\\7ac67c0c7c4a6dfc2c0becbc948078b48873f003c49f16c1d0be0d69b179d3b3"},{"ID":"4c8a0736-dba8-5fde-8cc0-56aa33e0149d","Path":"C:\\ProgramData\\Docker\\windowsfilter\\43ad281ee856dabf07411276e5774b386bd37aee8b3099c3b7faa1d314a7013e"},{"ID":"af791769-1fd1-5170-b6e4-2245156a8f6f","Path":"C:\\ProgramData\\Docker\\windowsfilter\\878625f6c364e37ff07532212a6979f096de46d9eb455c964366ecd5a9c03ba9"},{"ID":"082795f2-b562-5088-a34f-91d16d7e5c36","Path":"C:\\ProgramData\\Docker\\windowsfilter\\4dbda25002ed56956709c11b4cc902083e712fc8a862b2b62970e839ec2bffec"},{"ID":"e409f795-d9cf-539a-ac95-dbedc3506ccb","Path":"C:\\ProgramData\\Docker\\windowsfilter\\7e2f83b59544b3cf2e553cdd9d94dd27a4684360c23f44d93a2b39e5dd0301cb"},{"ID":"a5fdd7a2-0ea0-553a-9c1e-976a729321e3","Path":"C:\\ProgramData\\Docker\\windowsfilter\\27f0f73d07810d0877a35fc1215e5336e6034eba1c08974f2f308796c9a32890"},{"ID":"b0175521-e8e7-55e8-97a8-77d96d2bb78a","Path":"C:\\ProgramData\\Docker\\windowsfilter\\03bb0041548802485ca5cc3a0475fde8905f048e50eb6b43413b1796b34773ad"},{"ID":"85e06fce-32e5-5cb6-8678-a4750186c146","Path":"C:\\ProgramData\\Docker\\windowsfilter\\8f5d06ad16da8edecc28898e8cda1ce15e4087e16e1b9a5d2d7a4d10a2c55398"}],"HostName":"d2c0ee48dbf4","MappedDirectories":[{"HostPath":"c:\\users\\97254\\onecoremsvsmon\\16.3.0039.0","ContainerPath":"c:\\remote_debugger","ReadOnly":true,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false},{"HostPath":"c:\\cheggtest\\qfetcherapi","ContainerPath":"c:\\app","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false},{"HostPath":"c:\\cheggtest","ContainerPath":"c:\\src","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false},{"HostPath":"c:\\users\\97254\\.nuget\\packages","ContainerPath":"c:\\.nuget\\fallbackpackages2","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false},{"HostPath":"c:\\program files\\dotnet\\sdk\\nugetfallbackfolder","ContainerPath":"c:\\.nuget\\fallbackpackages","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false}],"HvPartition":true,"EndpointList":["766EA888-2541-4D88-B330-EBD3ECA2FF64"],"HvRuntime":{"ImagePath":"C:\\ProgramData\\Docker\\windowsfilter\\8f5d06ad16da8edecc28898e8cda1ce15e4087e16e1b9a5d2d7a4d10a2c55398\\UtilityVM"},"AllowUnqualifiedDNSQuery":true}).
I got this same error when using Windows containers. However, I switched to Linux containers, and it told me I had to enable volume sharing. Once that was enabled the sample instructions worked perfectly.
One reason I suspect that Windows containers are not working right now is that in build 1809 of nanoserver the USERNAME was switched from ContainerAdministrator to ContainerUser which has no permissions to write to the root of C: in the docker.
I now have a workaround to enable you to solve the issue you are having while trying to run this sample app using Windows containers.
As Visual Studio 2019 creates your docker file for you when you add docker support (windows), the dockerfile starts off at the top looking like this:
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
Change this to the following:
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 AS base
USER ContainerAdministrator
RUN net localgroup administrators /add "User Manager\ContainerUser"
USER ContainerUser
WORKDIR /app
EXPOSE 80
EXPOSE 443
Note that the 3 lines that I added essentially elevate ContainerUser to admin.
Open a powershell command prompt and do this:
docker rmi projname:dev
where projname is the name of your project. This will cause Visual Studio to rebuild from your edited dockerfile.
Under pages shared _Layout.cshtml you can set a breakpoint on the line for #RenderBody(). Set that breakpoint, and press F5 to run with debugging.
You should see the docker rebuild and run successfully, open your browser, and break on that line. Press F5 again to allow the page to render in the browser.
Let me know if this works for you.
For me, that exception came along with the following message:
Error response from daemon: user declined directory sharing C:\Repos\...\src\WorkforceManagementAPI.WEB.
I downloaded the latest version of Docker Desktop, which has an explicit list of File Sharing paths (Settings/Resources/File Sharing/add the path: C:\Repos...\src\WorkforceManagementAPI.WEB)
That resolved the issue.
I've encountered this problem after I added the <DockerfileRunArguments> tag to .csproj file. I had it like this:
<DockerfileRunArguments>
-v "c:/host_path:/container_path"
</DockerfileRunArguments>
It was 3 lines and this resulted in Visual Studio 2022 (v17.4) running 'docker run' command with new lines, splitting it. When I moved it to a single line:
<DockerfileRunArguments>-v "c:/host_path:/container_path"</DockerfileRunArguments>
It started working again :)
After some more "tests" it came out that this tags inner content can't start with a new line, so this is still ok:
<DockerfileRunArguments>-v "c:/host_path:/container_path"
-v "c:/other_host_path:/other_container_path"
</DockerfileRunArguments>
I am using CircleCI's persistent workspace feature to run jobs with the same build folder between Linux and Windows executor types. I was able to go from Linux to Windows but when I went from Windows to Linux I got this error when CircleCI attempted to attach the workspace.
Applying workspace layers:
9ba3eddc-3658-43c2-858b-aea39250af3e
25c476af-8804-4125-b979-05a62a9ac204
Error applying workspace layer for job 25c476af-8804-4125-b979-05a62a9ac204: Error extracting tarball /tmp/workspace-layer-25c476af-8804-4125-b979-05a62a9ac204854634413 : tar: project/.circleci/config.yml: Cannot change ownership to uid 3434, gid 197121: Invalid argument
Looking at the error it's clear that the UIDs are not existing on the system. I attempted to run commands to create the same UID/GID it was erroring on but I still got an unable to change owner issue.
I was expecting CircleCI to move the files and ignore the user: group part when it was extracted as you can't guarantee the UID/GID exists.
I opened a support ticket but hoping for a faster solution to this issue.
I found a solution to this issue and it's forcing CircleCI to use TAR_OPTIONS environment variable to force the options to ignore the owner/group.
Here is what I added to my jobs steps that attach the workspace when the previous job run was Window.
build-app:
build:
docker:
- image: Dockerhub.com/myrepo/myimage:1.0.0
environment:
TAR_OPTIONS: --no-same-owner
using TAR_OPTIONS environment to inject the option --no-same-owner allowed CircleCI to extract the tarball without issue.
I have been trying http://predictionio.apache.org/install/install-docker/ this tutorial. I have successfully built Docker image however when I try to run docker run i get the Can't open /etc/predictionio/pio-env.sh error.
docker build -t predictionio/pio pio
docker run -ti predictionio/pio
PS: If I comment out the last line CMD ["sh", "/usr/bin/pio_run"] I can build and run docker image successfully. I can open the file too from docker bash.
I think you need to grant permissions to execute this file. add the following line at the end of your Dockerfile
RUN chmod +x pio_run.sh
also, you might need to change CMD to ENTRYPOINT like following:
ENTRYPOINT ["sh","/usr/bin/pio_run.sh"]
Your output states you are running Windows. Did you use the default command prompt or did you use docker terminal? I had the same error messages in the past on Windows but mysteriously it disappeared after trying the tutorial again. I am not sure what I did different except I might possibly used docker instead of the default command prompt...
Could you also try using docker-compose instead of plain docker commands as described in the tutorial?
Ensure your storage (Postgres, MySQL or ElasticSearch) is running before starting PIO as well.
Just resolved it on my machine.
When you cloned repository on Windows, git converted end of line symbols from Unix-style (\n) to Windows style (\r\n).
You need to open file C:\wherever-you-cloned-pio-repository\predictionio\docker\pio\pio_run and change it back (for e.g. using Visual Studio Code, or Notepad++). Then you need to rebuild the image and it should work.
Also for the future you may want to disable automatic conversion Disable git EOL Conversions
I'm having an issue with docker-compose where I'm passing a file into the container when it's run. The issue is that it doesn't seem to recognize when the file has been changed and serves the saved result back indefinitely until I change the name of the file.
An example (modified names for brevity):
jono#macbook:~/myProj% docker-compose run vpn conf.opvn
Options error: Unrecognized option or missing parameter(s) in conf.opvn:71: AXswRE+
5aN64mYiPSatOACC6+bISv8RcDPX/lMYdLwe8zQY6qWtbrjFXrp2 (2.3.8)
Then I change the file, save it, and run the command again - exact same output.
Then without changing anything I do this:
jono#macbook:~/myProj% cp conf.opvn newconf.opvn
And when I run $ docker-compose run vpn newconf.opvn it works. Seems really silly.
I'm working with Tmux and Mac if there is some way that affects it. Is this the expected behaviour? I couldn't find anything documenting this on the docker-compose homepage.
EDIT:
Specifically I'm using this repo from the amazing Jess.
The image you are using is using volume in order to mount your current directory. Basically the file conf.opvn is copied to the docker container.
When you change the file, the container doesn't see that change, but it does pick up the rename (which the container sees as a new file). This most probably is due to user rights of the file and the user rights of the folder in the docker container where this file is mounted. Try changing the file's permissions to 777 before beginning the process and check again.
You can find a discussion about this in the official forum of docker
I want to work on a project, but I need to use docker for running the app, but the docker-compose up command fails with this error:
System error: exec: "./wait_to_start": stat ./wait_to_start:
no such file or directory
The wait_to_start command is an executable python script in the subfolder backend/.
I need to determine why it cannot be executed. Either it's been searched in the wrong path, or there are access right problems, or maybe the wrong python version is used.
Can I debug it with details, or login with SSH and check the files on the virtual machine? I'm too unexperienced with Docker...
You can either set the "workdir" metadata to make sure you are in the right place when you start a container or simply call /backend/wait_to_start instead of ./wait_to_start so you remove the need to be in the proper directory.
Do debug with docker-compose I would do this:
docker-compose run --entrypoint bash <servicename>
That should give you a prompt and let you inspect the file and working directory, so see what's wrong.