When you bring the tailscale docker container up and look at the docker logs do you see any errors?

Nothing obvious. The only thing I noticed was

2024/01/03 11:52:32 health("router"): error: setting up filter/ts-input: running [/sbin/ip6tables -t filter -N ts-input --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.8.9 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)`

which I resolved by adding `TS_DEBUG_FIREWALL_MODE=auto` (and the firewall mode changed to `nft-inuse` from `ipt-default`).

Worth mentioning that after setting this variable what apparently helped tailscaled to perform `wgengine: Reconfig: configuring DNS` and do its DNS thing and it look ok'ish now (I don't have a way how to check as the subnet is already exposed after running the manual command I mentioned earlier), yet I'd still expect the device to register automatically using the provided authky as this is likely happening in an earlier stage.

;tldr not sure if the firewall mode was blocking the login and other tasks as these worked fine when issued manually inside the container.

Here's the docker-compose I use with Portainer-Stacks, which has generally worked quite well for me across numerous Docker hosts:

version: '3.9'
services:
  tailscale:
    image: tailscale/tailscale:${TAG}
    container_name: tailscaled
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
      #- TS_HOSTNAME=${TS_HOSTNAME} # Usually not necessary for your hostname to be the same name on the tailscale network
      #- TS_AUTHKEY=${TS_AUTHKEY} # Generate auth keys here: https://login.tailscale.com/admin/settings/keys
      #- TS_AUTH_ONCE=${TS_AUTH_ONCE}
      - TS_ROUTES=${TS_ROUTES} # Creates a subnet router for Tailscale. Use your subnet's CIDR in the form: 192.168.1.0/24
      - TS_ACCEPT_DNS=${TS_ACCEPT_DNS} # Set to false for Pi-hole Docker setups
      - TS_SOCKET=${TS_SOCKET}
      - TS_EXTRA_ARGS=${TS_EXTRA_ARGS} # Add any other supported arguments in the docker commandline style: e.g. --advertise-exit-node
      - TS_STATE_DIR=${TS_STATE_DIR} # Required to create a persistent container state that will survive reboots
    volumes:
      - ${HOST_DIR}:/var/lib # Creates a tailscale directory under HOST_DIR for persistence
      - /dev/net/tun:/dev/net/tun
    network_mode: host
    restart: unless-stopped

And, some sample env variables

TAG=latest
TS_ROUTES=192.168.1.0/24
TS_ACCEPT_DNS=false
TS_SOCKET=/var/run/tailscale/tailscaled.sock
TS_EXTRA_ARGS=--advertise-exit-node
TS_STATE_DIR=/var/lib/tailscale
HOST_DIR=/data

A few notes:

I've found that not using TS_AUTHKEY is more convenient for me. Simply look in the Portainer-Log for the container after starting it, and the usual auth link can be found there, which can be copied and pasted into your browser.

My example is from a Pi-hole DNS server, which has been setup to also be a subnet router and exit node. TS_ACCEPT_DNS=false, is required for this Pi-hole example, but normally would not be used.

I would suggest removing privileged:, PUID=, GUID= and command: as none of these are required, and could have unintended consequences.

Hi, would you know which env variables should I use for --snat-subnet-routes=false?

I tried running it with TS_EXTRA_ARGS=--snat-subnet-routes=false and also docker exec tailscale tailscale up --snat-subnet-routes=false but nothing is happening.

You're not alone, I have this issue as well. Experimenting in the last 48 hours, I can also see that a docker compose is passing environment variables such as TS_AUTHKEY to the current tailscale/tailscale latest container and the container is stuck waiting on auth as if it's not looking at this (or any other variable provided).

Edit : don't execute the daemon direct. See other post

Funny stuff.... I was migrating my tailscale container to a different server and hit exactly the same issue as the one I reported. This time, I made sure I put `TS_DEBUG_FIREWALL_MODE=auto` in so I am sure the container wouldn't interrupt the init phase because of some dumb network config issue but nope - `TS_AUTHKEY` and also `TS_ROUTES` were simply happily ignored even this time and I had to exec to the container and run the respective commands manually...

command: tailscaled

Remove this. You want the docker to execute the wrapper it's built with - that's what pulls the env var's into a CLI line - you're calling the daemon direct which will ignore the env vars.

Made the same mistake :P

Ah makes sense! I was under impression that `tailscaled` reads the env variables of the container. Thanks for head up! :)

This, thank you. I was with the same problem I got the docker run command from the original doc and it was not working like the OP, once I removed the command from compose the exitnode and subnets were there!

thanks!