Syncthing docker instance can't reach IPv6

john3voltas · February 13, 2026, 1:55pm

Greetings folks. I have a similar setup to the one in this post: Discovery Failures: connection refused for v4 and v6

So, I have a Linux laptop, an android smartphone and a raspberry pi 5. The Pi5 is running Syncthing on a docker container. Everything works properly, but I notice that ST on the Pi5 has issues connecting to IPv6.

The Docker on the Pi is configured to support IPv6 as stated here Use IPv6 networking | Docker Docs . I can reach IPv6 servers when I try them from the Docker host. I’m at a loss. Can someone give me a hand with this? Thanks in advance. Cheers

bt90 · February 13, 2026, 5:12pm

What exactly did you configure? Simple IPv6 connectivity doesn’t require any manual configuration if you don’t intend to address containers with their own IPv6

john3voltas · February 13, 2026, 6:13pm

I did this:

The Pi itself comes with IPv6 enabled on it’s eth0, but the bridge0 interface didn’t have IPv6 enabled. It thought that was the cause for Syncthing’s IPv6 issues and that’s why I made those changes. But it didn’t help. I still only get 4/5 on the Pi and it keeps outputting the same error message that I pasted in the first post.

bt90 · February 13, 2026, 7:26pm

github.com/syncthing/syncthing

README-Docker.md

main

# Docker Container for Syncthing

Use the Dockerfile in this repo, or pull the `syncthing/syncthing` image
from Docker Hub.

Use the `/var/syncthing` volume to have the synchronized files available on the
host. You can add more folders and map them as you prefer.

Note that Syncthing runs as UID 1000 and GID 1000 by default. These may be
altered with the `PUID` and `PGID` environment variables. In addition
the name of the Syncthing instance can be optionally defined by using
`--hostname=syncthing` parameter.

To grant Syncthing additional capabilities without running as root, use the
`PCAP` environment variable with the same syntax as that for `setcap(8)`.
For example, `PCAP=cap_chown,cap_fowner+ep`.

To set a different umask value, use the `UMASK` environment variable. For
example `UMASK=002`.

This file has been truncated. show original

I’d recommend switching to host networking mode. This also improves Syncthings ability to discover local IPs.

john3voltas · February 17, 2026, 2:54pm

The issue was with docker’s default network. Even though I had enabled IPv6 on it (as per documentation) it just wouldn’t work. I decided to add another network in the docker compose yaml and bind syncthing’s network to that specific new network and it worked fine. This is what I had to configure in the yaml:

bt90 · February 17, 2026, 3:11pm

While this might work, you’ll miss out on better discovery. Host network mode is the way to go

john3voltas · February 17, 2026, 7:55pm

I can’t see how. Right now my discovery is stating 5/5. Isn’t that the max? Or is it possible to have 5/5 and the discoverability still being somewhat weaker than desired?

acolomb · February 17, 2026, 10:59pm

It means that 5 methods for announcing its local address are configured and working. But if that address is not reachable from outside the container, then the info isn’t worth a lot.

john3voltas · February 19, 2026, 12:35pm

I see. But it is bridged. How would that address not be reachable from outside? The only way would be through a firewall, right? I honestly don’t get it why I would need to go with host_network instead of a simple bridge. And I’m not arguing with you guys. I thank you a lot for your help. I’m just trying to understand why the developers would think the host_network is more suited than a bridge. Thanks a lot

bt90 · February 19, 2026, 2:00pm

If it’s fully bridged and no kind of NAT or masquerading is involved, than you’re right.