コミュニティソリューション

ZimaOSでHermes Slackをセットアップし、ゲートウェイエラーを解決する方法

A ZimaOS user configured a new Hermes Slack app with Socket Mode but hit a permission error on /opt/data/gateway.lock and then received no response to channel mentions.

Hermes Agentは、現在のSlack統合がSocket Modeを使用しているため、パブリックWebhookエンドポイントを公開せずにSlackへ接続できます。このページの元となったコミュニティレポートでは、その設定の大部分が正常に完了しました。ユーザーは新しいSlackアプリを作成し、次のトークンを取得しました： 次を確認します。 ボットトークンと ボットトークンと アプリレベルトークンを取得し、次を実行しました hermes gateway setup ZimaOS Hermesコンテナ内で、Slackチャンネルにボットを招待しました。

この問題は、Hermesがゲートウェイを再起動しようとした際に発生しました。CLIは次を返しました PermissionError: [Errno 13] Permission denied: '/opt/data/gateway.lock'。Slack上ではアプリが表示されましたが、 @Hermes メンションしても応答がありませんでした。現在のZimaSpaceドキュメントでは、次の点が明示されています /opt/data 権限エラーは、ゲートウェイ操作を以前rootで実行した後に発生する可能性がある、Hermesの所有権に関する問題として扱います。現在のHermes Slackドキュメントでは、スコープを手動で推測するより安全な、いくつかの設定要件も追加されています。

ZimaOS Hermes Slackレポートで起きたこと

2026年5月のコミュニティ投稿では、クリーンなZimaOS Hermes環境と新しいSlackワークスペースが使用されました。ユーザーはSocket Modeを有効にしたSlackアプリを作成し、必要な2種類のトークンをコピーして、HermesゲートウェイのウィザードからSlackを設定しました。

重要な手順は次のとおりです：

  1. Slackアプリを作成し、Socket Modeを有効にします。
  2. で始まるボットユーザーOAuthトークンを取得します 次を確認します。.
  3. で始まるアプリレベルトークンを取得します ボットトークンと.
  4. 実行 hermes gateway setup Hermesコンテナ内で。
  5. Slackを選択し、2つのトークンを入力します。
  6. ゲートウェイの再起動を確認するプロンプトで承認します。

再起動に失敗した際のエラー：

PermissionError: [Errno 13] Permission denied: '/opt/data/gateway.lock'

その後、ユーザーはHermes Web UIからゲートウェイを再起動し、招待しました @Hermes Slackチャンネルに招待し、Slackでアプリが追加されたことを確認するメッセージを受け取りました。しかし、チャンネルでメンションしても返信はありませんでした。つまり、トラブルシューティングが必要な箇所は、ZimaOS側のゲートウェイプロセスとSlack側のイベント設定の2層に分かれている可能性があります。

コミュニティのSlackトラブルシューティング投稿で共有されたZimaOS Hermesの設定リファレンス
このコミュニティレポートは、Slackの設定を試す前に、ZimaSpace Hermesの設定ガイドを参照して始まりました。

すべてのスコープを手動で再構築する代わりに、現在のHermes Slackマニフェストを使用する

現在のHermesドキュメントでは、Slackアプリのマニフェストを生成することが推奨されています。これは、すべてのOAuthスコープ、スラッシュコマンド、イベントサブスクリプション、Socket Modeの設定を記憶から手動で再構築するより安全です。

現在のHermes環境内で、次のコマンドを実行してマニフェストを生成します：

hermes slack manifest --agent-view --write

生成されたファイルの書き込み先：

~/.hermes/slack-manifest.json

次に、Slackのアプリ管理画面で、そのマニフェストから新しいSlackアプリを作成します。現在のHermesドキュメントでは、マニフェストによって組み込みコマンド、必要なスコープ、イベントサブスクリプション、Socket Modeの設定がまとめて宣言されることを説明しています。

現在の上流手順については、Hermes Agent Slackセットアップガイドを参照してください。

Hermesに必要な2つのSlackトークン

Hermesは異なる2つのSlack認証情報を使用しており、これらは相互に代用できません。

  • ボットトークン： xoxb-で始まり、SLACK_BOT_TOKENになります。
  • アプリレベルトークン： xapp-で始まり、Socket Modeをサポートしている必要があり、SLACK_APP_TOKENになります。

現在のHermes環境ファイルには、次のように記述できます。

SLACK_BOT_TOKEN=xoxb-your-bot-token
SLACK_APP_TOKEN=xapp-your-app-token
SLACK_ALLOWED_USERS=U01ABC2DEF3

SlackメンバーIDが次の項目に含まれていることを確認します 表示名ではなくSlack Member IDを使用します。トークンが正しくても、リクエストしたユーザーに権限がない場合、Hermesは接続済みのように見えながら、そのユーザーのメッセージの処理を拒否することがあります。

実際のものは決して公開しないでください 次を確認します。 または ボットトークンと コミュニティ投稿、スクリーンショット、Gitリポジトリ、サポートログに記載する値。公開されてしまったトークンは無効化して再生成してください。

チャンネルメンションには正しいSlackイベントが必要

ボットがチャンネルに表示されていることは、SlackがHermesにメッセージイベントを配信している証拠にはなりません。現在のHermesドキュメントでは、イベントサブスクリプションが障害の一般的な原因として挙げられています。

手動で設定したSlackアプリでは、現在のHermesバージョンに必要なイベントを確認してください。現在のドキュメントには、次のようなイベントが含まれています。

  • app_mention ダイレクトの場合 @Hermes メンション。
  • message.channels ボットが参加しているパブリックチャンネルのメッセージの場合。
  • message.groups プライベートチャンネルのサポートが必要な場合。
  • message.im ダイレクトメッセージの場合。

Slackアプリのインストール後にスコープまたはイベントサブスクリプションを変更した場合は、Slackに求められたらアプリをワークスペースに再インストールしてください。そうしないと、表示される設定と、インストール済みボットに実際に付与されている権限が異なる場合があります。

テスト前にHermesをチャンネルへ招待する

HermesはSlackのすべてのチャンネルに自動参加するわけではありません。明示的に招待してください。

/invite @Hermes

次に、Member IDがHermesの許可リストに含まれているSlackユーザーから、簡単なメンションをテストします。ダイレクトメッセージは機能するのにパブリックチャンネルでのメンションが機能しない場合は、 app_mention, message.channelsZimaOSのネットワーク設定を変更する前に、チャンネルへの参加状況、アプリに付与されている権限を確認します。

/opt/data/gateway.lockでPermission Deniedが発生する理由

現在のZimaSpace Hermes Agentガイドには、/opt/dataの権限問題が記載されています。これは通常、以前にHermes Gatewayをrootとして実行したことで、$HERMES_HOME内にroot所有のファイルが残っていることが原因だと説明されています。

ZimaSpaceが文書化しているコンテナのワークフローでは、専用の hermes ユーザー：

docker exec -it -u hermes hermes bash

次に、Hermesの仮想環境を有効化します。

source /opt/hermes/.venv/bin/activate

で直ちに失敗する場合、メッセージング設定は次のコマンドで開けます。

hermes gateway setup

ゲートウェイが /opt/data/gateway.lock実行したり、ゲートウェイ全体をrootとして繰り返し実行したりしないでください。まず、関係するユーザーと所有権を確認します。

id
ls -ld /opt/data
ls -l /opt/data/gateway.lock 2>/dev/null

現在のZimaSpaceガイドでは、ZimaOSダッシュボードでHermesのログを確認し、ファイル所有権の修復が必要な場合に限って一時的にrootシェルを使用することを推奨しています。所有権を再帰的に変更する操作を、確認なしに /opt/data Hermesに属するファイルと、インストールされているZimaOSパッケージが想定するユーザー／グループを確認していない場合は実行しないでください。

Hermesがランタイムファイルを書き込めるようになってからゲートウェイを再起動する

コミュニティの報告では、Web UIでゲートウェイを再起動をクリックしただけでは、ゲートウェイが正常であることの証明にはなりませんでした。基盤のプロセスがロックファイルを作成または更新できない場合、UI操作後もSlack連携が利用できないことがあります。

実際の所有権の問題を修正したら、次のユーザーとしてコンテナに入ります。 hermes ユーザーでコンテナに入り、環境を有効化して、インストールされているHermesのリリースでサポートされているコマンドを使ってゲートウェイを実行または再起動します。テスト用のSlackメッセージを送信しながら、ZimaOSのHermesログを確認します。

トラブルシューティングでは、次のように切り分けると便利です。

  • ゲートウェイが起動しない：/opt/dataの権限とHermesのログを調査します。
  • ゲートウェイは稼働しているが、Slack接続がない：xapp-トークンとSocket Modeを確認します。
  • Slack接続は存在するが、チャンネルメンションに反応しない：アプリイベント、チャンネルへの参加状況、再インストールの状態、SLACK_ALLOWED_USERSを確認します。
  • DMは機能するが、チャンネルが機能しない：モデルプロバイダーではなく、チャンネルイベントと権限を確認します。

Hermes Webダッシュボードはステータス確認に使用し、唯一のヘルスチェック手段にはしない

ZimaSpaceガイドでは、Hermes Webダッシュボードを次の場所で公開しています。

http://ZIMAOS_LAN_IP:9119

The dashboard can show running status, sessions, and model settings. It is useful for restarting and observing the gateway, but combine it with logs when a process-level permission error occurs.

ダッシュボードには、実行状態、セッション、モデル設定を表示できます。ゲートウェイの再起動や状態確認に便利ですが、プロセスレベルの権限エラーが発生した場合はログと併せて使用してください。
ZimaOSコミュニティユーザーが共有したHermes Slackトラブルシューティングのスクリーンショット

コミュニティの報告では、Slackユーザーには連携が表示されているものの、チャンネル内のメンションにはまだ応答していませんでした。

  1. ZimaOS上のHermes Slackトラブルシューティングチェックリスト
  2. Slackを追加する前に、Hermesのモデル設定自体が機能することを確認します。 hermes ZimaOSコンテナに次のユーザーとして入ります
  3. 通常のゲートウェイ運用ではrootではなく、ユーザーとして実行します。
  4. 可能な場合は、スコープを手作業で推測するのではなく、現在のHermes Slackマニフェストを使用してください。 次を確認します。 xoxb- ボットトークンと xapp-
  5. アプリトークンが同じ対象Slackアプリのものであること。
  6. Socket Modeが有効になっていることを確認します。 SlackメンバーIDが次の項目に含まれていることを確認します.
  7. SLACK_ALLOWED_USERS
  8. テストするチャンネルにHermesを招待します。 app_mention 確認
  9. Slackから要求された場合は、スコープまたはイベントサブスクリプションを変更した後にSlackアプリを再インストールしてください。
  10. もし /opt/data/gateway.lock 再起動を繰り返す前に、所有者情報とZimaOSのHermesログを確認してください。
  11. ゲートウェイが正常になったら、DMとチャンネル内でのメンションをそれぞれ個別にテストしてください。

ZimaOS上のHermes Slack FAQ

gateway.lockの権限エラーとは何ですか？

これは、Hermesプロセスが想定された場所にある実行時ロックファイルへアクセスできないことを意味します。現在のZimaSpaceドキュメントでは、 /opt/data 権限エラーは通常、Hermes Gatewayをrootで実行した後に、root所有のまま残されたファイルに関連しています。

Hermes Gatewayを修復するためにrootで実行すべきですか？

通常の解決策ではありません。ZimaSpaceでは、コンテナに入る際に hermes 通常のHermes操作用のユーザー。rootシェルは、所有者情報の修復が必要だと確認できた場合にのみ、一時的に使用してください。

SlackでHermesボットは表示されるのに返信しないのはなぜですか？

インストールして招待されていることは、Slackがアプリを認識していることを示すだけです。Hermesには、正常なゲートウェイ、 有効なSocket Mode接続、正しいイベントサブスクリプション、適切なワークスペース権限、そして許可されたSlackメンバーIDが引き続き必要です。

Hermes Slackには公開Webhook URLが必要ですか？

いいえ。現在のHermes Slack連携はWebSocket経由のSocket Modeを使用するため、Hermesのインスタンスをファイアウォールの背後に置いたまま、公開された受信Slack Webhookエンドポイントなしで運用できます。

Slackアプリを設定する現在の最善の方法は何ですか？

インストール済みのHermesリリースが対応している場合は、現在のHermes生成Slackマニフェストを使用してください。これにより、スコープ、イベントサブスクリプション、スラッシュコマンドの定義不足によるエラーを減らせます。