Bug Description

On a non-Docker Hermes install, opening the native Dashboard Files tab from another machine on the same network can cause the dashboard to treat the request as "hosted" and force the managed files root to /opt/data.

On a normal host install, /opt/data is a Docker-oriented path and may not exist or may be unreadable by the dashboard user. The result is a 500 in the Files tab instead of showing a valid host filesystem root.

Actual Behavior

Files tab shows:

{"detail":"Managed files root is unavailable: [Errno 13] Permission denied: '/opt/data'"}

In the same session, there was also a separate issue where the dashboard process needed a restart before the newer /api/files* routes became live, because web_server.py had been updated after the service started. After restart, the /api/files routes worked, but remote access still failed because the managed files root resolved to /opt/data.

Expected Behavior

For a non-Docker host install, remote dashboard access should not silently force /opt/data.

Reasonable expected behavior would be one of:

• use the same host root policy as local requests (for example, Path.home()), or
• detect whether Hermes is actually running in a containerized/hosted filesystem layout before forcing /opt/data, or
• fail with a clearer configuration error and documented override path.

Environment

• Hermes version: 0.16.0
• Install type: source/host install (not Docker)
• OS: Ubuntu 24.04
• Dashboard exposed on LAN with --host 0.0.0.0 --insecure
• Reproduced when opening the dashboard from another machine on the same LAN

Steps to Reproduce

1. Run Hermes dashboard as a host user service on Linux (non-Docker install).
2. Bind dashboard for LAN access, e.g. --host 0.0.0.0 --insecure.
3. Open the dashboard from another machine on the LAN.
4. Click Files.

Result

The Files view resolves the managed root to /opt/data and returns:

{"detail":"Managed files root is unavailable: [Errno 13] Permission denied: '/opt/data'"}

Relevant Source

Current logic appears to be:

def _managed_files_policy(request: Request, *, create_root: bool = True) -> ManagedFilesPolicy:
    raw_forced_root = os.environ.get(_MANAGED_FILES_ROOT_ENV, "").strip()
    if raw_forced_root:
        ...

    if not _local_dashboard_request(request) or _default_hermes_root_is_opt_data():
        root = _ensure_managed_root(_HOSTED_MANAGED_FILES_ROOT) if create_root else _HOSTED_MANAGED_FILES_ROOT
        return ManagedFilesPolicy(default_path=root, locked_root=root, can_change_path=False)

    home = _canonical_path(Path.home())
    return ManagedFilesPolicy(default_path=home, locked_root=None, can_change_path=True)

The not _local_dashboard_request(request) branch seems too broad for normal LAN usage on non-Docker installs.

Workaround

Set an explicit override for the dashboard service:

[Service]
Environment="HERMES_DASHBOARD_FILES_ROOT=/home/<user>"

Then restart hermes-dashboard.service.

This fixes the issue locally, but it looks like a workaround for an incorrect default policy.