What's Going Wrong?
I am attempting to deploy Hermes Agent on a UGreen DX4600 NAS (running UGOS Pro, a Linux-based NAS OS) using Docker. I am using the official image nousresearch/hermes-agent:latest.
The core issue is that even though the container has successfully created the config.yaml file during the setup process, it immediately fails to read it or modify it afterwards, throwing a Permission denied error. This happens despite the container running as root and having a volume mapped to the host filesystem.
Curiously, other AI agent Docker applications (e.g., agentscope-qwenpaw) work perfectly with identical volume mapping settings on the same hardware, suggesting that Hermes' specific method of writing or rotating configuration files might be conflicting with the host's ACL/filesystem permissions.
Steps Taken
- Created a host directory for persistent data (mapped to
/opt/data in the container).
- Started the container in interactive mode (
-it).
- Ran the setup wizard:
/opt/hermes/.venv/bin/hermes setup.
- Successfully completed the interactive configuration (API keys, etc.).
- As soon as the wizard attempts to save or the gateway tries to reload the config, the error triggers.
Installation Method
Docker
Operating System
Debian 12
Python Version
No response
Hermes Version
No response
Debug Report
Full Error Output
Warning: Failed to load config: [Errno 13] Permission denied: '/opt/data/config.yaml'
What I've Already Tried
- Privileged Mode: Enabled "Privileged Mode" in the Docker settings, but the error persists.
- Manual Permission Change: Attempted
chmod 777 /opt/data/config.yaml inside the container terminal. Even with root privileges inside the container, the operation was either ineffective or blocked by the host's underlying filesystem security.
- File Recreation: Deleted
config.yaml and reran the setup; the error reappears the moment the new file is generated.
- Host-side Edit: Edited and saved the file via the NAS host GUI to force a reset of the owner/ACLs, but the container still cannot maintain access after its own subsequent write operations.
- Environment Variables (PUID/PGID): Attempted to pass
PUID=1000 / PGID=10 (the NAS user ID) and PUID=0 / PGID=0 (Root) as environment variables to the container. Neither configuration resolved the permission conflict, suggesting the image may lack native support for these variables to manage filesystem access.
- Comparison: Confirmed that other Docker containers using the same volume path can read/write without issue, which points to a potential issue in the atomic-write or file-rotation logic used by Hermes Agent's config manager.
What's Going Wrong?
I am attempting to deploy Hermes Agent on a UGreen DX4600 NAS (running UGOS Pro, a Linux-based NAS OS) using Docker. I am using the official image
nousresearch/hermes-agent:latest.The core issue is that even though the container has successfully created the
config.yamlfile during the setup process, it immediately fails to read it or modify it afterwards, throwing aPermission deniederror. This happens despite the container running as root and having a volume mapped to the host filesystem.Curiously, other AI agent Docker applications (e.g.,
agentscope-qwenpaw) work perfectly with identical volume mapping settings on the same hardware, suggesting that Hermes' specific method of writing or rotating configuration files might be conflicting with the host's ACL/filesystem permissions.Steps Taken
/opt/datain the container).-it)./opt/hermes/.venv/bin/hermes setup.Installation Method
Docker
Operating System
Debian 12
Python Version
No response
Hermes Version
No response
Debug Report
Full Error Output
Warning: Failed to load config: [Errno 13] Permission denied: '/opt/data/config.yaml'What I've Already Tried
chmod 777 /opt/data/config.yamlinside the container terminal. Even with root privileges inside the container, the operation was either ineffective or blocked by the host's underlying filesystem security.config.yamland reran the setup; the error reappears the moment the new file is generated.PUID=1000 / PGID=10(the NAS user ID) andPUID=0 / PGID=0(Root) as environment variables to the container. Neither configuration resolved the permission conflict, suggesting the image may lack native support for these variables to manage filesystem access.