I am a complete noob to Docker, I apologize if this a simple question, I seem to have a significant installation/configuration error in Docker. I am working on a fresh install of Ubuntu 20.04 and Docker version 20.10.12, build e91ed57.
I am literally trying to follow the basic Docker tutorial for beginners from their website and the second command is not working.
The tutorial is no big deal, I can switch tutorials to something more up to date, but it seems that key functionality of Docker is not working correctly.. symlinks.
This command docker build -t getting-started . results in this error:
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/<user>/Downloads/WebDev/Docker/tutorial/getting-started-master/app/Dockerfile: no such file or directory
I double & triple checked everything. I literally tried every solution found here:
Docker: unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx
Docker build gives "unable to prepare context: context must be a directory: /Users/tempUser/git/docker/Dockerfile"
Nothing worked. I could only execute the command using an explicit path. rather than "." which is going to get annoying pretty quickly when developing real projects.
docker build -t getting-started ~/Downloads/WebDev/Docker/tutorial/getting-started-master/
All documentation states docker build -t getting-started . is the correct command, so I am worried about continuing with a "broken" docker installation.
I ran the docker ./check-config.sh script and it shows all is well except CONFIG_RT_GROUP_SCHED: missing which I thought was inconsequential for the moment since hello-world image worked as expected.
Hhhmmm?
What directory are you in when running these commands? From your error it seems you are in the /app directory, whilst you should probably be 1 directory up.
Or, alternatively, your dockerfile is 1 directory below where it was intended to be. I draw this conclusion by comparing the 2 paths you mention:
~/Downloads/WebDev/Docker/tutorial/getting-started-master/app/Dockerfile
vs
~/Downloads/WebDev/Docker/tutorial/getting-started-master/
If the second one works, then the dockerfile is under getting-started-master and not under /app.
Fyi: Docker has a context and unless you explicitly specify it to be something different, by default it's going to be the directory the Dockerfile is located in.
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'm trying to move my few microservices to a docker containers using docker-compose project type from Visual Studio.
I also have Service Fabric project so I have to install Service Fabric SDK into my docker containers.
That's what I do to achieve this (my dockerfile(s)):
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2-nanoserver-1809 AS base
WORKDIR /app
EXPOSE 80
...
WORKDIR /temp
ADD https://aka.ms/vs/15/release/vs_buildtools.exe /temp #C:\TEMP\vs_buildtools.exe
...
The rest code doesn't matter since it crashes on line with ADD command.
The error from Output after I run this via Ctrl+F5:
3>Step 4/11 : ADD https://aka.ms/vs/15/release/vs_buildtools.exe /temp
3>Service 'bmt.microservices.snowforecastcenter' failed to build: ADD failed: CreateFile \\?\C:\ProgramData\Docker\tmp\docker-builder567273413\temp: The system cannot find the file specified.
I don't understand what I'm doing wrong and what does it mean 'system cannot find the file' since I simply load the file from the internet and place it into my newly created \temp folder (the link is valid, I checked).
Does anybody know what this might be related to?
Ok, I've accidentally fixed the problem by moving comment to next line.
From this:
ADD https://aka.ms/vs/15/release/vs_buildtools.exe /temp #C:\TEMP\vs_buildtools.exe
To this:
ADD https://aka.ms/vs/15/release/vs_buildtools.exe /temp
#C:\TEMP\vs_buildtools.exe
Then I red on official site (https://docs.docker.com/engine/reference/builder/#/from) that you cannot have inline comments since they are treated as arguments:
Docker treats lines that begin with # as a comment, unless the line is a valid parser directive. A # marker anywhere else in a line is treated as an argument.
I hope this will help other people who are new in Docker.
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 trying to configure running simple .NET Core Web API application inside Docker container. My dockerfile contains following ENTRYPOINT line:
ENTRYPOINT ["dotnet", "Project.name.dll"]
Dockerfile builds image proper. When I run it however I have following exception:
No executable found matching command "dotnet-Project.name.dll"
I don't understand why parameter is transformed in that way (added hyphen). I use microsoft/dotnet:2.0.0-sdk-stretch container. Official documentation recommends following ENTRYPOINT config
ENTRYPOINT ["dotnet", "dotnetapp.dll"]
Which is the same as I use...
It's a bizarre error message, but it really is saying that the dll can not be found. You can see other examples of this "issue" here: https://github.com/dotnet/core-setup/issues/1126#issuecomment-327441394
When you run dotnet foo.dll, the dotnet application tries to find foo.dll and execute it. If the dll is not found, dotnet thinks that maybe you are trying to run a dotnet command (along the lines of dotnet foo, similar to dotnet build). This makes dotnet look for an executible named dotnet-foo.dll and try and execute that. Since that file also doesn't exist, dotnet finally errors out that dotnet-foo.dll can not be found.
In your case, it looks like dotnet couldn't find Project.name.dll. Does the dll really exist? Does it exist in the current directory? Perhaps you need to provide the full path to it?
Oh, and if you are running this on Azure, there are some known gotchas, such as putting your dlls under /home/ will just not work.