SteamCMD 'Needs to Be Online to Update': Docker 29.4.2 Fix

Published on

SteamCMD says it needs to be online to update, but the server is online? Docker 29.4.2 blocks a 32-bit socket call. How to confirm it, and Docker's own fixes.

Disk usage and bandwidth cards in a server control panel

A fresh game server install ends with !!! Fatal Error: Steamcmd needs to be online to update, yet the machine is clearly online: apt update works, other containers download fine, and your panel may even report "Installation completed" over an empty server folder. The message sends everyone off to check the network. In the reports from late October 2026 the network was fine every time. The cause was one Docker release, 29.4.2, and its default seccomp profile. Here is how to confirm that with two commands, and the fixes Docker's own maintainers name.

Quick answer: "Steamcmd needs to be online to update" inside a container usually means the Docker host runs Docker Engine 29.4.2. That release (1 May 2026) blocked the 32-bit socketcall(2) system call in Docker's default seccomp profile, as hardening against the "Copy Fail" kernel bug (CVE-2026-31431). SteamCMD on Linux is a 32-bit program, so its network calls fail with error 38 (ENOSYS) and it concludes it is offline. Docker 29.4.3 (6 May 2026) removed that block. Check with docker version --format '{{.Server.Version}}', upgrade Docker to 29.4.3 or later, and reinstall the servers that installed empty. Don't use seccomp=unconfined. On GitHub Actions, the ubuntu-26.04 runner image still ships 29.4.2, so pin the job to ubuntu-24.04 for now.

What the Error Looks Like

This is SteamCMD's self-update failing, from a game-ci/steam-deploy report of 27 October 2026 (shortened):

[  0%] Checking for available update...
[----] Verifying installation...
[  0%] Downloading Update...
[  0%] Checking for available update...
[----] !!! Fatal Error: Steamcmd needs to be online to update.  Please confirm your network connection and try again.
threadtools.cpp (3294) : Assertion Failed: Illegal termination of worker thread 'Thread(0x0x6039c320/0x0xee80aa'

The same cause shows up in other forms:

  • CreateBoundSocket: failed to create socket, error [no name available] (38) when an already updated SteamCMD tries to log in. That is from moby/moby #52506, the first report on 1 May, by a CubeCoders AMP developer.
  • Download failed: http error 0 in Steam/logs/bootstrap_log.txt (calagopus/wings #52).
  • In the same moby thread, Wine printed wine: socket : Function not implemented and a Garry's Mod server NET_OpenSocket: socket failed: Function not implemented.

Error 38 is ENOSYS, "Function not implemented". That number is the giveaway: a real network outage gives timeouts or refused connections, not a missing system call.

Why SteamCMD Thinks It Is Offline

Docker runs every container under a seccomp filter, a list of system calls the container may make. On 1 May 2026, Docker Engine 29.4.2 shipped a tighter default profile against CVE-2026-31431 ("Copy Fail"), a kernel bug that let a process escalate privileges through AF_ALG crypto sockets. Besides blocking AF_ALG, it blocked socketcall(2), the old multiplexer through which 32-bit x86 programs make socket calls. The profile behind it, moby/profiles seccomp v0.2.2, answers every socketcall with errno 38.

That hits SteamCMD directly. The linux32/steamcmd binary in Valve's current steamcmd_linux.tar.gz is a 32-bit Intel 80386 program; we checked the download on 3 November 2026. As a runner-images contributor confirmed in runner-images #14790, Debian's 32-bit glibc still sends its socket calls through socketcall, so a 32-bit glibc program in such a container can't even look up a host name. musl-based i386/alpine is not affected. The calagopus report caught it with strace: socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = -1 ENOSYS from the 32-bit steamcmd binary. No DNS, no download, "needs to be online".

Docker's 29.4.2 release notes list the breakage as a known issue: "The hardening can break 32-bit programs and i386 images, including SteamCMD and some Wine-based workloads." Five days later, 29.4.3 replaced the seccomp block with AppArmor and SELinux rules that stop AF_ALG "without disrupting legitimate 32-bit workloads".

Which Docker Versions Are Affected

Docker Enginesocketcall in the default seccomp profileSteamCMD in a container
29.4.1 and older, including 28.xAllowedWorks
29.4.2 (1 May 2026)Blocked, returns ENOSYSFails
29.4.3 (6 May 2026) and newerAllowed again; AF_ALG blocked by AppArmor or SELinux insteadWorks

The newest release on 3 November 2026 is 29.9.2, from 20 October. It still comes up because some hosts are stuck on 29.4.2. The calagopus report of 29 October ran Docker 29.4.2 on Ubuntu 24.04, and GitHub's ubuntu-26.04 runner image pins it (more on that below).

Step 1: Check Your Docker Version

On the Docker host (the Wings node, if your panel runs on a separate machine):

docker version --format '{{.Server.Version}}'
docker info --format '{{.SecurityOptions}}'

If the first line prints 29.4.2, you have found the cause. The second line shows which seccomp profile the daemon uses: name=seccomp,profile=builtin is Docker's own; a file path means someone set a custom profile in daemon.json.

On a Pterodactyl node, this lists every server whose last install hit the error (Wings keeps install logs in /var/log/pterodactyl/install/, one file per server UUID):

sudo grep -l "needs to be online" /var/log/pterodactyl/install/*.log

Step 2: Confirm It With a 32-bit Test

The runner-images report pins it down with a single container. On an x86_64 host, run a 32-bit and a 64-bit Debian side by side:

docker run --rm i386/debian:bookworm getent hosts github.com; echo "i386 exit code: $?"
docker run --rm debian:bookworm getent hosts github.com; echo "64-bit exit code: $?"
  • Both print an IP address and exit code 0: seccomp is not your problem. Go to "When It Is Not Docker" below.
  • The 64-bit one resolves, the i386 one prints nothing and exits 2: this is the socketcall block. On GitHub's runner, the same i386 test exited 0 with --security-opt seccomp=unconfined, which proves the point but is not a fix.
  • Both fail: DNS or the network itself is broken.

Step 3: Upgrade Docker to 29.4.3 or Later

This is the real fix. The Wings install guides of Pterodactyl and Pelican install Docker with curl -sSL https://get.docker.com/ | CHANNEL=stable bash (Pelican pipes it to sudo sh), which sets up Docker's apt repository. Docker's Ubuntu install page says to upgrade such an install with the package manager, not by running the script again:

apt-mark showhold
sudo apt update
apt list --all-versions docker-ce 2>/dev/null | head -3
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker version --format '{{.Server.Version}}'

If apt-mark showhold lists docker-ce or docker-ce-cli, someone pinned the version on purpose; release it with sudo apt-mark unhold docker-ce docker-ce-cli first. On 3 November 2026 Docker's repository offers 29.9.2 for both Ubuntu 24.04 and 26.04.

Plan a few minutes of downtime. The package upgrade restarts the Docker daemon, and Docker's live restore page says containers only keep running across patch releases, so a jump from 29.4.2 to 29.9.2 is not covered. Stop the game servers from the panel first and start them again afterwards.

Then run the step 2 test again and reinstall every server that "installed" without game files. On Pterodactyl that is Settings, Reinstall Server. The panel warns that "some files may be deleted or modified during this process", so back up any server that already has a world on it.

If You Can't Upgrade Yet: Docker's Profile Workaround

Docker's 29.4.2 release notes give one workaround, with warnings attached:

  • Don't use --security-opt seccomp=unconfined.
  • Don't use the older seccomp/v0.2.0 profile.
  • Use seccomp/v0.2.1 from moby/profiles, which allows socketcall but still blocks AF_ALG through socket.
  • Run a kernel that includes the CVE-2026-31431 fix. For Ubuntu's standard linux kernel package, Ubuntu's CVE page lists 6.8.0-117.117 as the fix on 24.04 and the 26.04 kernel as not affected. Check yours with uname -r.
  • Use it only for containers that need it, because those containers can still reach the bug through socketcall.

Download the profile:

sudo curl -fsSL https://raw.githubusercontent.com/moby/profiles/refs/tags/seccomp/v0.2.1/seccomp/default.json \
  -o /etc/docker/seccomp-profile-v0.2.1.json

With your own docker run, add --security-opt seccomp=/etc/docker/seccomp-profile-v0.2.1.json. A panel doesn't let you set that per server, so on a Wings node the only route is the daemon-wide default in /etc/docker/daemon.json. Merge the key into the file if it already holds settings:

{
  "seccomp-profile": "/etc/docker/seccomp-profile-v0.2.1.json"
}

Then run sudo systemctl restart docker and restart the game servers. docker info will now warn that the "daemon is not using the default seccomp profile". Treat this as a bridge: once you are on 29.4.3 or later, remove the key and restart Docker again. Otherwise you stay on this old profile and miss later updates to Docker's default, as a Docker contributor pointed out in the moby thread.

Pterodactyl, Pelican and Calagopus

The panels differ in which containers get hit.

  • Pterodactyl and Pelican: Wings gives server containers only no-new-privileges as a security option (Pterodactyl source, Pelican source), and install containers get no custom profile either. Docker's built-in profile applies to both, so on 29.4.2 a fresh install fails, and so does the SteamCMD update that many eggs run at every start.
  • Calagopus: its Wings applies its own seccomp profile to server containers when docker.container_apply_seccomp is on, so updates at start kept working. Install containers got Docker's default profile, which is why every SteamCMD egg install failed in the calagopus #52 report. The fix landed on 30 October, and the Wings 1.2.8 release notes list "Fixed not all places setting security_opt". Update Wings to 1.2.8, or upgrade Docker.

Watch for the false success. The calagopus report notes that most egg install scripts still report "Installation completed" after SteamCMD fails, so a server can look installed and have no game files at all. If a new SteamCMD server won't start, read the whole install log, not just its last line. Our guide to what the Panel and Wings each do explains where install scripts run.

GitHub Actions and Ubuntu 26.04 Hosts

Since GitHub started moving ubuntu-latest to Ubuntu 26.04, workflows that run SteamCMD in a container fail with the same message: depot uploads with game-ci/steam-deploy@v3 (#99) and jobs on the steamcmd/steamcmd images (steamcmd/docker #93). Both reports suspect the host OS. GitHub's own software lists point elsewhere. On 3 November 2026 the Ubuntu 26.04 image (version 20261026.180.1) lists Docker Server 29.4.2, the Ubuntu 24.04 image lists Docker Server 28.0.4, and both run the same kernel, 7.0.0-1017-azure. A runner-images contributor confirmed the socketcall cause in #14790 on 28 September, and a pull request that moves the 26.04 image to Docker 29.7.2 (#15205) was still open on 3 November.

Until that lands, use the workaround both projects use:

jobs:
  upload:
    runs-on: ubuntu-24.04  # was ubuntu-latest

On your own Ubuntu 26.04 VPS, the operating system is not the problem. Ubuntu's own docker.io package for 26.04 is 29.1.3 (29.1.3-0ubuntu4.1 on 3 November 2026), older than the change, and its changelog shows no seccomp change. Docker's repository for 26.04 carries 29.4.2 as well, though, so a host set up in early May and never upgraded can still have it. Step 1 tells you. Our Ubuntu 26.04 VPS guide covers the rest of the release.

When It Is Not Docker

If the step 2 test passes, or SteamCMD runs straight on the host without Docker, seccomp is out of the picture and the message may mean what it says. Run this on the machine or in the container that runs SteamCMD:

getent hosts steamcdn-a.akamaihd.net
curl -sI https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz | head -1

The second command asks Valve's CDN for the SteamCMD installer itself; a line with 200 means DNS and outgoing HTTPS work. On a Wings node, containers use the DNS servers under docker.network.dns in the Wings config (/etc/pterodactyl/config.yml, or /etc/pelican/config.yml on Pelican), which default to 1.1.1.1 and 1.0.0.1 in both. If your network only allows its own resolver, put that address there, then restart Wings and the server.

Your Own VPS or a Managed Server

On our VPS plans you get KVM virtualization and full root access, so the Docker version, daemon.json and Wings are yours to manage with the steps above. If the error shows up on a game server you rent from us, you don't manage Docker there: tell support which server it is by live chat, Discord or email, between 08:00 and 20:00 UTC.

FAQ

What does "Steamcmd needs to be online to update" mean? SteamCMD's bootstrapper could not download its own update. Inside a Docker container on Docker 29.4.2, that almost always means its 32-bit network calls are blocked, not that the network is down.

Why does SteamCMD say it needs to be online when my server clearly has internet? Because only 32-bit programs lose their network. 64-bit tools in the same container use the direct socket call, which Docker 29.4.2 still allows, so apt, curl and the panel all work while SteamCMD fails.

Which Docker version fixes it? 29.4.3, released 6 May 2026, and every version after it. On 3 November 2026 the newest is 29.9.2.

Is --security-opt seccomp=unconfined an acceptable fix? No. Docker's release notes say not to use it: it switches off the whole filter, not just the socketcall rule. Upgrade Docker, or use the v0.2.1 profile as a stopgap.

Why does SteamCMD only fail on ubuntu-latest in GitHub Actions? ubuntu-latest is moving to the Ubuntu 26.04 image, which ships Docker 29.4.2. The 24.04 image ships Docker 28.0.4, so runs-on: ubuntu-24.04 works until GitHub updates Docker on 26.04.

My panel says "Installation completed" but the server folder is empty. Is that the same problem? Very likely, if the install log shows the "needs to be online" line above it. Many egg install scripts carry on after SteamCMD fails. Fix Docker first, then reinstall the server.

Sources

All opened on 3 November 2026: