はじめに
こんにちは、松山です。
Amazon FSx for Windows File Server を利用し、EC2 からドライブレターを割り当てて利用するケースは多いと思います。今回案件の環境では、FSx を Nドライブとしてマウントし、その中に格納したスクリプトを JP1から定期的に実行していました。
ところが、この運用には思わぬ落とし穴がありました。
課題
スクリプトのコード中では N:\script\xxx.bat のように ドライブレター指定 をしていました。
しかし、Windows での通常のネットワークドライブ (net use) マッピングは ユーザーごと／セッションごと に有効となるため、以下のような問題が発生しました。
- EC2 にログインしているユーザーは
N:を利用できるが、 - サービスとして動作する JP1 のジョブ実行環境（Session 0）からは Nドライブが見えない
- 結果として「ファイルが見つからない」エラーが発生
- 回避するには、毎回スクリプト内で
net useを書く必要がある → 運用負担増大
失敗した試み
課題解決に向けて、いくつか方法を試しましたがうまくいきませんでした。
-
ログオンスクリプト／スタートアップスクリプトで
net use- Windows の仕様上、マッピングは「ユーザーセッション」に紐付くため、サービス（Session 0）からは見えませんでした。
-
/persistent:yesオプションの利用- 再ログイン後にマッピングは復元されますが、あくまでそのユーザーだけ。JP1 サービスからは依然として不可視でした。
-
UACの
EnableLinkedConnectionsレジストリ設定- 管理者権限のプロセスでネットワークドライブを見えるようにする設定ですが、こちらも対象は「同一ユーザーセッション内」に限定されるため、サービスには効果なし。
-
UNCパスへの書き換え
- 最も堅実ですが、既存スクリプトが大量にあり短期的には難しかったため、即効性のある解決策にはなりませんでした。
解決方法：SmbGlobalMapping の活用
Windows Server 2019 以降では PowerShell の New-SmbGlobalMapping コマンドレットが利用できます。これにより、全セッションから利用可能なグローバルマッピング を作成できます。
手順例
# 既存のNドライブマッピングを削除
net use N: /delete 2>$null
Remove-SmbMapping -LocalPath N: -Force -ErrorAction SilentlyContinue
# サービス実行用アカウントの資格情報を指定
$cred = Get-Credential 'DOMAIN\svc_jp1'
# グローバルマッピングを作成
New-SmbGlobalMapping `
-RemotePath \\fsx-fileserver.domain.local\share `
-LocalPath N: `
-Credential $cred `
-Persistent $trueこれにより、JP1 がサービスとして実行される環境（Session 0）からも N: ドライブを利用可能となりました。
確認
Get-SmbGlobalMapping出力に N: が表示されればOKです。
注意点
- OSバージョン要件：Windows Server 2019 以降
- DFS Namespace は対象外：直接共有パスのみ指定可能
- 権限：アクセスはあくまで実行アカウントの権限で制御される。JP1 のサービスアカウントに必要な共有／NTFS 権限を付与する必要あり。
- 既存の
net useと競合：事前に削除してから設定するのが安全。
まとめ
- FSx を Nドライブとしてマウントして利用する場合、通常の
net useではサービス環境から認識できず、運用上の課題がありました。 - いくつかの方法を試しましたが、いずれもサービス環境では効果がありませんでした。
SmbGlobalMappingを使うことで 全セッション共通のネットワークドライブ を実現し、JP1 のようなサービスからも安定して利用可能になりました。- 既存スクリプトを大きく修正せずに課題を解決できる点がメリットです。
今後は可能な範囲で UNC パスへリファクタリングしつつ、短期的には SmbGlobalMapping を運用に組み込むのが現実的な解となりました。