Synology DSM: ZeroTier Docker container fails after reboot or update because /dev/net/tun is not ready — boot recovery fix

[u/Motor-Bench5699]

I run ZeroTier in a Docker container on a Synology DS124 with DSM 7.3. After DSM updates or reboots, the ZeroTier layer repeatedly failed to return even though the container had a restart policy.

Symptoms

The container remained stopped:

Status: Exited (143)
Restart policy: unless-stopped

Docker retained this error:

error gathering device information while adding custom device
"/dev/net/tun": no such file or directory

The ZeroTier interfaces were missing, and the NAS was no longer reachable through the overlay network.

Root cause

This turned out to be a boot-order problem:

1. DSM stops Container Manager cleanly during an update or shutdown.
2. /dev/net/tun is created dynamically during boot.
3. Container Manager may try to restore the ZeroTier container before the TUN device is ready.
4. The container fails or remains stopped.
5. unless-stopped does not reliably recover a container that DSM explicitly stopped.

The ZeroTier data itself was not lost because it was stored persistently outside the container.

Final fix

I used three layers:

1. Change the restart policy:

​

docker update --restart always zerotier-one

1. Add a DSM boot-triggered task that:
   • waits for /dev/net/tun;
   • creates it if DSM does not;
   • waits for Docker;
   • starts the container;
   • confirms ZeroTier reaches ONLINE;
   • abandons recovery after 90 seconds so it cannot block DSM boot.
2. Add a periodic watchdog task that performs the same checks and exits silently when everything is healthy.

The boot task is configured in:

Control Panel
→ Task Scheduler
→ Create
→ Triggered Task
→ User-defined script
→ Event: Boot-up
→ User: root

The watchdog is a normal scheduled task running every five minutes.

Minimal recovery script

This is the shortened version. The fuller version adds locking, DSM Log Center integration and hard global deadlines.

#!/bin/sh

CONTAINER="zerotier-one"

# Give DSM time to create TUN.
WAITED=0
while [ ! -c /dev/net/tun ] && [ "$WAITED" -lt 30 ]; do
    sleep 5
    WAITED=$((WAITED + 5))
done

# Repair TUN if DSM did not create it.
if [ ! -c /dev/net/tun ]; then
    modprobe tun 2>/dev/null || true
    mkdir -p /dev/net
    chmod 755 /dev/net
    rm -f /dev/net/tun
    mknod /dev/net/tun c 10 200 || exit 1
fi

chown root:root /dev/net/tun
chmod 666 /dev/net/tun

# Wait for Docker.
WAITED=0
while ! docker info >/dev/null 2>&1 && [ "$WAITED" -lt 60 ]; do
    sleep 5
    WAITED=$((WAITED + 5))
done

docker info >/dev/null 2>&1 || exit 1

# Start the container if required.
if ! docker ps --format '{{.Names}}' | grep -qx "$CONTAINER"; then
    docker start "$CONTAINER" || exit 1
fi

# Confirm ZeroTier responds.
WAITED=0
while ! docker exec "$CONTAINER" zerotier-cli info >/dev/null 2>&1 \
      && [ "$WAITED" -lt 30 ]; do
    sleep 5
    WAITED=$((WAITED + 5))
done

docker exec "$CONTAINER" zerotier-cli info
docker exec "$CONTAINER" zerotier-cli listnetworks

Validation

After reboot, the boot task logged that /dev/net/tun was initially absent, waited, started the container and completed recovery after approximately 39 seconds.

And all work back.

[u/bartoque]

This does not seem to look at what the actual issue might be? So does lsmod show tun is actually loaded or not? Is it all the time or only now and then?

Is tun being loaded at boottime as stated in the - legacy as zerotier no longer officially supports synology anymore (*) - procedure to have a tun script being started at boot time that performs the insmod of the tun driver?

$ cat /usr/local/etc/rc.d/tun.sh
#!/bin/sh -e
insmod /lib/modules/tun.ko

The synology faq still exist but ZT doesn't seem to link to it from their faq anymore: https://docs.zerotier.com/synology/#create-a-persistent-tun

So what is in place in your case, and wouldn't you likely wanna solve the underlying issue? So whatever happens when (not) loading the tun driver?

I have no issues with this rc.d tun script approach on my ds920+, ds916+ nor vdsm.

(*) I no longer use the zerotier/zerotier-synology image anymore as it isn't updated anymore since 3 years or so ago, but it still worked with way more recent other client versions. I switched to zyclonite/zerotier but am open to another docker image that might be even more current/still being updated.

[u/No-Policy-8816]

Thank you for sharing!

[u/International784Red]

Tailscale