`configure_docker_dns: true` breaks everything on blacksmith.sh runners

[rsmartins78]

Hi,

My workflow has some Docker commands that fail after the warp step is executed, so I tried to enable configure_docker_dns to true and that breaks the whole thing.

/home/runner/_work/_actions/Boostport/setup-cloudflare-warp/v1.14.0/dist/index.js:30726
    if (err.code === "ENOENT") {
            ^

TypeError: Cannot read properties of null (reading 'code')
    at /home/runner/_work/_actions/Boostport/setup-cloudflare-warp/v1.14.0/dist/index.js:30726:13
    at FSReqCallback.oncomplete (node:fs:199:5)

[F21]

Can you try with v1.8.0? This was the version before the configure_docker_dns option was introduced.

[F21]

I just tried using it in a test repo and it worked fine. Are you using Github's hosted runners or your own runners?

Here's my output:

Run Boostport/setup-cloudflare-warp@v1
  with:
    organization: ***
    auth_client_id: ***
    auth_client_secret: ***
    configure_docker_dns: true
/bin/bash -c echo DNSStubListenerExtra=172.17.0.1 | sudo tee -a /etc/systemd/resolved.conf
/bin/bash -c echo '{}' | sudo tee /etc/docker/daemon.json
DNSStubListenerExtra=172.17.0.1
{}
/bin/bash -c cat /etc/docker/daemon.json | jq '.dns=["172.17.0.1"]' | sudo tee /etc/docker/daemon.json
{
  "dns": [
    "172.17.0.1"
  ]
}
/usr/bin/sudo systemctl restart systemd-resolved
/usr/bin/sudo systemctl restart docker
/usr/bin/sudo mkdir -p /var/lib/cloudflare-warp/
/usr/bin/sudo mv /tmp/mdm.xml /var/lib/cloudflare-warp/
/usr/bin/which warp-cli
warp-cli not found, proceeding with installation
/bin/bash -c cat /home/runner/work/_temp/5936e559-4d00-49e7-80d6-57f5ae484a14 | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg
/bin/bash -c echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list
deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ noble main
/usr/bin/sudo apt update

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

This is my workflow:

on:
  push:
    branches:
      - main
name: test
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Connect to Cloudflare WARP
        uses: Boostport/setup-cloudflare-warp@v1
        with:
          organization: ${{ secrets.CLOUDFLARE_ACCESS_ORGANIZATION }}
          auth_client_id: ${{ secrets.CLOUDFLARE_ACCESS_CLIENT_ID }}
          auth_client_secret: ${{ secrets.CLOUDFLARE_ACCESS_CLIENT_SECRET }}
          configure_docker_dns: true

      - name: Checkout
        uses: actions/checkout@v4

      - name: Import Secrets
        uses: enflo/curl-action@master
        with:
          curl: -k SOME_PRIVATE_ADDRESS

[F21]

I just released v1.15.0 which migrates all usage of fs to the promise version. Perhaps that will fix your issue.

[rsmartins78]

Hi, version v1.15.0 is not breaking anymore, but DNS resolution inside a docker container also doesn't work.
My runner is a blacksmith.sh machine.

[F21]

Ah that must be the problem. I am guessing blacksmit.sh doesn't use identical OS images as the GitHub actions runners. The bits that set up dns resolution from within docker are here: https://github.com/Boostport/setup-cloudflare-warp/blob/main/lib/setup-cloudflare-warp.js#L185

I would suggest forking the repo and adding some debug statements and running them on your blacksmith.sh runner to see what's failing. Once that's done, we can potentially add a few more configurations to allow customization of file paths.

[rsmartins78]

I've inspected /etc/resolv.conf and the content is pointing to 127.0.0.53.
Then I ran resolvectl status and the output is:

Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 9.9.9.9 149.112.112.112

Link 2 (dummy0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 1.1.1.1
        DNS Domain: ~.

Link 4 (sit0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (ip6tnl0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (ip6gre0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 7 (tailscale0)
    Current Scopes: none
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 9 (bsdummy6)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

It looks pretty ok to me, I really can't understand why docker doesn't work. BUT, if I stop WARP client, docker start again to resolve the names.

[F21]

Can you post the contents of /etc/docker/daemon.json and /etc/systemd/resolved.conf?

Can you also add another step before this action and check to see if warp-cli is already installed on the machine?

[rsmartins78]

warp-cli is not installed, so the action installs it every run
warp-cli not found, proceeding with installation

/etc/docker/daemon.json

{
  "registry-mirrors": [
    "http://192.168.127.1:5000/"
  ],
  "insecure-registries": [
    "192.168.127.1:5000"
  ],
  "dns": [
    "172.17.0.1"
  ]
}

/etc/systemd/resolved.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/resolved.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
#StaleRetentionSec=0
DNSStubListenerExtra=172.17.0.1

[F21]

These are the results on GH actions:

{
  "dns": [
    "172.17.0.1"
  ]
}

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/resolved.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.
[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
#StaleRetentionSec=0
DNSStubListenerExtra=172.17.0.1

Can you check if the docker daemon hands out ip addresses in the 172.17.x.x range?

[rsmartins78]

Looks like yes.
docker network inspect bridge

[
    {
        "Name": "bridge",
        "Id": "4cadc9711ed114fd5063f09efb0b75d090554248cc0624f83a03ded3421b46b8",
        "Created": "2025-08-27T09:48:40.89806029Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

[F21]

Maybe blacksmith.sh has something different in their networking that's different from GH actions. Maybe add a separate step after the setup-cloudflare-warp action to restart the warp-cli as a workaround for now.

If you find a solution, I am happy to accept a PR for it.