fix(docker): accept PUID/PGID as aliases for HERMES_UID/HERMES_GID#25872
Closed
konsisumer wants to merge 1 commit into
Closed
fix(docker): accept PUID/PGID as aliases for HERMES_UID/HERMES_GID#25872konsisumer wants to merge 1 commit into
konsisumer wants to merge 1 commit into
Conversation
NAS platforms (UGOS, Synology, unRAID) bind-mount /opt/data from a host directory owned by the user's own UID and expect the LinuxServer.io PUID/PGID convention. The entrypoint only read HERMES_UID/HERMES_GID, so PUID/PGID were silently ignored, the gosu drop landed on UID 10000, and the runtime could not read the bind-mounted volume. Resolve HERMES_UID/HERMES_GID from PUID/PGID when unset; the existing HERMES_UID/HERMES_GID vars still take precedence when both are set. Fixes NousResearch#15290
Collaborator
|
Thanks @konsisumer! Your fix shipped as |
pull Bot
pushed a commit
to TKaxv-7S/hermes-agent
that referenced
this pull request
May 29, 2026
…ousResearch#25872) (NousResearch#34401) Salvages NousResearch#25872 by @konsisumer against current main. NAS users (UGOS, Synology, unRAID) expect the LinuxServer.io PUID/PGID convention and bind-mount /opt/data from a host directory owned by their own UID. Without this alias those vars are silently ignored and the s6-setuidgid drop to UID 10000 leaves the runtime unable to read the volume. HERMES_UID/HERMES_GID still take precedence when both are set. The original PR targeted docker/entrypoint.sh, which is now a 27-line deprecation shim under s6-overlay (the May 2026 rework moved all bootstrap logic to docker/stage2-hook.sh, installed as /etc/cont-init.d/01-hermes-setup). Re-applied the same 2-line alias resolution at the equivalent spot in stage2-hook.sh just before the existing UID/GID remap block. Test was retargeted at docker/stage2-hook.sh; docs hunk adapted to current main's wording ("stage2 hook" + s6-setuidgid, not the obsolete "entrypoint drops via gosu") with the NAS bind-mount example preserved verbatim. Test-first regression verification: reverted just docker/stage2-hook.sh to origin/main and re-ran the new tests. Result: FAILED test_stage2_hook_resolves_puid_pgid_aliases FAILED test_puid_pgid_populate_hermes_uid_gid AssertionError: assert ':' == '1000:10' That's the exact bug shape — PUID=1000 PGID=10 silently ignored, HERMES_UID/HERMES_GID stay empty. With the salvage applied, all 4 tests pass. Closes NousResearch#25872 Co-authored-by: konsisumer <11262660+konsisumer@users.noreply.github.com>
KKT-OPT
pushed a commit
to KKT-OPT/hermes-agent
that referenced
this pull request
May 31, 2026
…ousResearch#25872) (NousResearch#34401) Salvages NousResearch#25872 by @konsisumer against current main. NAS users (UGOS, Synology, unRAID) expect the LinuxServer.io PUID/PGID convention and bind-mount /opt/data from a host directory owned by their own UID. Without this alias those vars are silently ignored and the s6-setuidgid drop to UID 10000 leaves the runtime unable to read the volume. HERMES_UID/HERMES_GID still take precedence when both are set. The original PR targeted docker/entrypoint.sh, which is now a 27-line deprecation shim under s6-overlay (the May 2026 rework moved all bootstrap logic to docker/stage2-hook.sh, installed as /etc/cont-init.d/01-hermes-setup). Re-applied the same 2-line alias resolution at the equivalent spot in stage2-hook.sh just before the existing UID/GID remap block. Test was retargeted at docker/stage2-hook.sh; docs hunk adapted to current main's wording ("stage2 hook" + s6-setuidgid, not the obsolete "entrypoint drops via gosu") with the NAS bind-mount example preserved verbatim. Test-first regression verification: reverted just docker/stage2-hook.sh to origin/main and re-ran the new tests. Result: FAILED test_stage2_hook_resolves_puid_pgid_aliases FAILED test_puid_pgid_populate_hermes_uid_gid AssertionError: assert ':' == '1000:10' That's the exact bug shape — PUID=1000 PGID=10 silently ignored, HERMES_UID/HERMES_GID stay empty. With the salvage applied, all 4 tests pass. Closes NousResearch#25872 Co-authored-by: konsisumer <11262660+konsisumer@users.noreply.github.com>
hechuyi
pushed a commit
to hechuyi/hermes-agent
that referenced
this pull request
Jun 6, 2026
…ousResearch#25872) (NousResearch#34401) Salvages NousResearch#25872 by @konsisumer against current main. NAS users (UGOS, Synology, unRAID) expect the LinuxServer.io PUID/PGID convention and bind-mount /opt/data from a host directory owned by their own UID. Without this alias those vars are silently ignored and the s6-setuidgid drop to UID 10000 leaves the runtime unable to read the volume. HERMES_UID/HERMES_GID still take precedence when both are set. The original PR targeted docker/entrypoint.sh, which is now a 27-line deprecation shim under s6-overlay (the May 2026 rework moved all bootstrap logic to docker/stage2-hook.sh, installed as /etc/cont-init.d/01-hermes-setup). Re-applied the same 2-line alias resolution at the equivalent spot in stage2-hook.sh just before the existing UID/GID remap block. Test was retargeted at docker/stage2-hook.sh; docs hunk adapted to current main's wording ("stage2 hook" + s6-setuidgid, not the obsolete "entrypoint drops via gosu") with the NAS bind-mount example preserved verbatim. Test-first regression verification: reverted just docker/stage2-hook.sh to origin/main and re-ran the new tests. Result: FAILED test_stage2_hook_resolves_puid_pgid_aliases FAILED test_puid_pgid_populate_hermes_uid_gid AssertionError: assert ':' == '1000:10' That's the exact bug shape — PUID=1000 PGID=10 silently ignored, HERMES_UID/HERMES_GID stay empty. With the salvage applied, all 4 tests pass. Closes NousResearch#25872 Co-authored-by: konsisumer <11262660+konsisumer@users.noreply.github.com> (cherry picked from commit 4808321)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed and why
NAS users on #15290 (UGreen UGOS Pro, plus Synology/unRAID reports) bind-mount
/opt/datafrom a host directory owned by their own UID. They setPUID/PGID— the LinuxServer.io convention NAS ecosystems expect — butdocker/entrypoint.shonly readHERMES_UID/HERMES_GID, so those vars were silently ignored. The gosu privilege drop then landed on the defaulthermesuser (UID 10000), which cannot read a bind mount owned by the host user, producing the persistent[Errno 13] Permission denied: '/opt/data/config.yaml'.The entrypoint now resolves
HERMES_UID/HERMES_GIDfromPUID/PGIDwhen unset, so passingPUID/PGIDmakes the runtime drop to the host UID that already owns the bind mount.HERMES_UID/HERMES_GIDstill take precedence when both are set, so existing deployments are unaffected.Per the reporter's 2026-05-14 diagnostics: a Docker named volume works while a NAS bind mount does not, and
PUID=1000/PGID=10were confirmed ignored by the current:latestimage — running the container as the host UID is the fix that lets bind mounts work without host-sidechownloops. The troubleshooting docs inwebsite/docs/user-guide/docker.mdnow document the alias and the NAS bind-mount pattern.How to test
pytest tests/tools/test_entrypoint_puid_pgid.py -q— new contract test covering PUID/PGID alias resolution andHERMES_UID/HERMES_GIDprecedence.docker run -e PUID=1000 -e PGID=10 -v /host/dir:/opt/data nousresearch/hermes-agent gateway runagainst a bind mount owned by host UID 1000 — the entrypoint logsChanging hermes UID to 1000and the runtime can read/writeconfig.yamlwithout a host-sidechown.What platforms tested on
pytest tests/tools/test_entrypoint_puid_pgid.py(4 passed) plus the existingtests/tools/test_docker*andtest_dockerfile_*suites (30 passed);bash -n docker/entrypoint.shclean.Addressing maintainer feedback
@alt-glitch flagged this as related to #13731 (CLOSED — duplicate of #15832) with the workaround
--user 0:0. #13731 was fixed by commit14c9f7272, which removedUSER hermesfrom the Dockerfile so the entrypoint runs as root. The reporter's diagnostics confirm they are on a post-fix:latestimage, and that--user 0:0does not resolve their case: the entrypoint correctly detects container-root and drops to UID 10000 by design, which still mismatches the host-owned bind mount. ThePUID/PGIDalias addresses the remaining gap — it lets NAS users target the host UID directly instead of relying on achownof a bind mount the host filesystem may reject.Fixes #15290