Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker build exception: Invoke-WebRequest : The remote name could not be resolved #6453

Closed
2 tasks done
kkbruce opened this issue Apr 26, 2020 · 25 comments
Closed
2 tasks done

Comments

@kkbruce
Copy link

kkbruce commented Apr 26, 2020

  • I have tried with the latest version of my channel (Stable)
  • I have uploaded Diagnostics
  • Diagnostics ID: 99736AF1-D022-4508-AE58-2007E0B76A8F/20200426101030

Expected behavior

download file in docker build with Windows container.

Actual behavior

Can't download the file in docker build with Windows container.

Invoke-WebRequest : The remote name could not be resolved: 'nginx.org'
At line:1 char:76
+ ... yContinue'; Invoke-WebRequest -Uri http://nginx.org/download/nginx-1. ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt
   pWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe
   ll.Commands.InvokeWebRequestCommand

Information

  • Windows Version:
c:\>ver

Microsoft Windows [版本 10.0.18363.815]
  • Docker Desktop Version:
docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:23:10 2020
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.24)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:37:20 2020
  OS/Arch:          windows/amd64
  Experimental:     false
  • Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: No

Steps to reproduce the behavior

  1. Dockerfile
# escape=`

FROM mcr.microsoft.com/windows/servercore:1909
LABEL maintainer="kkbruce" version="1.18.0"

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

# .zip file URL from http://nginx.org/en/download.html
RUN Invoke-WebRequest -Uri http://nginx.org/download/nginx-1.18.0.zip -OutFile nginx.zip ; `
	Expand-Archive nginx.zip -DestinationPath $Env:ProgramFiles ; `
	Remove-Item -Force nginx.zip ; `
	Move-Item $Env:ProgramFiles\nginx-* $Env:ProgramFiles\nginx
  1. Run docker build -t kkbruce/nginx:1.18.0-servercore-1909 . and get Invoke-WebRequest : The remote name could not be resolved: 'nginx.org' exception.

I found a like issue pulla2908/docker-mssql-server-windows-developer-fti#2 , if I add --network "Default Switch" then docker build will success.

Now that the container wants to connect to the external network, do we need additional parameters?

Added: If after a while in Windows 10, it will return to an abnormal state.

@jeff994
Copy link

jeff994 commented Jun 29, 2020

Same issues here

@andyfisher100
Copy link

I also have a similar issue but when installing or using chocolatey package manager. It always seems to be when using powershell based commands.

If you take the following dockerfile as an example:

FROM mcr.microsoft.com/windows:1809
ADD https://aka.ms/vs/16/release/vs_enterprise.exe C:\\tools\\vs_enterprise19.exe
RUN powershell -NoProfile -ExecutionPolicy Bypass -Command "[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))"

The Visual Studio exe download will succeed but then the choco install script running from powershell will fail saying that the host cannot be resolved, like there is a dns/internet issue. However if there was an internet/dns issue, how did the VS exe download first?

@uaonline
Copy link

uaonline commented Sep 28, 2020

Similar issue being encountered with Docker Engine v19.03.11, on Windows Server 2016 host.

This isn't woking:
FROM mcr.microsoft.com/windows/servercore:ltsc2016
RUN Invoke-WebRequest -UseBasicParsing "http://nodejs.org/dist/v12.18.3/node-v12.18.3-win-x64.zip" -OutFile C:\nodejs.zip

Yet this works:
FROM mcr.microsoft.com/windows/servercore:ltsc2016
ADD http://nodejs.org/dist/v12.18.3/node-v12.18.3-win-x64.zip C:\nodejs.zip

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@RichardMM
Copy link

/remove-lifecycle stale

@RichardMM
Copy link

I am experiencing the same issue as well

@RichardMM
Copy link

@kkbruce hello,
Were you able to get the reason for this or a fix because the ADD function does not work in all scenarios

@kkbruce
Copy link
Author

kkbruce commented Jan 6, 2021

@RichardMM
In the new version of Docker Desktop, I did not repeat this problem again. Otherwise, you can try the --network "Default Switch" parameter.

@shanz1999
Copy link

Same problem here following https://www.aeons.dev/2020/02/19/win2016-with-vsbuild-docker/

doggy8088 added a commit to doggy8088/mssql-docker that referenced this issue Apr 12, 2021
Fix DNS issue in Windows Container by adding the following --network switch:
--network "Default Switch"

docker/for-win#6453 (comment)

docker build --network "Default Switch" -t willh/mssql-server-windows-developer:20H2 .
@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@darkvertex
Copy link

/remove-lifecycle stale

@phmonte
Copy link

phmonte commented Apr 15, 2021

Same problem in docker build and docker run, works only with --network "Default Switch" parameter.

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@Cpt-Falcon
Copy link

/remove-lifecycle stale

@Cpt-Falcon
Copy link

This problem still exists and is quite problematic

@hatasaki
Copy link

Hi all,
I faced same issue then I solved it based on the info written in this post.
I hope it can help you.

This often happens when there are multiple networking adapters (Ethernet, Wi-Fi, etc.) present on the host. The priority of these adapters needs to be configured properly in order for the Windows networking stack to correctly choose gateway routes. You can fix this by setting your primary internet-connected networking adapter to have the lowest InterfaceMetric value. Try these Powershell commands from an elevated console:

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric -Descending

Again, you want your host's primary internet-connected network adapter to have the lowest InterfaceMetric value.

Use this command to make the change (example assumes primary adapter InterfaceAlias is 'Wi-Fi'):

Set-NetIPInterface -InterfaceAlias 'Wi-Fi' -InterfaceMetric 3

That should do it. If your host's primary network adapter is bridged because you have an External virtual switch setup in Hyper-V, then you will set the external virtual switch to have the lowest InterfaceMetric value.

You can verify your routing tables by using this command (the last line should show the primary adapter's gateway address along with it's ifMetric value):

Get-NetRoute -AddressFamily IPv4

I hope this helps!

@klawingco
Copy link

klawingco commented Oct 1, 2021

I wasted 2 hours of time trying to fix this. What I've done is removing my wifi dongle (I am connected to ethernet via wired LAN). I believe if it's built-in. Disabling it will suffice.
Othersie If you are working on a laptop with multiple network adapters @hatasaki comment might help.

@DatKyle
Copy link

DatKyle commented Oct 4, 2021

@hatasaki's comment helped fix this for me. One thing to note is I had 2 interfaces (Network 8 and 9) with metrics 1, when I updated the required interface (network 3) to metrics 1, it still didn't work. I had to update the Network 8 and 9 metrics to be 2 to get docker to use the correct interface.

@Cpt-Falcon
Copy link

Cpt-Falcon commented Oct 29, 2021

All, WSL 1 was working fine but WSL2 does not work at all. Something is clearly wrong. However, I was able to get around everything and work locally OR on a VPN with the following extremely helpful github repo:

https://github.com/sakai135/wsl-vpnkit

Install the following and your problems should be solved.

@selek55
Copy link

selek55 commented Dec 14, 2021

/remove-lifecycle stale

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@mulder999
Copy link

/remove-lifecycle stale

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@francsiswanto
Copy link

In my case, I just do these:

  • remove all containers
  • prune docker network
  • done

It's work for me.

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Sep 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests