Xkasmvnc: 'vncExtInit: failed to bind socket: Address already in use (98)' in Docker with network_mode: host — fails on all display numbers

[dop-amine]

Describe the bug

When running Xkasmvnc inside a Docker container with --network=host (or network_mode: host in Compose), the server always fails with a fatal error at vncExtInit regardless of which display number is used. The error occurs on every display number tested (:0, :1, :20, :97, :98, etc.) and under any user (root or non-root).

Xvnc KasmVNC 1.4.0.663b6d6a0bdd4638bff981c75a522056aaaa1c2e - built Sep 22 2025 14:56:59
Copyright (C) 1999-2018 KasmVNC Team and many others (see README.me)
See http://kasmweb.com for information on KasmVNC.
Underlying X server release 12101012

 2026-06-02 [INFO] ICE: Querying public IP...
 2026-06-02 [INFO] ICE: My public IP is [redacted]
 2026-06-02 [INFO] vncext: VNC extension running!
(EE)
Fatal server error:
(EE) vncExtInit: failed to bind socket: Address already in use (98)

The same container image with TigerVNC (tigervnc-standalone-server) works correctly on the same display numbers.

---

System Description

Host OS:

PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.4 LTS (Noble Numbat)"
ID=ubuntu

Linux [hostname] 6.8.0-60-generic #63-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Docker version: 29.x, running container with network_mode: host / --network=host.

---

KasmVNC Details

Package installed: kasmvncserver_noble_1.4.0_amd64.deb

$ Xkasmvnc -version
Xvnc KasmVNC 1.4.0.663b6d6a0bdd4638bff981c75a522056aaaa1c2e - built Sep 22 2025 14:56:59

---

To Reproduce

Minimal Dockerfile:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl && \
    curl -fsSLo /tmp/kasmvnc.deb \
        "https://github.com/kasmtech/KasmVNC/releases/download/v1.4.0/kasmvncserver_noble_1.4.0_amd64.deb" && \
    apt-get update && apt-get install -y /tmp/kasmvnc.deb && \
    rm /tmp/kasmvnc.deb && rm -rf /var/lib/apt/lists/*

docker build -t kasmvnc-test .
docker run --network=host --rm kasmvnc-test \
    Xkasmvnc :1 -SecurityTypes None -geometry 1280x720 -depth 24

Expected behavior: KasmVNC starts and serves the web client on the configured port.

Actual behavior: Fatal error — vncExtInit: failed to bind socket: Address already in use (98) — server exits immediately.

---

Diagnosis / What was ruled out

The error EADDRINUSE (98) is not coming from an obvious port conflict. Extensive debugging shows:

1. All display numbers fail — tested :0, :1, :20, :97, :98, :99. The error is not display-specific.
2. No conflicting TCP ports — ss -tlnp confirms nothing is listening on ports 5900–5999, 6079–6080, 8443, or any other expected VNC/HTTP port.
3. No stale X lock files — /tmp/.X11-unix/ is empty, no /tmp/.X{N}-lock files exist.
4. User is irrelevant — error occurs as root and as non-root via runuser.
5. Config file location confirmed — /home/user/.vnc/kasmvnc.yaml with use_ipv6: false and explicit websocket_port does not resolve the issue.
6. TigerVNC works fine — replacing Xkasmvnc with TigerVNC's Xvnc on the identical display numbers succeeds without error.

Hypothesis: With --network=host, Docker shares the host's network namespace, which includes the abstract Unix domain socket namespace. KasmVNC 1.4.0 may be attempting to bind an abstract socket with a name that is either fixed (not display-number-scoped) or conflicts with something already present in the host's abstract socket namespace. This would explain why:

• Every display number fails (fixed socket name → always conflicts)
• The conflict is invisible to ss -tlnp (abstract sockets, not TCP)
• TigerVNC works (uses different/no abstract sockets for its VNC extension)

Running without --network=host (bridge mode) has not been tested, as host networking is required by the deployment. It is possible the issue does not reproduce in bridge networking.

---

Additional context

• This was a regression from the previously working TigerVNC + noVNC + websockify stack
• KasmVNC 1.3.3 was briefly tested but the noble .deb appeared to not install over 1.4.0 cleanly in the test environment, so it's unclear if 1.3.x is affected
• The ICE: Querying public IP log line appears immediately before the fatal error, suggesting the ICE/STUN/UDP initialization may be related — though the error occurs in vncExtInit, not an ICE-specific function
• The reproduction is 100% consistent: every cold-start attempt on a fresh container fails

Any guidance on which socket vncExtInit is attempting to bind in 1.4.0 would help narrow the root cause. Happy to test patches or provide additional debugging output.