ramifara

The Hermes-Agent Community Applications template has a critical data-loss footgun in its default /opt/data mapping.Current default mapping Hermes describes /opt/data as the single source of truth for all configuration and runtime state, including: - Configuration - Sessions - state.db - kanban.db - Workspaces - Credentials - Memories - Long-running agent state The problemMy Unraid server does not have a cache pool. In this configuration, /mnt/cache is not a mounted persistent filesystem. Docker silently created the missing host path inside Unraid's RAM-backed root filesystem. Hermes then ran normally for several days and wrote all of its state there. Nothing in the template or container indicated that /opt/data was not actually persistent. After the next Unraid reboot, the directory was recreated empty, resulting in the loss of: - All Hermes session history - Kanban state - Workspaces - Configuration - Long-running agent state - Other persistent application data Evidencedocker inspect Hermes-Agent: /mnt/cache/appdata/hermes-agent -> /opt/data RW=truefindmnt: No /mnt/cache mount exists. System uptimeRecently rebooted./mnt/cache/appdata/hermes-agent All files have timestamps after the reboot.Why this is dangerousThe template currently advises users to use "a real disk path like /mnt/cache." However, /mnt/cache is only a real persistent disk path if a cache pool actually exists. A new Unraid user has no reasonable way to know that Docker will silently create a missing bind-mount directory inside the host's volatile root filesystem. From the user's perspective, everything appears to be working correctly until the first reboot permanently erases all application state. Suggested improvementsI believe this should be treated as a critical template issue. I recommend the following changes: 1. Do not default the application's single source of truth to /mnt/cache without verifying that a cache pool exists. 2. Require users to select an existing persistent storage location, such as: - /mnt/disk1/appdata/hermes-agent - /mnt/disk2/appdata/hermes-agent - A valid named pool 3. Add a prominent warning that /mnt/cache is not persistent when no cache pool is mounted. 4. Ideally, refuse to start the container if /opt/data resolves to rootfs, tmpfs, overlay, or any other non-persistent filesystem. 5. Add an explicit first-run persistence verification step to the installation and support documentation. 6. Warn existing users immediately, as others may currently have Hermes storing its entire state in RAM without realizing it, and will lose everything on their next reboot. Final noteI understand that using /mnt/user has potential FUSE, SQLite, and ownership caveats. However, a permission error or startup failure is far preferable to an application appearing completely healthy while silently storing its entire state in volatile RAM. If avoiding /mnt/user, the template should require an existing /mnt/diskX or named pool path instead of assuming /mnt/cache is valid. This issue has already resulted in the loss of several days of agent sessions and work. I am new to Unraid, so I accept that I could have known more about its storage layout. However, this default behavior is easy for new users to fall into, and I believe the template can be improved to prevent others from experiencing the same data loss.