I was struggling with this issue for past two days with a new install. Even update check showed network error. Truenas connect also didn’t work.
I just changes time zone form Asia/Kolkata to Asia/calcutta and eveything working now!
also changed my primary dns in truneas to 8.8.8.8.
Yesterday was probably due to the huge cloudflare outage
Update: I found the actual cause, and it’s my router (or ISP), not TrueNAS. My network silently drops any UDP DNS query that carries an EDNS0 record. That applies to every resolver (1.1.1.1, 8.8.8.8, 9.9.9.9, even the router’s own), over IPv4 and IPv6, and from other machines on the LAN too, so it isn’t TrueNAS-specific. The same query without EDNS, or over TCP, answers instantly. Go’s DNS resolver has added EDNS0 to its queries since Go 1.21, while glibc doesn’t by default. That’s why curl, getent and nslookup worked fine while dockerd and containerd, which are Go, timed out. I suspect the upgrade only exposed the problem, because an older build didn’t send EDNS. The GODEBUG=netdns=cgo / use-vc workaround earlier in this thread works because it switches to glibc or to TCP. Of the RES_OPTIONS settings, single-request does nothing here and use-vc is what fixes it. My gateway is a Nokia HA-140W. To check whether you’re affected:
dig @1.1.1.1 ``registry-1.docker.io`` # times out if affected (dig sends EDNS by default)
dig @1.1.1.1 ``registry-1.docker.io`` +noedns # answers
dig @1.1.1.1 ``registry-1.docker.io`` +tcp # answers
The /etc/systemd override doesn’t survive a TrueNAS upgrade, because each upgrade creates a new boot environment. I now use a Post Init command instead (System → Advanced → Init/Shutdown Scripts), which is stored in the config and persists: grep -q '^options.*use-vc' /etc/resolv.conf || echo 'options use-vc' >> /etc/resolv.conf
Edit: Ah, but a side effect of the use-vc fix is that Docker copies the host’s /etc/resolv.conf options into every container, so all containers inherit use-vc too. glibc copes with this. c-ares doesn’t: it’s Bun’s default resolver and is also behind Node’s dns.resolve*. It times out after about 25s against Docker’s embedded DNS at 127.0.0.11, for sibling compose service names and external hosts alike. I only noticed because a Bun app went into a boot loop. It couldn’t resolve its own postgres service, and a hard-coded extra_hosts IP I’d added earlier as a stopgap now pointed at a different container. The fix is a workaround per app: set any dns_opt in the compose file, e.g. dns_opt: [“ndots:0”]. That replaces the inherited options instead of adding to them, and both service names and external names then resolve instantly. External lookups still work because Docker’s embedded resolver forwards them upstream itself. You can check what a container got with docker exec grep options /etc/resolv.conf.