Fix/bind addr ipv6 fallback

[pinguinfuss]

---

• I have read the contributing guideline and understand that I have made the correct modifications

---

Description:

Commit 84a119f (#216) switched --bind-addr to "[::]:8443" so the service listens on both IPv4 and IPv6 via dual-stack. This works fine when an IPv6 stack is present (even on IPv4-only networks), but it fails outright when IPv6 is disabled at the kernel level (e.g. ipv6.disable=1, kernel built without CONFIG_IPV6, or the module not loaded). In that case there is no AF_INET6 socket family, so binding to [::] fails with EAFNOSUPPORT and code-server never starts — the container becomes unreachable.

This PR detects IPv6 availability at startup via the presence of /proc/net/if_inet6 (the standard indicator that the kernel has IPv6 support) and chooses the bind address accordingly:

• IPv6 available → [::]:8443 (dual-stack, unchanged behaviour from listen on both ipv4 and ipv6 even when running container as root #216)
• IPv6 unavailable → 0.0.0.0:8443 (IPv4 fallback)

Both the root and non-root exec paths use the shared BIND_ADDR variable.

Benefits of this PR and context:

Restores the ability to run the container on hosts/kernels with IPv6 disabled, which regressed after #216, while fully preserving the dual-stack behaviour that #216 introduced for everyone else. No configuration or environment variables are required — the correct address is selected automatically.

How Has This Been Tested?

Verified in a container inheriting a host kernel with IPv6 fully disabled
(/proc/net/if_inet6 and /proc/sys/net/ipv6 absent):

• Binding to [::]:8443 fails with [Errno 97] Address family not supported by protocol (reproduces the regression).
• Binding to 0.0.0.0:8443 succeeds.
• [[ -e /proc/net/if_inet6 ]] correctly evaluates false, so the script selects the 0.0.0.0 fallback.

On a normal dual-stack host /proc/net/if_inet6 is present and the script keeps [::]:8443, so existing IPv4+IPv6 behaviour is unchanged.

Source / References:

• Regressing change: listen on both ipv4 and ipv6 even when running container as root #216 (--bind-addr "[::]:8443")
• Related IPv4-only test note in listen on both ipv4 and ipv6 even when running container as root #216 did not cover kernels with IPv6 disabled
  (only IPv6-less networks with the stack still present).
• Prior art for the same class of problem in the LSIO ecosystem:
  Container does not work on host with ipv6 disabled docker-swag#92

Closes #218

[github-actions]

Thanks for opening this pull request! Be sure to follow the pull request template!

[pinguinfuss]

Relates to #218

[PLCHome]

One suggestion: it might be useful to adjust the BIND_ADDR from outside the container by setting an environment parameter. It's only two more lines of code:

in File root/etc/s6-overlay/s6-rc.d/svc-code at line 21

if [[ -z ${BIND_ADDR} ]]; then
  # Bind to the IPv6 wildcard (dual-stack, also serves IPv4) when IPv6 is
  # available, otherwise fall back to the IPv4 wildcard. Binding to "[::]"
  # fails outright on hosts/containers where IPv6 is disabled.
  if [[ -e /proc/net/if_inet6 ]]; then
      BIND_ADDR="[::]:8443"
  else
      BIND_ADDR="0.0.0.0:8443"
  fi
fi

Updates for README.md and an example showing how to handle it:

---
services:
  code-server:
    image: lscr.io/linuxserver/code-server:latest
    container_name: code-server
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - PASSWORD=password #optional
      - HASHED_PASSWORD= #optional
      - SUDO_PASSWORD=password #optional
      - SUDO_PASSWORD_HASH= #optional
      - PROXY_DOMAIN=code-server.my.domain #optional
      - DEFAULT_WORKSPACE=/config/workspace #optional
      - PWA_APPNAME=code-server #optional
      - BIND_ADDR="[::]:8443" #optional
    volumes:
      - /path/to/code-server/config:/config
    ports:
      - 8443:8443
    restart: unless-stopped

docker run -d \
  --name=code-server \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -e PASSWORD=password `#optional` \
  -e HASHED_PASSWORD= `#optional` \
  -e SUDO_PASSWORD=password `#optional` \
  -e SUDO_PASSWORD_HASH= `#optional` \
  -e PROXY_DOMAIN=code-server.my.domain `#optional` \
  -e DEFAULT_WORKSPACE=/config/workspace `#optional` \
  -e PWA_APPNAME=code-server `#optional` \
  -e BIND_ADDR="[::]:8443" #optional
  -p 8443:8443 \
  -v /path/to/code-server/config:/config \
  --restart unless-stopped \
  lscr.io/linuxserver/code-server:latest

[LinuxServer-CI]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[RoboMagus]

Keep it open

[madpeteguy]

Hope it will get merged, im sick of manual fixing after each version...

[pinguinfuss]

@PLCHome: should be in the PR now.

[drizuid]

im unsure why we should entertain people disabling an entire protocol stack in 2026?
it would be like telling us that you use ipx/spx and need to disable ipv4 because you disabled tcp/ip
we are also not fans of adding superfluous envvars, it will confuse most of our userbase to have something like bindaddr, so if anything that var makes it less likely to be merged

the tl;dr here is that while disabling ipv6 may have been suggested in the early 2000s by uneducated network admins, there is absolutely no value in it . it does not increase security, it breaks things, and it clearly adds administrative overhead.

I will leave this open for the other team members to chime in, since they're all ipv4 cult (and yet still dont suggest entirely disabling protocol stacks)

[PLCHome]

Let me explain the background a bit more clearly:
on a 32‑bit Raspberry Pi with IPv6 disabled at the OS level, the container currently does not start at all. In this specific environment, the only way to get the container running is to disable IPv6 inside the container as well. So this is not about “entertaining” arbitrary protocol‑stack disablement, but about making the software start on a constrained platform that is already configured without IPv6.

From a security perspective, there is an additional angle:
instead of fully disabling IPv6, one could also consider passing an address or prefix mask to restrict the allowed IPv6 range. This would actually increase security by limiting access to a specific IPv6 segment rather than keeping it completely open. In other words, the option would allow either:

a strict restriction of the IPv6 address space (more secure), or
a controlled disablement in environments where IPv6 is intentionally not used.
I fully understand your concern about introducing confusing or superfluous environment variables. However, it is not useless; it actually increases the security of the container.

[j0nnymoe]

I'm surprised this is running on your 32bit raspberry pi as we haven't built though I ages for 3 years now.

[PLCHome]

Sorry, it's a 64-bit Debian GNU/Linux 12 (bookworm) system using the linuxserver/code-server image on Docker. But it only runs with this change.

[drizuid]

on a 32‑bit Raspberry Pi with IPv6 disabled at the OS level, the container currently does not start at all.

this is the issue, as i mentioned there hasn't been a valid reason in 20+ years to disable it at the OS level even 20years ago, it was mostly just misunderstood

there is no need to try to convince me though, i cannot be convinced disabling the stack at the os/host level has value. The other team members will decide whether this gets merged. (which will also mean they have to do the same on numerous other containers for consistency if they decide to approve it)

[PLCHome]

It won't start without the change:

[custom-init] No custom files found, skipping...
starting with no password
[2026-09-14T11:55:19.227Z] info  code-server 4.131.0 a3fc2899bd0fcd388253c0e79ce33b8acd48c688
[2026-09-14T11:55:19.230Z] info  Using user-data-dir /config/data
[2026-09-14T11:55:19.275Z] error listen EAFNOSUPPORT: address family not supported :::8443
starting with no password
[2026-09-14T11:55:22.236Z] info  code-server 4.131.0 a3fc2899bd0fcd388253c0e79ce33b8acd48c688
[2026-09-14T11:55:22.240Z] info  Using user-data-dir /config/data
[2026-09-14T11:55:22.299Z] error listen EAFNOSUPPORT: address family not supported :::8443
starting with no password
[2026-09-14T11:55:25.391Z] info  code-server 4.131.0 a3fc2899bd0fcd388253c0e79ce33b8acd48c688
[2026-09-14T11:55:25.394Z] info  Using user-data-dir /config/data
[2026-09-14T11:55:25.439Z] error listen EAFNOSUPPORT: address family not supported :::8443
starting with no password
[2026-09-14T11:55:28.430Z] info  code-server 4.131.0 a3fc2899bd0fcd388253c0e79ce33b8acd48c688
[2026-09-14T11:55:28.434Z] info  Using user-data-dir /config/data
[2026-09-14T11:55:28.483Z] error listen EAFNOSUPPORT: address family not supported :::8443

With the change, the IP range has been switched to IPv4, and it is starting up.

[custom-init] No custom files found, skipping...
starting with no password
[2026-09-14T11:57:44.777Z] info  code-server 4.131.0 a3fc2899bd0fcd388253c0e79ce33b8acd48c688
[2026-09-14T11:57:44.780Z] info  Using user-data-dir /config/data
[2026-09-14T11:57:44.824Z] info  Using config file /config/.config/code-server/config.yaml
[2026-09-14T11:57:44.825Z] info  HTTP server listening on http://0.0.0.0:8443/
[2026-09-14T11:57:44.825Z] info    - Authentication is disabled
[2026-09-14T11:57:44.825Z] info    - Not serving HTTPS
[2026-09-14T11:57:44.826Z] info  Session server listening on /config/data/code-server-ipc.sock
Connection to 127.0.0.1 8443 port [tcp/*] succeeded!
[ls.io-init] done.

But I prefer only one interface:

[2026-09-14T12:05:00.140Z] info  code-server 4.131.0 a3fc2899bd0fcd388253c0e79ce33b8acd48c688
[2026-09-14T12:05:00.143Z] info  Using user-data-dir /config/data
[2026-09-14T12:05:00.189Z] info  Using config file /config/.config/code-server/config.yaml
[2026-09-14T12:05:00.189Z] info  HTTP server listening on http://192.168.178.228:8443/
[2026-09-14T12:05:00.190Z] info    - Authentication is disabled
[2026-09-14T12:05:00.190Z] info    - Not serving HTTPS
[2026-09-14T12:05:00.191Z] info  Session server listening on /config/data/code-server-ipc.sock

I just tried it again with the current version code-server 4.137.0 b11dabdaca0d3369986975be285db92c8795cea5 ; same behavior—it doesn't start.

[aptalca]

I don't think you understand what we are trying to tell you. What we're saying is that you SHOULD NOT be disabling ipv6 on your rpi. That is the reason the container is not starting as you are experiencing. We do not support disabling ipv6 at the OS level.