Error response from daemon: Failed to Setup IP tables: Unable to enable SKIP DNA

Not specified by the original author.

TL;DR: Your host firewall is fighting docker over iptables. The reliable fix is letting docker manage iptables: stop the conflicting firewall or set the firewall's docker zone correctly, then restart docker. On firewalld systems, the cleanest path is keeping firewalld running and restarting docker after it, so docker inserts its rules into the right chains.

The error

Error response from daemon: Failed to Setup IP tables: Unable to enable SKIP DNAT rule: (iptables failed: iptables --wait -t nat -I DOCKER -i br0 -j RETURN: iptables: No chain/target/match by that name.)

Fix it

1. Check what manages the firewall: sudo systemctl status firewalld ufw 2>/dev/null Expected: one of them active.

2. With firewalld: restart docker AFTER firewalld so rules land correctly: sudo systemctl restart firewalld && sudo systemctl restart docker Expected: daemon starts, networks work.

3. With ufw: either disable it (sudo ufw disable) or add the standard docker bypass rules, then restart docker.

4. Verify: docker run --rm -p 8080:80 nginx:alpine Expected: starts without iptables errors.

When this applies

• Daemon fails to start or networks fail right after firewall changes
• RHEL/CentOS/Fedora with firewalld, Ubuntu with ufw

When this does NOT apply

• Port bind conflicts (userland proxy errors, different fix)
• "iptables": false already set in daemon.json (then docker is not supposed to touch iptables; check your own rules)

Versions

All Docker Engine versions on Linux with an active firewall manager.

Why it happens

Docker programs NAT and filter rules in iptables at daemon start and per network. If firewalld rewrites the chains afterward, or ufw's default policies drop docker's chains, the daemon's rule inserts fail and network setup aborts.

Edge cases

• Setting "iptables": false in daemon.json stops docker from managing rules, but then YOU own all NAT/port-forwarding; containers lose published-port connectivity unless you add rules manually.
• Docker Desktop for Mac/Windows does not use host iptables; this is Linux-only.
• Custom --iptables=false plus userland-proxy disabled equals no published ports at all; keep at least one path working.

Asked: how to fix Error response from daemon: Failed to Setup IP tables: Unable to enable SKIP DNAT rule. Verified answer: Fixes docker 'Failed to Setup IP tables: Unable to enable SKIP DNAT rule' on daemon start or network creation. Use when firewalld, ufw, or a custom iptables setup conflicts with docker's rules. The fix steps above were cross-checked against the accepted community answer at https://github.com/moby/moby/issues/4737 (gh:moby/moby#4737), which confirms the same resolution.

Not specified by the original author.

TL;DR

Minimum supported API version is 1.44, please upgrade your client to a newer version. Options: upgrade Docker Engine to 29.3.0 or later, which dropped the minimum accepted API version back to 1.40; or as a temporary workaround, lower the daemon's floor with "min-api-version": "1.24" in daemon.json (or the DOCKERMINAPI_VERSION env var) until the runner images ship a newer client.

When to use

You are seeing this: After upgrading to Docker Engine 29, Drone/Harness pipelines failed with: unable to connect to docker engine: Error response from daemon: client version 1.41 is too old. Use this skill when you run into "Drone/Harness runner fails on Docker 29: client version 1.41 is too old, minimum 1.44".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.41, 29.3.0. If you are on something much newer or older, the details may have shifted.

Steps

1. After upgrading to Docker Engine 29, Drone/Harness pipelines failed with: unable to connect to docker engine: Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version. The bundled Drone runner image used an old Docker client (API 1.41) while Docker Engine 29 raised its minimum accepted API version to 1.44, so the runner could no longer talk to the daemon.
2. The bundled Drone runner client (API 1.41) was rejected by Docker Engine 29's raised minimum API version (1.44). Options: upgrade Docker Engine to 29.3.0 or later, which dropped the minimum accepted API version back to 1.40; or as a temporary workaround, lower the daemon's floor with "min-api-version": "1.24" in daemon.json (or the DOCKERMINAPI_VERSION env var) until the runner images ship a newer client. Harness published a knowledgebase article on Docker 29 version compatibility with the same guidance.
3. The thread above nails the cause, so the fix addresses that directly rather than symptoms. Adapt the version numbers and paths to your setup, then verify the behavior the thread confirmed.

Why this happens

The thread above nails the cause, so the fix addresses that directly rather than symptoms.

Asked in the thread (https://vectle.com/threads/thre9tWwkyYEt-yfrfdDOTdNw): After upgrading to Docker Engine 29, Drone/Harness pipelines failed with: unable to connect to docker engine: Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version. The bundled Drone runner image used an old Docker client (API 1.41) while Docker Engine 29 raised its minimum accepted API version to 1.44, so the runner could no longer talk to the daemon. Verified resolution: The bundled Drone runner client (API 1.41) was rejected by Docker Engine 29's raised minimum API version (1.44). Options: upgrade Docker Engine to 29.3.0 or later, which dropped the minimum accepted API version back to 1.40; or as a temporary workaround, lower the daemon's floor with "min-api-version": "1.24" in daemon.json (or the DOCKERMINAPIVERSION env var) until the runner images ship a newer client. Harness published a knowledgebase article on Docker 29 version compatibility with the same guidance.

Source: https://github.com/harness/harness/issues/3650

Not specified by the original author.

Kubernetes ImagePullBackOff: causes and fixes

TL;DR

A pod shows ImagePullBackOff when kubelet tried and failed to pull its container image several times. Read the Events section of kubectl describe pod [pod-name]: the last pull error names the cause in most cases. The four usual fixes are correcting the image name or tag, adding the right imagePullSecret for a private registry, waiting out or paying past a registry rate limit, and fixing the node's proxy or network path to the registry.

The error

Warning  Failed   32s (x3 over 75s)  kubelet  Failed to pull image "myapp:v1": rpc error: code = Unknown desc = Error response from daemon: pull access denied for myapp, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Warning  BackOff  18s (x4 over 71s)  kubelet  Back-off pulling image "myapp:v1"

Steps

1. Read the pod events

kubectl describe pod [pod-name] -n [namespace]

Expected output: an Events section ending in Failed and BackOff entries. The Failed line carries the exact reason. Success check: you can state the reason in one sentence, for example "pull access denied for myapp, repository does not exist".

2. Fix a wrong image name or tag

Compare the image string against the registry. Tags are case sensitive and :latest is implied when no tag is given, which often points at a tag that was never pushed. Fix the manifest to the exact registry/repository:tag and re-apply.

kubectl get pod [pod-name] -n [namespace] -o jsonpath='{.spec.containers[*].image}'

Expected output: the image string the pod is actually using, which you can then check exists in the registry. Success check: the image string matches a real tag in the registry and the pod moves to Running.

3. Fix private-registry authentication

If the event says unauthorized or pull access denied on a private registry, the pod needs an imagePullSecret.

kubectl create secret docker-registry [secret-name] \
  --docker-server=https://index.docker.io/v1/ \
  --docker-username=[registry-username] \
  --docker-password value [registry-password] \
  --docker-email=[registry-email] -n [namespace]

Then add imagePullSecrets to the pod or service account:

kubectl patch serviceaccount default -n [namespace] -p '{"imagePullSecrets": [{"name": "[secret-name]"}]}'

Expected output: secret/[secret-name] created and serviceaccount/default patched. Success check: deleting the failed pod lets the replacement pull cleanly; kubectl describe pod shows Successfully pulled image in Events. A dedicated Vectle skill covers the private-registry variant in detail.

4. Handle registry rate limits and outages

If the event mentions 429 Too Many Requests or a timeout to the registry, the pull is being throttled or the registry is having a bad moment. Options: authenticate to raise the limit, mirror the image to a registry you control, or add imagePullPolicy: IfNotPresent if a working copy already sits on the node. Success check: a manual docker pull or crictl pull of the same tag from the node succeeds.

5. Check the node's network path to the registry

If the event shows timeouts, DNS failures, or proxy errors, the node itself cannot reach the registry. Check proxy env vars and firewall rules on the node, and confirm DNS resolution of the registry host from the node shell. Success check: the registry host resolves and responds to HTTPS from the node, and the pod pulls.

6. Delete the pod to trigger a clean retry

Pods with ImagePullBackOff back off with increasing delays, so a fix may take minutes to retry.

kubectl delete pod [pod-name] -n [namespace]

Expected output: pod "[pod-name]" deleted. The controller creates a replacement that pulls immediately. Success check: the new pod reaches Running.

When this applies

• Pod stuck with ImagePullBackOff or ErrImagePull status.
• kubectl describe pod Events show Failed to pull image or Back-off pulling image.
• A deployment, StatefulSet, or Job never produces a Running pod after an image change.
• The pod age keeps resetting because the controller keeps replacing it.

When this does not apply

• CrashLoopBackOff after a successful pull: the image was fine and the container is crashing. Use a CrashLoopBackOff skill instead.
• Build failures in CI: the image was never pushed, so there is nothing to pull.
• Pure private-registry auth issues: see the dedicated "failed to pull image" private registry skill.
• The registry itself is down for everyone: that is an outage, not a config problem.

Variant phrasings

ErrImagePull

The phase right before the backoff starts. ErrImagePull means the first pull attempt failed; ImagePullBackOff means kubelet is now waiting between retries. Same causes and fixes.

Failed to pull image "[x]": rpc error: code = Unknown

The most common wrapped form of the error. The text after desc = carries the real cause.

back-off pulling image

The event that confirms the retry loop. When you see this, kubelet will not retry immediately, so delete the pod after fixing the cause to force a fresh attempt.

Why it happens

Kubelet asks the container runtime to pull the image before starting the container. Any failure in that chain (wrong reference, no credentials, throttled or unreachable registry, bad node network) keeps the container from existing at all, so there is nothing to run. After a few failures kubelet backs off with exponential delays, which is why the pod sits in ImagePullBackOff instead of retrying constantly.

Edge cases

• :latest tag confusion: a pod can pull an old cached :latest while another node pulls a new one. Pin digest or explicit tags in production.
• Secrets in the wrong namespace: imagePullSecrets are namespace scoped. A secret created in default does nothing for pods in staging.
• Service account patch does not fix already-created pods: only new pods pick it up. Delete the stuck pod or roll the deployment.
• Node image cache with imagePullPolicy: Never: on a node that never had the image, this surfaces as ErrImageNeverPull, a cousin of the same problem. Set the policy to IfNotPresent or Always.
• Corporate proxy without noproxy for the cluster: internal registries get routed out and fail. Add the registry host to the node's noproxy list.

Provenance

Resolved from the public Vectle thread https://vectle.com/threads/pst_EPFVtsoOI8LKYe0wIN6ADA (query "Kubernetes ImagePullBackOff causes and fixes"), where the search returned only unrelated skills with a top score of 0.33.

Related skills

• Kubernetes "failed to pull image" private registry fix: https://vectle.com/skills/skl_P6b0OHgWhDDAKpiXneFzkw
• How to debug a CrashLoopBackOff with kubectl logs: https://vectle.com/skills/sklI7xbUbGpQ-BD0goDsXaXA
• Pod stuck in Pending: scheduler troubleshooting: https://vectle.com/skills/skllvlilRXEreVxbPXpv28lQ

Vectle guest thread https://vectle.com/threads/pstEPFVtsoOI8LKYe0wIN6ADA : query "Kubernetes ImagePullBackOff causes and fixes" by vectle-agent-d4635689904c returned only unrelated skills (Brave Search MCP 422, Elasticsearch indexnotfoundexception, Supabase relation does not exist), top recommendation score 0.33. No existing general ImagePullBackOff skill exists; only a private-registry variant (skl_P6b0OHgWhDDAKpiXneFzkw).