Windows Server Backupでネットワーク共有にバックアップできない：「指定されたファイル パスは存在しないか…」の原因と解決策（Windows Server 2016）

Windows Server 2016 Standard で Windows Server Backup（WSB）を使い、バックアップ先をネットワーク共有フォルダーにすると「指定されたファイル パスは存在しないか、ローカル接続されたディスク上にありません」で失敗することがあります。この記事では、実際に解決した手順（共有フォルダーの再作成）を軸に、権限・指定方法・対象ボリュームの落とし穴まで具体的に整理します。

発生する症状：ネットワーク共有へのバックアップが開始できない

Windows Server 2016 の「Windows Server Backup」から、バックアップの保存先としてネットワーク共有フォルダー（共有ドライブ）を指定した際に、次のエラーで止まるケースがあります。

指定されたファイル パスは存在しないか、ローカル接続されたディスク上にありません

厄介なのは、エクスプローラー等で手動操作をすると、その共有フォルダーにファイルやフォルダーを作成できてしまう点です。「書けるのに、バックアップだけ失敗する」ため、ネットワークや権限の問題に見えて切り分けが長引きがちです。

項目	内容（例）	ポイント
OS	Windows Server 2016 Standard	WSB（Windows Server Backup）の標準機能で発生
バックアップ先	ネットワーク共有フォルダー（SMB 共有）	UNC パス指定が基本
表示エラー	指定されたファイル パスは存在しないか…	「保存先」以外が原因でも出ることがある
手動コピー	可能（フォルダー作成もできる）	WSB の実行コンテキストが別である可能性

まず結論：共有フォルダーを削除して同じ場所に再作成すると正常化することがある

この事例で最終的に解決したのは、バックアップ先として指定していた共有フォルダーを一度削除し、同じ場所に再作成する方法でした。再作成後はエラーが出ず、WSB がネットワーク共有へ正常にバックアップできるようになりました。

この動きから、次のような状態が疑われます。

• 共有設定（共有権限・共有名・オプション）の内部情報が不整合を起こしていた
• 以前の共有設定・ACL（アクセス制御リスト）・継承関係の残骸が残り、WSB から正しく見えなかった
• 共有フォルダー内の過去バックアップ構造（WindowsImageBackup など）が壊れていた、または権限がズレていた

WSB はバックアップ先に対して、単純な「書き込み」だけではなく、フォルダー作成・削除・属性設定・一時ファイル作成など複数の操作を行います。手動コピーができても、WSB の実行時に必要な操作のどこかで権限・状態・構造の不整合にぶつかると、結果として「パスが存在しない／ローカルディスクではない」系の分かりにくいメッセージに集約されることがあります。

共有フォルダー再作成の手順（バックアップ先サーバー側）

バックアップ保存先（共有フォルダーを提供している側）のサーバー／NAS で、次の順に進めます。

手順	操作	狙い	注意点
1	バックアップ用共有フォルダーを削除（必要なら退避）	壊れた共有状態・権限・構造をリセット	保存済みバックアップを保持したい場合は退避が必須
2	同じパス名で新規フォルダーを作成	ファイルシステム側の状態を初期化	別の用途のデータを混在させない
3	共有設定を作り直し（共有名・権限・オプション）	WSB がアクセスできる共有にする	まずは切り分け優先で広めの権限にするのが有効
4	NTFS 権限（セキュリティ）を作り直す	実効権限のズレを排除	共有権限だけでは不十分。必ず両方見る
5	WSB 側で共有フォルダーを再指定して実行	再接続・再認識させる	資格情報が古い場合は更新（後述）

この「削除→再作成」は、根本原因が “内部的な不整合” や “過去設定のゴミ” の場合に特に効きます。ネットワークやOS設定を大きく変えずに短時間で試せるため、同様のエラーではまず最初の候補に入れてよい対処です。

なぜ「手動で書ける」のにWSBは失敗するのか

現場で最もハマりやすいポイントがここです。WSB の処理は、あなたがログオンしているユーザーの操作と同じ条件で動いているとは限りません。

特に GUI からのバックアップでも、内部ではサービス／タスクとして動き、次の違いが出やすくなります。

観点	手動コピー（エクスプローラー等）	Windows Server Backup（WSB）	よくある落とし穴
実行ユーザー	ログオン中のユーザー	ローカル システム／バックアップ用コンテキスト／指定した資格情報	「自分が書ける＝WSBも書ける」と思い込みやすい
マッピングドライブ	見える（Z: など）	見えないことが多い	ドライブレター指定で失敗しがち
必要な権限	ファイル作成だけで足りる場合がある	作成・削除・属性設定・カタログ更新など複数操作	Modify/Full が必要な場面がある
既存構造	気にせず書き足せる	WSB 固有のフォルダー構造が前提	壊れた WindowsImageBackup があると失敗することがある

このため、原因切り分けでは「WSB と同じ条件で共有にアクセスできるか」を検証するのが近道です。次の章から、実務で効く確認手順を優先度順にまとめます。

最短で直すための切り分け手順（優先度順）

エラー文は「保存先パス」に見えますが、実際は複数要因が絡みます。時間を溶かさないために、まずは“やると結果がハッキリする”項目から潰します。

優先度	確認・対処	具体的なやり方	期待する結果
高	共有フォルダーを削除→再作成	共有提供側でフォルダーと共有設定を作り直す	不整合が原因ならこれだけで解決する
高	UNC パスで指定する	\\backup-server\wsb_backup の形式で指定	マッピングドライブ起因の失敗を排除
高	共有権限・NTFS 権限を見直す	まず切り分けとして Everyone フルコントロールも検討	権限不足を切り分けできる
中	資格情報（ユーザー名/パスワード）を明示	GUI で認証情報を入れ直す／wbadmin で -user/-password	別コンテキストによる認証失敗を排除
中	バックアップ対象ボリュームを再確認	存在しないドライブレターや外したボリュームが含まれていないか	「保存先に見えるが実は対象が原因」パターンを排除
低	ログを確認して裏取り	イベントビューアー（Backup/Operational 等）	再発防止や恒久対応の根拠になる

共有権限とNTFS権限：WSBは「書ければOK」ではない

WSB がネットワーク共有に保存する場合、バックアップ先には多様なファイル操作が発生します。よくあるのが「フォルダーは作れるのに、途中で失敗する」状態で、これは権限が部分的に足りない（または継承が崩れている）ときに起こります。

まず押さえるべき基本は、実効権限が共有権限とNTFS権限の両方で決まる点です。どちらかが弱いと、最終的に弱い方に引っ張られます。

切り分け用の権限設定（まず動かすことを優先）

本番で永続的に Everyone フルコントロールは推奨しませんが、原因切り分けとしては非常に有効です。動作確認で成功するなら「権限が主因」だと確信できます。

設定箇所	切り分け時の推奨	本番での考え方
共有権限	Everyone：フルコントロール	バックアップ用アカウント/サーバーのみへ最小権限に絞る
NTFS 権限	バックアップ用アカウント：フルコントロール（または変更）	必要十分な権限（通常は変更/フル）にし、監査や継承を整理

運用でおすすめの設計：バックアップ専用アカウントを作る

バックアップは「保存されるデータが強い権限を持つ」ため、運用上の事故を防ぐには専用アカウントを作って権限を限定するのが安全です。

• ドメイン環境：ドメインの専用アカウント（例：DOMAIN\wsb_backup）を作成し、共有・NTFS の両方で付与
• ワークグループ環境：共有提供側とバックアップ実行側で同名・同パスワードのローカルユーザーを用意するか、WSB 実行時に明示的に資格情報を指定

WSB はバックアップ先の直下に WindowsImageBackup フォルダー等を作成し、バックアップのカタログやイメージを配置します。フォルダー作成・更新・削除まで含めて許可されていないと、途中で詰まります。

指定はUNCパスが基本：ドライブレター（マッピング）は避ける

ネットワーク共有は、ドライブレター（Z: など）ではなく UNC パスで指定するのが鉄則です。

マッピングドライブは「そのユーザーのログオンセッション」に紐づくことが多く、サービスやタスク（WSBの実行主体）からは見えない／同じドライブ文字が存在しない、という事態が起こりやすいからです。

指定方法	例	推奨度	理由
UNC パス	\\backup-server\wsb_backup	高	実行主体が変わっても認識されやすい
マッピングドライブ	Z:\wsb_backup	低	サービス/タスクから見えず失敗することがある

「手動では書ける」のに失敗する場合でも、まず UNC へ切り替えるだけで解消するケースがあります。共有フォルダー再作成と合わせて、真っ先にやる価値があります。

wbadmin で検証すると原因が見えやすい

GUI のウィザードは簡単ですが、エラーが抽象的で、どの段階で失敗したかが見えにくいことがあります。切り分けには、コマンドラインの wbadmin を使うと状況がハッキリしやすくなります。

例えば、ネットワーク共有へ「今すぐ」バックアップする例は次のようになります（内容は環境に合わせて調整してください）。

wbadmin start backup -backupTarget:\\backup-server\wsb_backup -include:C: -allCritical -quiet -user:DOMAIN\wsb_backup -password:********

• -backupTarget：保存先（UNC 推奨）
• -include：バックアップ対象（例では C:）
• -allCritical：起動に必要な重要ボリュームも含める
• -user/-password：共有へ接続する資格情報を明示

資格情報を明示して成功するなら、「WSB が使っている認証情報が想定と違う」または「保存済み資格情報が古い」可能性が高いです。逆に、明示しても失敗するなら共有側（権限・構造・不整合）や対象ボリューム側の問題にフォーカスできます。

WSB と同じ条件で共有にアクセスできるか（簡易テスト）

ログオンユーザーでアクセスできても、WSB が動くコンテキストではアクセスできないことがあります。最も安全なのは「WSB が実際に使う資格情報で UNC にアクセスできるか」を確認することです。

簡易的には、資格情報を指定してディレクトリ参照できるかを確認します。

cmd /c dir \\backup-server\wsb_backup

ワークグループや資格情報の衝突が疑われる場合は、明示的に接続してから参照します。

net use \\backup-server\wsb_backup /user:DOMAIN\wsb_backup ********
cmd /c dir \\backup-server\wsb_backup
net use \\backup-server\wsb_backup /delete

この段階で拒否されるなら、WSB 以前に「認証・権限・名前解決・SMB到達性」のどこかです。WSB のウィザード画面だけを眺めるより、原因へ一直線に近づけます。

バックアップ対象ボリュームの選択ミスでも同じエラーが出ることがある

このエラーは保存先が原因とは限りません。見落としが多いのが、バックアップ対象として「今は存在しない」ボリュームが選択されたままになっているケースです。

例えば次のようなパターンがあり得ます。

• 一時的に隠しパーティション（System/Recovery/WinRE 等）へドライブレターを割り当てた
• 作業後にドライブレターを外した（または構成が変わった）
• しかし WSB の設定上は、その“存在しないドライブレター”をバックアップ対象に含めたまま
• 結果として WSB 実行時に参照できず、保存先エラーのようなメッセージで止まる

対策として、WSB の設定画面（または wbadmin の include/allCritical 指定）を見直し、対象が現在の構成と一致しているかを必ず確認します。

チェック項目	確認ポイント	対処
存在しないドライブレター	バックアップ対象に「今は無い」ドライブが含まれていないか	対象から外す／設定を作り直す
隠し/回復系パーティション	一時的な割り当ての痕跡がないか	allCritical を使う場合は設計を見直す
外付け・一時ボリューム	常に接続される保証があるか	対象に入れない、または接続運用を固定化

エラー文が保存先に見えても、実体は「バックアップ対象が存在しない」ことが引き金になっていることがあります。共有フォルダー再作成や権限調整をしても直らない場合は、ここを疑う価値が高いです。

イベントログで根拠を取る：見ておくべき場所

恒久対策や再発防止をするなら、WSB が何に失敗したのかをログで裏取りすると安心です。特に複数要因が絡む環境（NAS、別セグメント、認証方式が混在など）では、ログが最短ルートになります。

確認場所	見える内容	使いどころ
イベントビューアー：アプリケーション	バックアップ関連のエラー概要	失敗タイミング・頻度の把握
イベントビューアー：システム	ネットワーク、ディスク、VSS などの周辺エラー	保存先以外（VSS/ストレージ/ネットワーク）の切り分け
アプリケーションとサービス ログ：Microsoft のバックアップ系ログ	WSB のより詳細な処理ログ	共有アクセス失敗・対象ボリューム参照失敗の特定

ログを見て「アクセス拒否」「資格情報」「名前解決」「対象が見つからない」などの手がかりが出れば、対処は一気に絞れます。逆にログが薄い場合でも、共有フォルダー再作成＋UNC＋権限調整の基本手順が最も効果的です。

再発防止の運用ポイント：ネットワーク共有バックアップのクセを押さえる

ネットワーク共有への WSB バックアップは便利ですが、ローカルディスクへのバックアップに比べて、運用上のクセがあります。事故を減らすために、次の方針をおすすめします。

バックアップ専用の共有を用意し、用途を混在させない

• 共有フォルダー内に別用途のファイルを置かない（権限継承や構造破損の原因になりやすい）
• WSB 用に「サーバーごと」または「役割ごと」に共有/フォルダーを分ける
• 同じ共有を複数サーバーで使う場合は、バックアップの保存構造が衝突しないように設計する

世代管理が必要なら“保存先フォルダーをローテーション”する

WSB はネットワーク共有への保存だと、運用の仕方によっては過去世代が残りにくい（上書きされやすい）ことがあります。世代を残したい場合は、日付フォルダーへ出し分ける、世代用の共有を用意する、別のバックアップ方式（DPM やサードパーティ製品等）を検討するなど、要件に合わせた設計が必要です。

権限は最小化し、バックアップデータを守る

• バックアップ専用アカウントを使い、共有とNTFSの両方で必要最小限にする
• バックアップデータには機密情報が含まれる可能性が高いので、アクセスできる人・端末・サーバーを限定する
• NAS/ファイルサーバー側で監査ログやアクセスログを有効化できるなら有効化を検討する

障害対応を早くするため、テスト手順を固定化する

同じエラーが再発したときにすぐ動けるよう、次の“型”を決めておくと復旧が早くなります。

テストの型	実施内容	判断
共有到達性	UNC で参照できるか（dir / net use）	不可ならネットワーク・認証・権限のどれか
権限切り分け	一時的に権限を広げて成功するか	成功なら恒久的に最小権限へ戻して調整
WSB 実行	wbadmin で資格情報を明示して実行	成功なら GUI 側の資格情報・設定に問題が残る
対象確認	バックアップ対象のボリュームが実在するか	不整合があれば設定の作り直し

まとめ：このエラーで詰まったら、まずここから

「指定されたファイル パスは存在しないか、ローカル接続されたディスク上にありません」は、保存先の問題に見えても、実際には権限・認証・設定の残骸・バックアップ対象の不整合など、複数の原因で起こり得ます。

今回のケースでは、バックアップ先のネットワーク共有フォルダーを削除して再作成することで解決しました。同様の症状に遭遇したら、次の順で切り分けると最短で解決に近づけます。

• 共有フォルダーを削除・再作成し、共有設定とNTFS権限を作り直す
• バックアップ先はドライブレターではなく UNC パスで指定する
• 共有権限とNTFS権限の両方で、WSB が必要とする書き込み操作ができるようにする（まずは広め→最小化）
• バックアップ対象ボリュームに「今は存在しない」ドライブや一時ボリュームが混ざっていないか確認する
• 必要に応じて wbadmin とイベントログで原因を裏取りする

ネットワーク共有へのバックアップは、サーバーの復旧に直結する重要な仕組みです。設定が通ったら終わりではなく、「復元できるか」まで含めて定期的にテストしておくと、障害時のリスクを大きく減らせます。