TS_STATE_DIR - permission denied

[melojms]

I'm trying to run tsidp using docker-compose, but I'm getting the permission error:

tsidp | 2025/11/02 10:13:17 ERROR failed to start tsnet server error="tsnet.Up: tsnet: logpolicy.Config.Save for /data/tailscaled.log.conf: open /data/tailscaled.log.conf.tmp397936848: permission denied"

My docker-compose.yml is the same that is in the repository README.
If I comment the TS_STATE_DIR environment var, the container starts without issues.

Any idea what the problem is?

[pmoffe]

Hey @melojms, use TSIDP_STATE_DIR and TSIDP_HOSTNAME. Referenced here: https://github.com/tailscale/tsidp?tab=readme-ov-file#docker-environment-variables

[melojms]

Hi @pmoffe
I don't think latest version is using TSIDP_STATE_DIR:

tsidp/scripts/docker/run.sh

Lines 6 to 8 in 335dc10

	if [ -n "$TS_STATE_DIR" ]; then
	ARGS="$ARGS -dir=$TS_STATE_DIR"
	fi

[angelbirth]

@melojms it worked for me when I chmod o+w the state dir. Maybe just a workaround, not a solution

[kblissett]

I'm seeing this same issue when running the docker compose file in the README on macOS 15.7.1 and Docker version 28.5.1, build e180ab8. This is the compose file for reference:

services:
  tsidp:
    container_name: tsidp
    image: ghcr.io/tailscale/tsidp:latest
    volumes:
      - tsidp-data:/data
    environment:
      - TAILSCALE_USE_WIP_CODE=1 # tsidp is experimental - needed while version <1.0.0
      - TS_STATE_DIR=/data # store persistent tsnet and tsidp state
      - TS_HOSTNAME=idp # Hostname on tailnet (becomes idp.your-tailnet.ts.net)
      - TSIDP_ENABLE_STS=1 # Enable OAuth token exchange
      # Optional: Tailscale auth key for automatic node registration
      # - TS_AUTHKEY=tskey-auth-xxxxx
volumes:
  tsidp-data:

[mostlygeek]

Hi,

Try this:

> docker-compose down 
> docker run --rm -v tsidp_tsidp-data:/data alpine:latest chown -R 1001:1001 /data
> docker-compose up

These assume you're using the example of the docker compose configuration. That's why the volume is named tsidp_tsidp-data.

The cause was we changed the user in the container to app with a UID of 1001 as part of our security review. Previously, tsidp ran as root within the container. The fix is to get the /data within the container writable by the app user.

[jaxxstorm]

We should switch to 65532 as the UID, see see distroless https://github.com/GoogleContainerTools/distroless/blob/aa83e4eb09c9da30bec7c789ab9a5272c11f583b/common/variables.bzl#L17-L18

We can then safely chown the directories on startup if we need to

[ted-allocate]

For those folks on Kubernetes and have their files on a PV, I added an initContainer to my deployment to fix the permissions on startup:

      initContainers:
        - name: fix-perms
          image: alpine:3.20
          command:
            - /bin/sh
            - -c
            - |
              echo "Fixing user permissions in /var/lib/tsidp..."
              chown -R 1001:1001 /var/lib/tsidp
              echo "Done."
          volumeMounts:
            - name: tsidp
              mountPath: /var/lib/tsidp