medzin

My mistake, I apologize. If I recall correctly, Hermes refuses to run as root and will fall back to UID 10000 regardless of your configuration. Therefore, the only workaround for now is to use a custom Docker image instead of the official one, as outlined in this comment: https://github.com/NousResearch/hermes-agent/issues/49569#issuecomment-4760137144

Yes, this is a known issue with the Hermes Agent Docker image when running the container as a non-root user. The only workaound it so run the conainer as a root. Similar GitHub issues: https://github.com/NousResearch/hermes-agent/issues/50981 https://github.com/NousResearch/hermes-agent/issues/49569

@Braulio Dias Ribeiro This looks like a recently fixed Hermes Docker issue rather than an Unraid template path issue. Hermes Docker stores config and secrets in /opt/data, and the current image correctly loads /opt/data/.env. The bug was that s6-overlay could drop HERMES_HOME before gateway run, causing Hermes to look in the wrong location. Upstream fix: https://github.com/NousResearch/hermes-agent/pull/32412 Related issue: https://github.com/NousResearch/hermes-agent/issues/33004 I validated the current nousresearch/hermes-agent:latest image and confirmed: - HERMES_HOME=/opt/data - /opt/data/.env is loaded - FIRECRAWL_API_URL becomes visible to gateway.run - /opt/hermes/.env does not need to exist Please force-update/pull the latest Hermes image and recreate/start the container with the same appdata path. If the issue still happens after updating, please share the image digest/version and container logs. Hermes is also moving very quickly right now, so Docker behavior can change between image builds. If something looks inconsistent with the docs, the first thing to try is usually pulling the latest image and recreating the container while keeping the same appdata path.

Hi @ELP1! The path you used is correct for this template. However, recent n8n versions added a security restriction for local file access. Starting with n8n 2.0, N8N_RESTRICT_FILE_ACCESS_TO defaults to ~/.n8n-files, so the Read/Write Files from Disk node will not be allowed to read /data/... unless you explicitly allow it. See the official n8n docs: https://docs.n8n.io/2-0-breaking-changes/#set-default-value-for-n8n_restrict_file_access_to https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile/#file-locations To use files from the appdata mount, add this variable to the container: N8N_RESTRICT_FILE_ACCESS_TO=/dataThen restart the container and try /data/folder/*.pdf again.

Thanks for the reports - I've tracked down both issues and pushed a template update. If you reinstall/force-update the template from Community Apps you'll get the new defaults; existing installs need a couple of one-time fixes below. Quick background on what was going wrong The Hermes image only accepts a runtime UID/GID of 1000 or higher. The template was shipping Unraid's usual 99 / 100, which the image silently rejects - so it fell back to UID 10000 while your appdata stayed owned by 99:100. That mismatch is what caused PermissionError: [Errno 13] ... /opt/data/pairing/telegram-approved.json. The dashboard, when bound to 0.0.0.0 (needed for LAN access), turns on an OAuth login gate that has no provider configured in the self-hosted image - so it refuses to start and nothing listens on :9119. (Full technical write-up / upstream bug: https://github.com/NousResearch/hermes-agent/issues/38070) Fix 1 - Telegram permission error Stop the container. On the Unraid host (terminal), fix ownership of the appdata folder so it matches the runtime user: chown -R 10000:10000 /mnt/cache/appdata/hermes-agent The pairing subfolder is the one that actually breaks, so make sure the -R covers it. Make sure HERMES_UID / HERMES_GID are 10000 (the new template default). Leave them at 10000 unless you have a specific host user ≥1000 you want to match. Start the container. Also - when configuring Telegram, don't run /opt/hermes/.venv/bin/hermes setup from the console. Calling that path directly runs as root and writes root-owned files into the volume, which re-breaks pairing. Use the supported wrapper instead, which drops to the right user automatically: docker exec Hermes-Agent hermes setup (Or just set TELEGRAM_BOT_TOKEN and TELEGRAM_ALLOWED_USERS in the template - no console setup needed.) Fix 2 - WebUI won't open on :9119 The updated template adds a new variable, HERMES_DASHBOARD_INSECURE=1, which lets the dashboard bind on the LAN. If you're on the old template, add it manually (Add another Variable → key HERMES_DASHBOARD_INSECURE, value 1). ⚠️ Heads-up: with this on, the dashboard has no authentication - anyone on your network who can reach http://<ip>:9119 has full control. That's fine on a trusted home LAN, but do not port-forward it to the internet. If you need remote access, put it behind a reverse proxy with auth or a VPN/Tailscale. After applying both, the bot should accept messages again and the WebUI should load. Let me know if anything's still off and I'll dig in.

This is the support thread for the OpenClaw Unraid Docker template. Template: https://raw.githubusercontent.com/medzin/docker-templates/main/medzin/openclaw.xml OpenClaw is a self-hosted AI assistant gateway. This template runs the medzin/openclaw Docker image, which is based on the official OpenClaw container and adds Unraid-friendly UID/GID handling for persistent appdata permissions. Quick SetupDuring container installation, set OPENCLAW_GATEWAY_TOKEN in the Unraid template. Use a long random value. Then start the container, open the Unraid container console, and run: gosu node openclaw onboard --mode local --no-install-daemonOfficial DocsOpenClaw: https://docs.openclaw.ai/ Docker: https://docs.openclaw.ai/install/docker Gateway: https://docs.openclaw.ai/cli/gateway Configuration: https://docs.openclaw.ai/gateway/configuration

Thanks for the follow-up. This looks like a Docker/runtime limitation rather than something wrong with your setup. The Unraid template runs the official Hermes Docker image. The persistent appdata path is /opt/data, but the application itself lives under /opt/hermes inside the container image. Because of that, I would avoid using the WebUI self-update flow for this Docker template. If the update modifies files under /opt/hermes, those changes are not part of appdata and may not survive container recreation/image updates. Also, restarting the gateway from inside Hermes can stop the foreground gateway process, which makes Docker think the container exited. For Unraid, the safer update path is: Update the Docker image from Unraid. Restart the container from the Unraid Docker page. Run setup/migration commands again only if the official Hermes docs say they are needed.

Thanks for reporting this. That helped identify the actual issue. The container console runs commands as root, so the setup flow can create or update files with root:root ownership. Restarting the gateway from inside Hermes is not enough in that case, because it does not re-run the container entrypoint. I updated the main post to make this clearer: after running the setup commands, restart the whole container from the Unraid Docker page. That lets the entrypoint apply the configured HERMES_UID / HERMES_GID ownership again. The template defaults are HERMES_UID=99 and HERMES_GID=100, so a manual chown 99:99 should not normally be needed with the updated instructions.

This is the support thread for the Hermes Agent Unraid Docker template. Template: https://raw.githubusercontent.com/medzin/docker-templates/main/medzin/hermes-agent.xml Hermes Agent is a self-improving AI agent by Nous Research. This template runs the official nousresearch/hermes-agent container in gateway mode with the dashboard enabled and API server disabled by default. Quick SetupAfter installing the container, open the Unraid container console and run: /opt/hermes/.venv/bin/hermes setupAfter setup completes, restart the container from the Unraid Docker page. This container restart is required even if setup already restarts the gateway. The Unraid console runs as root, so setup may create config files owned by root:root. Restarting the container lets the Docker entrypoint apply the configured HERMES_UID and HERMES_GID ownership. Official DocsDocker: https://hermes-agent.nousresearch.com/docs/user-guide/docker/ Quickstart: https://hermes-agent.nousresearch.com/docs/getting-started/quickstart/ Telegram: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/telegram/

Hi! You have to mount /data directory from the container not the standard /home/node/.n8n. I had to change it to make the image Tailscale-friendly.

This is a support thread for a custom Docker image for n8n, specifically designed for better compatibility with Unraid where file permissions on mounted volumes can be problematic. Docker Hub: https://hub.docker.com/r/medzin/n8n GitHub: https://github.com/medzin/docker-n8n