fix: chown root-owned files in HERMES_HOME on startup#35098
Closed
x1am1 wants to merge 1 commit into
Closed
Conversation
When docker exec -u root creates or modifies files directly in $HERMES_HOME (gateway.lock, state.db, auth.json, etc.), they become root-owned. The hermes user (uid 10000) then gets PermissionError on next startup, causing a gateway restart loop. The existing chown logic only covers specific subdirectories (cron, sessions, logs, etc.) but not root-level files. We can't chown -R the whole directory (NousResearch#19788 — host-mounted bind may contain unrelated user files), but chowning individual root-owned files is safe. Add a find command that chowns all root-owned regular files in the HERMES_HOME root directory to hermes. This runs unconditionally on every container start, catching any files left behind by root operations.
benbarclay
added a commit
that referenced
this pull request
Jun 1, 2026
The targeted data-volume chown in stage2-hook.sh only covers hermes-owned *subdirectories*; loose state files living directly under $HERMES_HOME (auth.json, state.db, gateway.lock, gateway_state.json, …) are missed. When created or rewritten by `docker exec <container> hermes …` (root unless `-u` is passed) they land root-owned, and the unprivileged hermes runtime then hits PermissionError on next startup, producing a gateway restart loop. Fix: reset ownership of an explicit allowlist of hermes-owned top-level files on every boot. The list mirrors the top-level file entries of hermes_cli.profile_distribution.USER_OWNED_EXCLUDE plus the runtime lock files. This uses a targeted allowlist rather than the originally-proposed blanket `find $HERMES_HOME -maxdepth 1 -user root` sweep, preserving the targeted-ownership contract from #19788 / PR #19795: a bind-mounted $HERMES_HOME may contain host-owned files Hermes does not manage, and those must never be chowned. Verified end-to-end: allowlisted root-owned files are reset to hermes on restart while a non-allowlisted host file keeps its root ownership. Co-authored-by: x1am1 <2663402852@qq.com>
Collaborator
|
Thanks for catching this @x1am1 — the bug is real: top-level state files ( I've opened #36236 as a salvage that fixes the same bug while keeping your authorship ( Verified end-to-end: allowlisted root-owned files get reset to hermes on restart, while a non-allowlisted host file keeps its root ownership. Closing this in favor of #36236 — really appreciate the report and the fix. |
benbarclay
added a commit
that referenced
this pull request
Jun 1, 2026
#36236) The targeted data-volume chown in stage2-hook.sh only covers hermes-owned *subdirectories*; loose state files living directly under $HERMES_HOME (auth.json, state.db, gateway.lock, gateway_state.json, …) are missed. When created or rewritten by `docker exec <container> hermes …` (root unless `-u` is passed) they land root-owned, and the unprivileged hermes runtime then hits PermissionError on next startup, producing a gateway restart loop. Fix: reset ownership of an explicit allowlist of hermes-owned top-level files on every boot. The list mirrors the top-level file entries of hermes_cli.profile_distribution.USER_OWNED_EXCLUDE plus the runtime lock files. This uses a targeted allowlist rather than the originally-proposed blanket `find $HERMES_HOME -maxdepth 1 -user root` sweep, preserving the targeted-ownership contract from #19788 / PR #19795: a bind-mounted $HERMES_HOME may contain host-owned files Hermes does not manage, and those must never be chowned. Verified end-to-end: allowlisted root-owned files are reset to hermes on restart while a non-allowlisted host file keeps its root ownership. Co-authored-by: x1am1 <2663402852@qq.com>
JoeKowal
pushed a commit
to JoeKowal/hermes-agent
that referenced
this pull request
Jun 4, 2026
…search#35098) (NousResearch#36236) The targeted data-volume chown in stage2-hook.sh only covers hermes-owned *subdirectories*; loose state files living directly under $HERMES_HOME (auth.json, state.db, gateway.lock, gateway_state.json, …) are missed. When created or rewritten by `docker exec <container> hermes …` (root unless `-u` is passed) they land root-owned, and the unprivileged hermes runtime then hits PermissionError on next startup, producing a gateway restart loop. Fix: reset ownership of an explicit allowlist of hermes-owned top-level files on every boot. The list mirrors the top-level file entries of hermes_cli.profile_distribution.USER_OWNED_EXCLUDE plus the runtime lock files. This uses a targeted allowlist rather than the originally-proposed blanket `find $HERMES_HOME -maxdepth 1 -user root` sweep, preserving the targeted-ownership contract from NousResearch#19788 / PR NousResearch#19795: a bind-mounted $HERMES_HOME may contain host-owned files Hermes does not manage, and those must never be chowned. Verified end-to-end: allowlisted root-owned files are reset to hermes on restart while a non-allowlisted host file keeps its root ownership. Co-authored-by: x1am1 <2663402852@qq.com>
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.
Problem
When
docker exec -u rootcreates or modifies files directly in$HERMES_HOME(e.g.gateway.lock,state.db,auth.json), they become root-owned. The hermes user (uid 10000) then getsPermissionErroron next startup, causing a gateway restart loop.Root Cause
The existing chown logic in
stage2-hook.shonly covers specific subdirectories (cron, sessions, logs, etc.) but not root-level files.Fix
Add a targeted
findcommand that chowns all root-owned regular files in$HERMES_HOMEroot to hermes:-maxdepth 1— only root-level files, not recursive-user root— only files owned by root-type f— files only, not directoriesSupersedes #35078.