Latest docker version (as of 2023-09-01) fails to spawn worker #1691

New Issue

OVERLORD · 2026-02-05T01:30:12+03:00

OVERLORD commented

2026-02-05 01:30:12 +03:00

Originally created by @phormix on GitHub (Sep 6, 2023).

Subject of the issue

Docker version (1.29.2: latest, pulled from 2023-09-01) fails. Logs indicate an issue spawning worker threads per error (continual)

thread 'main' panicked at 'OS can't spawn worker thread: Operation not permitted (os error 1)', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.31.0/src/runtime/scheduler/multi_thread/worker.rs:447:13
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Deployment environment

Debian Bookworm with kernel 6.1.0-11-amd64

vaultwarden version: 1.29.2

Install method: Docker image
Clients used: Web vault, Android
Reverse proxy and version: Apache 2.4.57/debian
MySQL/MariaDB or PostgreSQL version: N/A (in docker image)
Other relevant details:

Steps to reproduce

docker container start vaultwarden

Expected behaviour

container normal startup

Actual behaviour

Thread failed due to error

Troubleshooting data

This error is repeated in the logs (per "docker logs vaultwarden")

thread 'main' panicked at 'OS can't spawn worker thread: Operation not permitted (os error 1)', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.31.0/src/runtime/scheduler/multi_thread/worker.rs:447:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Originally created by @phormix on GitHub (Sep 6, 2023).   ### Subject of the issue Docker version (1.29.2: latest, pulled from 2023-09-01) fails. Logs indicate an issue spawning worker threads per error (continual) thread 'main' panicked at 'OS can't spawn worker thread: Operation not permitted (os error 1)', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.31.0/src/runtime/scheduler/multi_thread/worker.rs:447:13 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ### Deployment environment Debian Bookworm with kernel 6.1.0-11-amd64     * vaultwarden version: 1.29.2  * Install method: Docker image * Clients used: Web vault, Android * Reverse proxy and version: Apache 2.4.57/debian * MySQL/MariaDB or PostgreSQL version: N/A (in docker image) * Other relevant details: ### Steps to reproduce docker container start vaultwarden ### Expected behaviour container normal startup ### Actual behaviour Thread failed due to error ### Troubleshooting data  This error is repeated in the logs (per "docker logs vaultwarden") ``` thread 'main' panicked at 'OS can't spawn worker thread: Operation not permitted (os error 1)', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.31.0/src/runtime/scheduler/multi_thread/worker.rs:447:13 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ```

OVERLORD closed this issue

2026-02-05 01:30:15 +03:00

OVERLORD commented

2026-02-05 01:30:21 +03:00

@stefan0xC commented on GitHub (Sep 6, 2023):

Can you tell us more about your setup? I.e. are you running docker on bare-metal or in a VPS (like a LXC container)?
Please also post the output of docker info.

@stefan0xC commented on GitHub (Sep 6, 2023): Can you tell us more about your setup? I.e. are you running docker on bare-metal or in a VPS (like a LXC container)? Please also post the output of `docker info`.

OVERLORD commented

2026-02-05 01:30:25 +03:00

@phormix commented on GitHub (Sep 6, 2023):

Debian 64-bit AMD VM (libvirtd/qemu) within a 64-bit Debian parent host

The "docker info" command shows
Server:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 3
Server Version: 19.03.12
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 6.1.0-11-amd64
Operating System: Debian GNU/Linux 12 (bookworm)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.824GiB
Name: vaultwarden
ID: SRE6:Z3TD:WRZU:JNG3:74DG:YBDK:3KIW:YMLG:RFPX:LGHB:LD6T:LHHU
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

Looks like it does start up after adding this to the docker run params
--security-opt="seccomp=unconfined"

This may be a rust issue as I found the above in another rust-related thread.
This may be related to this issue as well, though that user threw more privileges at the docker container rather than setting the above security option

@phormix commented on GitHub (Sep 6, 2023): Debian 64-bit AMD VM (libvirtd/qemu) within a 64-bit Debian parent host The "docker info" command shows Server: Containers: 1 Running: 1 Paused: 0 Stopped: 0 Images: 3 Server Version: 19.03.12 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd init version: fec3683 Security Options: apparmor seccomp Profile: default Kernel Version: 6.1.0-11-amd64 Operating System: Debian GNU/Linux 12 (bookworm) OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 3.824GiB Name: vaultwarden ID: SRE6:Z3TD:WRZU:JNG3:74DG:YBDK:3KIW:YMLG:RFPX:LGHB:LD6T:LHHU Docker Root Dir: /var/lib/docker Debug Mode: false Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false Looks like it does start up after adding this to the docker run params --security-opt="seccomp=unconfined" This may be a rust issue as I found the above in another rust-related thread. This may be related to [this issue](https://github.com/dani-garcia/vaultwarden/discussions/3850) as well, though that user threw more privileges at the docker container rather than setting the above security option

OVERLORD commented

2026-02-05 01:30:29 +03:00

@phormix commented on GitHub (Sep 6, 2023):

Will see if I can figure out a more granular seccomp profile later that allows stuff to work while maintaining a better level of security than just dumping it into unconfined, but that'll do in a pinch and is probably a better option than the gloves-off privileged=true

@phormix commented on GitHub (Sep 6, 2023): Will see if I can figure out a more granular seccomp profile later that allows stuff to work while maintaining a better level of security than just dumping it into unconfined, but that'll do in a pinch and is probably a better option than the gloves-off privileged=true

OVERLORD commented

2026-02-05 01:30:33 +03:00

@BlackDex commented on GitHub (Sep 6, 2023):

Your docker is very old.
See #3827

@BlackDex commented on GitHub (Sep 6, 2023): Your docker is very old. See #3827

OVERLORD commented

2026-02-05 01:30:36 +03:00

@BlackDex commented on GitHub (Sep 6, 2023):

Your docker version is even older than the default shipped with Debian Bookworm.

@BlackDex commented on GitHub (Sep 6, 2023): Your docker version is even older than the default shipped with Debian Bookworm. ![1000053370](https://github.com/dani-garcia/vaultwarden/assets/610450/dfaeaed2-0d6d-411e-9d1e-e830d8295ed9)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1691