Permission denied when using bind mounts with rootless Docker and non-1000 UID

[panigrc]

When running Woodpecker CI in rootless Docker with a bind mount for /var/lib/woodpecker, the container fails to write to the SQLite database (woodpecker.sqlite) if the host user’s UID is not 1000.

My theory is that:

1. The Woodpecker image hardcodes the woodpecker user as UID 1000
2. In rootless Docker, the container runs under the host user’s UID (e.g., 1004).
3. The bind-mounted directory on the host is owned by the host user (e.g., 1004:1004), but the container’s /var/lib/woodpecker is owned by 1000:1000.
4. The container cannot chown the directory (non-root user), and the host cannot change the container’s internal ownership.

This creates a permission mismatch, causing Woodpecker to fail with error:

{"level":"error","time":"2026-07-02T14:44:21Z","message":"failed to setup store: could not migrate datastore: migration add-cron-field failed: attempt to write a readonly database: retry in 729.577424ms"}

compose.yml:

services:
  woodpecker-server:
    image: woodpeckerci/woodpecker-server:v3.16-alpine
    restart: unless-stopped
    user: "1004:1004"
    volumes:
      - ./docker:/var/lib/woodpecker
    environment:
      - WOODPECKER_HOST=${WOODPECKER_HOST}
      - WOODPECKER_ADMIN=${WOODPECKER_ADMIN}
      - WOODPECKER_GITEA=true
      - WOODPECKER_GITEA_URL=${WOODPECKER_GITEA_URL}
      - WOODPECKER_GITEA_CLIENT=${WOODPECKER_GITEA_CLIENT}
      - WOODPECKER_GITEA_SECRET=${WOODPECKER_GITEA_SECRET}
      - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
      - WOODPECKER_PLUGINS_PRIVILEGED=${WOODPECKER_PLUGINS_PRIVILEGED}

Environment:

• Host OS: Ubuntu 20.04
• Docker Rootless mode Version: 28.1.1
• Docker Compose: Version: v2.35.1

I also tested the following unsuccessfully:

1. Chown files 1000:1000
2. Remove the user directive from compose.yaml

Is there a recommended way to run Woodpecker in rootless Docker with non-1000 UIDs?

[panigrc]

I moved woodpecker to the 1000:1000 user, but I got still the same error, because it seems that the files are mounted using root which is expected according to the documentation https://docs.docker.com/engine/security/rootless/uid-gid-mapping/

This difference matters when setting file permissions on bind-mounted directories: in rootless mode, files owned by your host user appear as owned by root inside the container.

By changing user: "1000:1000" to user: "0:0" it works because it gives the container root permission, but I guess this is not the most secure way to do it.

[yudin-s]

That result matches the rootless Docker UID mapping behavior.

In rootless mode, container root is not host root: the daemon and containers run inside the rootless user's user namespace. For bind mounts, files owned by the host user can appear as owned by root inside the container. So if the Woodpecker process runs as container UID 1000, it may not be able to write a bind-mounted directory even when the host path is owned by your host UID 1004.

That also matches the Woodpecker image layout: the rootless server image creates /var/lib/woodpecker for the woodpecker user (1000:1000), while the documented compose example uses a Docker named volume for /var/lib/woodpecker, where the rootless daemon can manage the ownership inside its namespace.

The practical options are:

volumes:
  - woodpecker-server-data:/var/lib/woodpecker

volumes:
  woodpecker-server-data:

or, if you need to keep the bind mount:

user: "0:0"
volumes:
  - /your/host/path:/var/lib/woodpecker

In rootless Docker, user: "0:0" is root inside the container namespace and maps back to the unprivileged rootless user on the host. It is usually less risky than the same setting on a normal rootful Docker daemon, but you should still keep the host data directory permissions tight because that host user owns the data.

I would avoid user: "1004:1004" here unless you deliberately set up an idmapped/subuid layout where that UID is meaningful inside the container. Inside the container it is just UID 1004, not automatically "the host user".

So the cleanest fix is the named volume. The bind-mount fix is to run as 0:0 under the rootless daemon. If that resolves it, please mark the answer as accepted.