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:
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:
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
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?
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:
and a mounted Docker socket:
Hermes enters an s6-overlay restart loop with:
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:
volumes:
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:
user: "10000:10000")group_add)/var/run/docker.sockIn 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:
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
Investigation
stage2-hook.sh correctly detects docker.sock GID:
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
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?