Tailscale 1.50 + Tailnet Lock: machine has already been registered

[vampywiz17]

What is the issue?

When i restart my docker container (or recreate) it need to re-auth the client.

Steps to reproduce

• Authenticate
• stop docker container
• start again

Are there any recent changes that introduced the issue?

it working 1.48.2. After i update, not working. If i switch back to 1.48.2 image it working well.

OS

Linux

OS version

Docker (Alpine 3.18.3)

Tailscale version

1.50.0

Other software

No response

Bug report

No response

[ftasbasi]

Did you get an error like this:

boot: 2023/09/25 22:20:38 Running 'tailscale login'
2023/09/25 22:20:38 control: doLogin(regen=false, hasUrl=false)
2023/09/25 22:20:38 health("overall"): error: not in map poll
flag provided but not defined: -reset
USAGE
login [flags]...

I needed to revert back to previous version from v1.50.0 to make it work, maybe same issue.
@vampywiz17

[vampywiz17]

@ftasbasi

i see this:

2023/09/26 12:55:29 control: LoginInteractive -> regen=true
2023/09/26 12:55:29 [RATELIMIT] format("control: LoginInteractive -> regen=true")
2023/09/26 12:55:29 control: doLogin(regen=true, hasUrl=false)
2023/09/26 12:55:29 [RATELIMIT] format("control: doLogin(regen=%v, hasUrl=%v)")
2023/09/26 12:55:29 control: Generating a new nodekey.
2023/09/26 12:55:29 [RATELIMIT] format("control: Generating a new nodekey.")
2023/09/26 12:55:29 control: RegisterReq: onode= node=[mjgEp] fup=false nks=false
2023/09/26 12:55:29 [RATELIMIT] format("control: RegisterReq: onode=%v node=%v fup=%v nks=%v")
2023/09/26 12:55:30 Received error: register request: http 500: You have a locked tailnet and this machine has already been registered. Please either delete the machine from the admin console and retry, or switch back to the profile and reauth. See: https://tailsc
2023/09/26 12:55:30 [RATELIMIT] format("Received error: %v")

But if switched back to 1.48.2, working... (and not need to re-add the client)
If i go inside the container and put tailscale status it say that logoff. if i delete the client, re-add it, it working until not stop the container.

[DentonGentry]

Received error: register request: http 500: You have a locked tailnet and this machine has already been registered. Please either delete the machine from the admin console and retry, or switch back to the profile and reauth. See: https://tailsc

Do you use Tailnet Lock?

[DentonGentry]

@ftasbasi

flag provided but not defined: -reset

Was tailscale login -reset being run? And it worked in 1.48?

[vampywiz17]

Received error: register request: http 500: You have a locked tailnet and this machine has already been registered. Please either delete the machine from the admin console and retry, or switch back to the profile and reauth. See: https://tailsc

Do you use Tailnet Lock?

Yes, i use it. But in 1.48.2, it no problem.

[DentonGentry]

Yes, i use it. But in 1.48.2, it no problem.

I understand that 1.48.2 worked in this environment, but that doesn't really help to identify the root cause.

The template asks for a tailscale bugreport because otherwise we have very little information to go on, and I have to ask in order to have a chance of diagnosing a problem.

A tailscale bugreport even from another node would let us identify which tailnet and be able to look up settings.

[DentonGentry]

machine has already been registered

The container has persistent storage mounted at /var/lib/tailscale? So /var/lib/tailscale/tailscaled.state survives a reboot?

[ftasbasi]

@ftasbasi

flag provided but not defined: -reset

Was tailscale login -reset being run? And it worked in 1.48?

Actually, I was running tailscale with following parameters:

--accept-routes --reset

and the above error was throwing out.

the following start cmd seems to be used:

Program starting: v1.48.2-tab970fe55, Go 1.21.0: []string{"tailscaled", "--socket=/tmp/tailscaled.sock", "--state=kube:xxx", "--statedir=/xxxx"

[DentonGentry]

@ftasbasi

tailscale login --reset has never worked, the login subcommand does not have a --reset argument.
tailscale up --reset does work, and works in 1.50.0 as well from testing here.

What was the full command you were running in 1.50.0? tailscale login --accept-routes --reset ?
That same tailscale login --accept-routes --reset works in 1.48.2?

[ftasbasi]

@DentonGentry It was 'tailscale up --accept-routes --reset' but it was throwing error as 'tailscale login -reset'

[DentonGentry]

@ftasbasi at this point I'd ask to open a new bug. Testing with 1.50.0 just now, tailscale up -accept-routes -reset does work for me. Something more must be involved somehow.

[vampywiz17]

@DentonGentry

problematic client (1.50.0): BUG-395825eabc37cf549a08c00c5542a0edfda11fe17b368faa036c81ea42c4d8dd-20230926134234Z-f996ca61994d2f2f

other working client (same tailnet): BUG-fa74da4a4c997835dfeb8507c57573227ad065c546066ed015690eeb3059b061-20230926134417Z-a582954e382f1b0a

Hope it help.

The container has persistent storage mounted at /var/lib/tailscale? So /var/lib/tailscale/tailscaled.state survives a reboot?

Yes, it persisntent, here my yaml:

version: '3.3'
services:
    tailscale:
        container_name: tailscaled
        volumes:
            - '/var/lib:/var/lib'
            - '/dev/net/tun:/dev/net/tun'
            - '/var/run/tailscale/:/var/run/tailscale/'
        network_mode: host

        environment:
            - TS_AUTHKEY=$TS_AUTHKEY
            - TS_SOCKET=/var/run/tailscale/tailscaled.sock
            - TS_ROUTES=192.168.31.0/24
            - TS_STATE_DIR=/var/lib/tailscale
        image: tailscale/tailscale
        restart: unless-stopped

    derper:
        environment:
            - DERP_DOMAIN=**************.duckdns.org
            - DERP_ADDR=:80

            - DERP_VERIFY_CLIENTS=true
        depends_on:
            - tailscale
        ports:
            - '16666:80'
            - '16667:3478/udp'
        volumes:
            - '/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock'
        image: fredliang/derper
        restart: unless-stopped

[cyberworm-uk]

I've similarly had to revert back to 1.48, I'm also using tailnet lock. Also running inside a container. There is a volume mounted to store tailscaled.state and had no issues until upgrading to 1.50.

After upgrading, the container prompted for the machine to be added anew to the existing tailnet.

To try and resolve the issue, I removed the existing machine and re-added it and normal service resumed. However, any time that the container was restarted it would once again provide me with a link to add the machine a new rather than use the existing one.

I removed the existing container volume that stored existing tailscaled.state, to provide a fully clean slate, and repeated the process and saw the same results.

Container is run under podman rather than docker but with the same results others have reported, e.g.

podman run -d \
  --env TS_USERSPACE=false \
  --env TS_STATE_DIR=/var/lib/tailscale \
  --env TS_SOCKET=/var/run/tailscale/tailscaled.sock \
  --volume tailscaled-state:/var/lib/tailscale \
  --device /dev/net/tun \
  --network host \
  docker.io/tailscale/tailscale

However, an iOS and Synology device on the same tailnet updated to 1.50 without issue, the only impacted devices appear to be containers.

Also of note, when downgrading to 1.48 the machine created under a 1.50 container allows it to start the 1.50 profile, so it appears to be an issue with loading rather than saving.

[vampywiz17]

Exactly. I also Update a native linux client and not affect any problem. Only with container.

[smelllllllllll]

I am experiencing the exact same issue, I've had to revert back to 1.48.2

[maisem]

This looks like a regression in cmd/containerboot. The mitigation is to set TS_AUTH_ONCE=true as an env var to the container.

[cyberworm-uk]

Thanks. Looking at the documentation, it appears this environment variable should always have been required for my setup but hadn't been previously. Setting the noted environment variable TS_AUTH_ONCE=true allows 1.50 to work as expected.

[vampywiz17]

It fix the problem! I close the issue.

[DentonGentry]

Unstable release 1.51.25 contains a fix for this. If able to run an unstable release, could you try it?

We can incorporate the same fix into a 1.50.1 release.

[DentonGentry]

This should be resolved in 1.50.1, released earlier today.