hermes - 💡(How to fix) Fix [Bug]: Regression in v0.15.1: non-root Docker + group_add (docker.sock GID) causes s6-overlay boot loop

Bug Description

Summary

Regression introduced between:

v2026.5.16 (v0.14.0) ✅ Works v2026.5.28 (v0.15.0) ❌ Broken

When running Hermes as a non-root Docker user with:

user: "10000:10000"

group_add:

• "1001"

and a mounted Docker socket:

• /var/run/docker.sock:/var/run/docker.sock

Hermes enters an s6-overlay restart loop with:

s6-applyuidgid: fatal: unable to set supplementary group list: Operation not permitted

Docker itself correctly applies the supplementary group.

The issue appears related to the new Docker socket group-management logic introduced in stage2-hook.sh.

Broken Versions

v2026.5.28 (v0.15.0) v2026.5.29 (v0.15.1)

Workaround

Rollback to:

v2026.5.16 (v0.14.0)

restores normal operation with the exact same compose configuration.

Related Issues

Possibly related: #16703 #15865 #14655 #32559 #12696

Steps to Reproduce

docker-compose:

user: "10000:10000"

group_add:

• "1001"

volumes:

• /var/run/docker.sock:/var/run/docker.sock

Docker socket:

stat -c '%g %U %G %a %n' /var/run/docker.sock

Output:

1001 root UNKNOWN 660 /var/run/docker.sock

Verification that Docker correctly injects the supplementary group:

docker run --rm
--user 10000:10000
--group-add 1001
alpine
id

Output:

uid=10000 gid=10000 groups=1001,10000

Expected Behavior

Hermes should successfully start when all of the following conditions are met:

• running as a non-root user (user: "10000:10000")
• using Docker supplementary groups (group_add)
• mounting /var/run/docker.sock
• the runtime user already belongs to the docker socket GID

In this configuration, Hermes should complete startup normally and the Docker backend should be usable.

The container should not enter an s6-overlay restart loop and should not fail with:

s6-applyuidgid: fatal: unable to set supplementary group list: Operation not permitted

Since the runtime user is already a member of the docker socket group, Hermes should detect that state and skip any unnecessary supplementary-group reconfiguration during startup.

Hermes should start successfully when the runtime user already belongs to the docker socket group.

Actual Behavior

Logs

[stage2] hermes already in group 1001 for /var/run/docker.sock

s6-applyuidgid: fatal: unable to set supplementary group list: Operation not permitted

Investigation

stage2-hook.sh correctly detects docker.sock GID:

[stage2] hermes already in group 1001 for /var/run/docker.sock

However startup still fails during subsequent s6 privilege handling.

The issue appears to occur after the Docker socket group support changes introduced in v0.15.0.

Affected Component

Configuration (config.yaml, .env, hermes setup)

Messaging Platform (if gateway-related)

No response

Debug Report

n/a (not started)

Operating System

Windows 11 + WSL2 ,Ubuntu 24.04.3 LTS (GNU/Linux 6.6.87.2-microsoft-standard-WSL2 x86_64)

Python Version

3.13.5

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR