ファイルサーバー再起動前に共有フォルダー利用者を特定するには、まず読み取り専用のGet-SmbSessionで接続セッションを、Get-SmbOpenFileで実際に開かれているファイルを確認します。管理コンソールなら「共有フォルダー」「セッション」と「開いているファイル」を別々に見ます。接続があるだけで編集中とは限らず、アイドル時間が長くても未保存データがないとは断定できないため、所有者へ通知し、強制切断は承認された保守時間の最後の手段にします。
セッションと開いているファイルを区別する
SMBセッションはクライアントとサーバーの接続単位で、ユーザー名、クライアントコンピューター、接続数などを示します。セッションがあってもファイルを編集中とは限りません。一方、開いているファイルはサーバーがクライアントのために保持するファイルハンドルを示します。再起動前は両方を確認し、セッション数だけで「利用者なし」と判断しません。
同じユーザーが複数PCから接続したり、サービスアカウントやコンピューターアカウントが共有を使ったりします。ユーザー名だけで連絡先を決めず、ClientComputerName、SessionId、ファイルパス、共有名、業務システムの所有者を組み合わせます。クラスターファイルサーバーではScopeNameやClusterNodeNameも確認し、現在の所有ノードと共有スコープを間違えないようにします。
GUIでは共有フォルダーの三つの一覧を見る
対象ファイルサーバーの「コンピューターの管理」を管理者として開き、「システムツール」「共有フォルダー」を展開します。「共有」では共有名とローカルパス、「セッション」では接続ユーザーとクライアント、「開いているファイル」ではファイルパスと利用者を確認します。別サーバーから接続する場合は、誤ったサーバーを選んでいないかウィンドウ名で確認します。
一覧の更新に時間がかかることがあり、表示直後の空欄を「利用なし」と断定しません。Microsoftは名前解決の問題によりセッション一覧の表示が遅くなる事例も公開しています。読み込みを待ち、必要ならPowerShellの結果と照合します。右クリックの「セッションを閉じる」「開いているファイルを閉じる」はデータ損失につながるため、調査段階では選びません。
Get-SmbShareで対象共有を確認する
管理者PowerShellを対象サーバーで開き、まずGet-SmbShareを実行して共有名、Path、ScopeName、ShareStateを確認します。MicrosoftのGet-SmbShareは、そのコンピューターが公開しているSMB共有を取得する読み取り専用コマンドです。対象共有だけを見る場合は、正式な共有名を指定し、管理共有や別部門の共有を混ぜないようにします。
DFS名前空間を利用している場合、利用者が見ているパスと実際のバックエンドサーバーが異なることがあります。DFS管理情報と保守対象サーバーを照合し、別ターゲットへ接続している利用者まで誤って通知しないようにします。共有のパス、サーバー名、クラスターロール、保守対象ボリュームを作業票へ記録します。
Get-SmbSessionで接続元を一覧化する
Get-SmbSessionはSMBサーバーとクライアントの間で確立しているセッションを取得します。出力からSessionId、ClientComputerName、ClientUserName、NumOpens、SecondsIdleなど必要な列を選び、対象共有の保守時点で記録します。表示結果は時々刻々変わるため、取得日時とサーバー名を必ず付けます。
SecondsIdleが大きくても、アプリがファイルを開いたままキャッシュしている可能性があります。NumOpensが0でも直後に再接続するサービスがあるため、アイドル値だけで強制切断対象にしません。同じSessionIdをGet-SmbOpenFileへ渡すと、そのセッションが保持するファイルを絞り込めます。
Get-SmbOpenFileで編集中の可能性を確認する
Get-SmbOpenFileはクライアントのために開かれているファイルの基本情報を取得します。FileId、SessionId、Path、ShareRelativePath、ClientComputerName、ClientUserName、Locksを確認し、保守対象共有のパスだけを絞ります。Microsoftの例でもセッションID、クライアント名、ユーザー名、パスが表示されます。
表示されたパスには個人名、案件名、機密フォルダー名が含まれる場合があります。結果をチャットや公開チケットへ貼り付けず、アクセス制限された保守記録へ保存します。CSVへ出す場合も保管期限と閲覧権限を決めます。ファイルハンドルがあることは利用中の重要な兆候ですが、アプリの保存状態までは分からないため、利用者へ確認します。
利用者とシステム所有者へ通知する
ClientUserNameとClientComputerNameから担当者を特定し、保守開始、対象共有、保存して閉じる期限、再開予定、連絡先を通知します。サービスアカウントやサーバー名が出た場合は、そのシステムの運用担当へ連絡し、ジョブ、バックアップ、スキャン、データ連携が動いていないか確認します。個人へ直接連絡できない場合は部門管理者へエスカレーションします。
単にエクスプローラーを閉じるだけでなく、WordやExcelなどのアプリで保存し、対象ファイルを閉じ、共有を使う業務アプリを正規手順で終了してもらいます。通知後にGet-SmbSessionとGet-SmbOpenFileを再取得し、差分を確認します。スクリーンショットだけでなく、取得時刻と残件を表へ残すと判断しやすくなります。
強制切断はデータ損失の可能性を前提にする
Close-SmbSessionはSMBセッションを強制終了するコマンドです。Microsoftは、クライアントが変更をサーバーへ書き戻していない場合にデータ損失を起こす可能性があると明記しています。確認のGet系コマンドと名前が似ていますが、Closeは変更操作です。調査中や連絡前に実行せず、変更承認、利用者確認、バックアップ、保守時間を満たした場合だけ検討します。
対象を誤ると一人の一ファイルではなく、そのセッション内の複数ファイルへ影響します。-Forceで確認を省略する運用は避け、対象SessionId、ユーザー、クライアント、開いているファイル、承認者を二人で照合します。WhatIfが利用できる場合も、それだけでデータ安全性が保証されるわけではありません。可能なら利用者またはサービス側の正常終了を優先します。
再起動直前に最終スナップショットを取る
保守開始直前に共有、セッション、開いているファイルを再取得し、残件と例外承認を記録します。新しいセッションが増えていれば、通知漏れまたは再接続するサービスがあります。共有への新規書き込みを止める運用がある場合は、アプリケーションと業務所有者の正規手順で実施し、アクセス権を場当たり的に削除しません。
サーバー再起動は本記事の確認とは別の変更作業です。クラスターフェールオーバー、バックアップ、レプリケーション、ウイルス対策、アップデート、依存サービス、監視抑止、復旧確認を保守計画に含めます。利用者がいないことだけを根拠に再起動せず、変更管理と復旧手順を満たします。
再起動後は共有と業務アプリを確認する
再起動後にGet-SmbShareで対象共有がOnlineか、共有パスが正しいかを確認します。代表クライアントから読み取りと、許可された検証用ファイルでの書き込みを行い、名前解決、認証、アクセス権、ファイルロック、クラスターフェールオーバーを確認します。実データを上書きしてテストしません。
監視、イベントログ、バックアップ、業務アプリの再接続も確認し、利用者へ再開を案内します。再開直後に多数のセッションが戻ることは正常な場合がありますが、エラーや極端な遅延がないか監視します。保守前後のスナップショット、通知、承認、残件、復旧確認を作業記録へ残します。
確認チェックリスト
- Get-SmbShareで対象共有、パス、サーバー、スコープを確認した
- Get-SmbSessionとGet-SmbOpenFileを別々に取得した
- 取得日時、SessionId、ユーザー、クライアント、開いているパスを記録した
- 結果に含まれる個人名や機密パスを限定された場所で保管した
- 利用者とサービス所有者へ保存・終了期限を通知した
- アイドル時間だけで安全と判断せず、通知後に再取得した
- Close系操作を調査段階で実行せず、強制切断のデータ損失を承認者と確認した
- 再起動後に共有、権限、代表クライアント、業務アプリ、監視を確認した
コメント