Windows の AWS Deadline Cloud Worker でジョブが同じエラーで 3 回拒否された話
はじめに
AWS Deadline Cloud の CMF (Customer-Managed Fleet) Worker を Windows で構成し、ジョブを Worker Agent と同じ OS ユーザーで実行する WORKER_AGENT_USER モードを使おうとしたときに遭遇した問題を共有します。
ジョブを投入すると、入力ファイルの同期の直前でセッションが 1 秒未満に FAILED し、Worker Agent のログに次のエラーが出ます。
ERROR Session.Failed Job cannot run as WORKER_AGENT_USER.
Worker Agent is running with Administrator privileges.
メッセージは Administrator 権限を指しているように読めます。ところが、権限まわりを対処しても同じ文言のまま 2 回再発し、結局 3 段階の原因がありました。しかも最後の原因は権限の有無を一切見ていませんでした。 本記事では、この 3 つの対処について書きます。
AWS Deadline Cloud とは
AWS Deadline Cloud は、3DCG/VFX 制作向けのレンダーファームをクラウド上に構築できるマネージドサービスです。Worker のオートスケーリングやジョブ管理、ライセンス供給などレンダーファーム運用に必要な機能を備えています。
対象読者
- AWS Deadline Cloud の CMF を Windows Worker で構築している、もしくは検討している方
WORKER_AGENT_USERモードでジョブを動かしたい方- 公式ドキュメントだけでは越えられない設定要件に当たっている方
参考
- AWS Deadline Cloud Developer Guide: Customer-managed fleets
- aws-deadline/deadline-cloud-worker-agent
- OpenJobDescription Specifications (ジョブユーザー / セッションのモデル)
- Microsoft Learn: Replace a process level token (SeAssignPrimaryTokenPrivilege)
前提となる構成
WORKER_AGENT_USER モードは、ジョブを Worker Agent サービスと同じ OS ユーザーで実行する方式です。ジョブ実行専用のユーザーを別に用意しない最小構成で使われます。
Administrators グループ所属
install-deadline-worker は Windows で deadline-worker という非対話ユーザーを作り、サービスをこのユーザーで起動します。ところがこのユーザーが Administrators グループに自動で加入していました。Deadline Cloud は Administrators 所属のユーザーを WORKER_AGENT_USER モードの実行対象から除外するため、すべてのジョブが拒否されます。
対処は、グループからの除外とサービス再起動です。
Remove-LocalGroupMember -Group Administrators -Member deadline-worker
Restart-Service DeadlineWorker -Force
SeAssignPrimaryTokenPrivilege
グループから除外しても、同じエラーが続きます。secedit /export で User Rights Assignment を確認すると、deadline-worker に SeAssignPrimaryTokenPrivilege が付与されていました。これはプロセスのトークンを置換するための特権です。
Deadline Cloud のチェックは、Administrators 所属だけでなく、この特権の保持者も Administrator 相当と判定します。install-deadline-worker がこの特権を自動付与するため、グループ除外だけでは判定が変わりません。特権を一度除外するとチェックは次に進みます。
@'
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Privilege Rights]
SeAssignPrimaryTokenPrivilege = *S-1-5-19,*S-1-5-20
'@ | Set-Content -Path C:\Windows\Temp\fix-priv.inf -Encoding Unicode
secedit /configure /db C:\Windows\Temp\fix-priv.sdb /cfg C:\Windows\Temp\fix-priv.inf /areas USER_RIGHTS
Restart-Service DeadlineWorker -Force
ここで一点補足があります。この特権は「外せばチェックを通るが、通った先で必要になる」という二面性を持ちます。後述の run_jobs_as_agent_user = true を有効化すると、ジョブの子プロセスを起動するためにこの特権が要ります。そのため最終的には元に戻すことになります。いったんは外して次の対処に進みます。
scheduler.py のハードコード判定
特権を外しても、まだ同じエラー文言で再発します。そこで Worker Agent のソースを Worker EC2 上で直接読み、原因の実体を特定しました。
C:\Program Files\Python311\Lib\site-packages\deadline_worker_agent\scheduler\scheduler.py
該当箇所は次のような判定でした。
# For Windows the WA runs as Administrator so fail jobs that were configured to runAs - WORKER_AGENT_USER
if (
os.name == "nt"
and self._job_run_as_user_override.job_user is None
and not self._job_run_as_user_override.run_as_agent
and job_details.job_run_as_user
and job_details.job_run_as_user.is_worker_agent_user
):
err_msg = "Job cannot run as WORKER_AGENT_USER. Worker Agent is running with Administrator privileges."
self._fail_all_actions(session_spec, err_msg)
エラー文言は Administrator privileges に言及していますが、この判定は実行時の権限を一切見ていません。 os.name == "nt" であること (つまり Windows であること) を理由に、WORKER_AGENT_USER モードを既定で拒否するという、ハードコードによる挙動でした。文言を額面どおりに受け取って権限の調整を続けても、ここを抜けられません。
正しい方法は、worker.toml で明示的にオプトインすることです。
[os]
run_jobs_as_agent_user = true
あわせて、2 つ目の対処で外した SeAssignPrimaryTokenPrivilege は子プロセスの起動に必要なので、ここで deadline-worker に戻します。
最終状態
3 つの対処を越えた後に成立する設定の組み合わせは次のとおりです。
| 項目 | 状態 |
|---|---|
deadline-worker の Administrators 所属 |
除外 |
deadline-worker の SeAssignPrimaryTokenPrivilege |
維持 (run_jobs_as_agent_user で必要) |
worker.toml の run_jobs_as_agent_user |
true |
この組み合わせに至って初めて、WORKER_AGENT_USER モードのジョブが動きます。
まとめ
Windows の Deadline Cloud Worker で同じエラー文言が 3 回出て、その裏に 3 つの異なる原因がありました。Administrators グループ、SeAssignPrimaryTokenPrivilege、そして Windows 既定のオプトアウト判定です。エラー文言を鵜呑みにせず、必要なら Worker Agent のソースを読むことが、Windows の Deadline Cloud 運用では有効です。
Windows で Deadline Cloud の CMF Worker を構築する方の参考になれば幸いです。





