Windows 11 24H2の新しいノートPCで、WD My Cloud Mirror（NAS）の共有フォルダーをネットワークドライブとして割り当てようとすると「The mapped network drive could not be created… / An extended error has occurred（拡張エラーが発生しました）」で失敗する──同じLAN内の他PCでは接続できるのに、このPCだけダメ。こうした“片側だけ繋がらない”系トラブルは、資格情報・名前解決・SMBのセキュリティ要件のズレが原因になりがちです。本記事では、実際に解決した手順と、安全に運用するための落としどころまでまとめます。
現象：Windows 11 24H2でNASのネットワークドライブ割り当てが失敗する
今回のケースは、WD My Cloud Mirror の共有フォルダーをWindowsの「ネットワーク ドライブの割り当て」からマップしようとしたときに、次のようなエラーで止まる状況です。
- エラー表示：The mapped network drive could not be created… / An extended error has occurred（拡張エラーが発生しました）
- 同一ネットワーク上の別PC（Windows 10 / Windows 11）では問題なく接続できる
- NASファームウェアは最新
- SMB 1/2/3 は有効（ただし運用としては後述のとおりSMB1は基本OFF推奨）
この「拡張エラーが発生しました」はメッセージが抽象的で、原因がひとつに決まらないのが厄介です。よくあるのは次の3系統です。
| 系統 | 起きがちな原因 | 症状の特徴 |
|---|---|---|
| 資格情報（ユーザー/パスワード） | ゲスト接続、古い資格情報の残骸、ユーザー名の書式ミス | エクスプローラーで開くと資格情報が何度も求められる／突然失敗する |
| 名前解決・経路 | NAS名が引けない、DNS/NetBIOS/WSD、VPNや別セグメント | NAS名だと失敗するがIP直打ちだと通る |
| SMBの互換性・セキュリティ要件 | SMB署名、SMB方言（2/3）、暗号化、Windows側の既定が強化 | 他PCは通るのに“このPCだけ”失敗しやすい |
まず押さえるポイント（前提）：NAS接続の土台を整える
ゲストアクセスは使わず、必ずNASのユーザー名・パスワードで接続する
Windows 11では、セキュリティ面から「ゲスト接続（匿名）」が弾かれやすい設計になっています。WD My Cloud Mirror 側でユーザーを作り、そのユーザー名・パスワードでアクセスするのが基本です。
SMB1は原則OFF、SMB2/SMB3を使う
SMB1は古く脆弱性の面でも非推奨です。特別な理由がない限り、SMB2/SMB3で接続できる状態に寄せましょう。今回のように「SMB1/2/3は有効」にしている環境でも、トラブルシュートの最終形は“SMB2/3で安定動作”が理想です。
| 項目 | 推奨 | 理由 |
|---|---|---|
| SMB1 | 無効 | 古い規格でセキュリティリスクが高い。Windows側も既定で無効のことが多い |
| SMB2/SMB3 | 有効 | 現行の互換性・性能・安全性の基盤。NASも実質ここが主戦場 |
| ゲスト（匿名）アクセス | 無効 | Windows 11で弾かれやすい。監査や権限管理も不利 |
Windows 11 24H2では“SMBが繋がらない”既知系の挙動が出ることがある
同じNASが別PCでは繋がるのに、新しいWindows 11 24H2だけ失敗する場合、Windows側のSMBセキュリティ要件（署名など）とNAS側実装の噛み合わせで失敗しているケースが現実的です。ここでは、影響が大きい順に潰していきます。
実際に有効だった解決手順：SMB署名必須を一時的に無効化して割り当てる
結論から言うと、今回のケースでは「WindowsのSMBクライアントで“署名必須”を一時的に外す」ことで割り当てが成功しました。次の手順で進めます。
手順1：管理者権限のPowerShellでSMB署名必須を一時的に無効化
スタートメニューでPowerShellを検索し、「管理者として実行」します。以下を実行します。
Set-SmbClientConfiguration -RequireSecuritySignature $false実行後は再起動します。単に再ログインでは反映が不十分なことがあるため、ここは素直に再起動が安定です。
手順2：エクスプローラーから「別の資格情報」でネットワークドライブを割り当てる
再起動後、エクスプローラーの「ネットワーク ドライブの割り当て」を開き、次を意識して設定します。
- 「別の資格情報で接続する」にチェック
- NASで作成したユーザー名／パスワードを入力
- パスは \\<NASのIPアドレス>\<共有名> を優先（名前解決の問題を回避）
例：
\\192.168.1.50\Publicここで割り当てに成功すれば、原因はかなりの確度で「SMB署名要件や認証周りの噛み合わせ」です。
手順3：その後の状態（セキュリティソフトの影響切り分け）
この事例では、割り当てに成功した後にMcAfeeを再インストールしても接続は維持されました。つまり「セキュリティソフトが決定打ではなかった」可能性が高い、という結果です。
ただし一般論として、セキュリティソフトやEDRがSMB（TCP 445）を監視して影響する環境もゼロではありません。まずOS側の要件差（とくに24H2）を切り分け、必要に応じて例外設定を検討する、という順番が安全です。
なぜ効くのか：SMB署名（Security Signature）が原因になりやすい背景
SMB署名は、通信の途中改ざんを検出するための仕組みです。Windows側で「署名必須」になっていると、相手（NAS）の対応が不完全だったり挙動が不安定だったりした場合、接続が成立しないことがあります。
今回のコマンドは、Windowsクライアントの「署名必須」を外す操作です。
- メリット：NAS側が署名周りで躓く環境でも繋がる可能性が上がる
- デメリット：LAN内に攻撃者が入り込める状況では、改ざん検出が弱くなる
つまり「繋がることを最優先にする暫定回避策」になり得る一方で、恒久運用にするなら“安全な落としどころ”を考えるのが大切です。
もう少し安全に運用するための代替案：本来は署名必須へ戻すのが理想
家庭内LANなど信頼できる範囲で暫定運用するのは現実解ですが、可能なら最終的に以下を目指すのがおすすめです。
代替案A：NAS側でSMB署名に対応・有効化できるなら、Windowsを既定へ戻す
WD My Cloud Mirror 側でSMB署名を有効にできる（またはファーム更新で改善する）なら、Windows側は元に戻しましょう。
Set-SmbClientConfiguration -RequireSecuritySignature $trueこの構成が最も望ましい形です。NAS側が署名非対応・不安定な場合のみ、$false を“影響範囲を限定して”使うのが筋になります。
代替案B：影響範囲を狭める（家庭内LANのみに限定する）
署名必須を外す場合は、次の対策でリスクを下げられます。
- NASは家庭内LANにのみ置き、不要なポート開放（外部公開）をしない
- PC側のネットワークプロファイルをプライベートにする（パブリック回避）
- ゲストアクセスを使わず、ユーザー/パスワードの認証を必須にする
- ルーターのゲストWi-Fiや不特定端末がぶら下がるセグメントからNASへ到達できないようにする
| 運用 | おすすめ度 | 理由 |
|---|---|---|
| NAS側署名ON + Windows署名必須ON | 高 | 安全性と整合性が最も良い。できるならこれ |
| Windows署名必須OFF（家庭内LAN限定） | 中 | 繋がらない問題を回避しやすい。リスクを理解して限定的に |
| SMB1有効化で凌ぐ | 低 | 互換性目的でもリスクが高い。最終手段にしない方がよい |
うまくいかない場合のチェックリスト：原因を素早く切り分ける
「署名必須OFFでもダメ」「割り当てはできたが不安定」などの場合に備えて、切り分けポイントを“効果が出やすい順”で並べます。
UNCパスで直接アクセス（名前解決の問題を潰す）
まずはマップより先に、エクスプローラーのアドレスバーで直接開きます。
- NAS名：
\\MyCloudMirror\Share - IP指定：
\\192.168.1.50\Share
NAS名でダメでIPで通るなら、名前解決（DNS/NetBIOS/WSD）側が原因の可能性が高いです。恒久的には、ルーターのDHCP固定割り当てやhosts、DNS設定の見直しが効きます。
資格情報マネージャー（古いNAS資格情報を削除）
過去に別PCや別ユーザーで繋いだ情報が残っていると、Windowsは“間違った資格情報”で接続しようとして失敗します。次を実施します。
- 「資格情報マネージャー」→「Windows資格情報」→NASっぽい項目を削除
- 削除後、再度「別の資格情報で接続する」で入力し直す
コマンド派なら cmdkey でも整理できます。
cmdkey /list
cmdkey /delete:192.168.1.50ネットワークプロファイルが「プライベート」になっているか
パブリック（公衆）扱いだと共有や探索が制限され、症状が複雑化します。設定で「プライベート」にしておくと、共有系のトラブルが減ります。
TCP 445（SMB）がブロックされていないか
Windowsファイアウォールやセキュリティソフトで、SMBの本丸であるTCP 445がブロックされると当然繋がりません。次のコマンドで疎通を見ます。
Test-NetConnection -ComputerName 192.168.1.50 -Port 445結果が「TcpTestSucceeded : True」なら到達できています。Falseなら、PC側・ルーター側・NAS側のどこかで遮断されています。
NAS/ルーター再起動、NASファーム更新の再確認
地味ですが、SMBのセッションが中途半端に残っていると、特定端末だけ認証が通らない状態になることがあります。再起動でセッションが整理され、症状が消えることがあります。ファーム更新は「最新のはず」でも、念のため再確認しておくと安心です。
割り当て方法を変えて試す：GUIがダメならコマンドで繋ぐ
エクスプローラーの割り当てが失敗する場合でも、コマンド経由だと分かる情報が増えたり、通ったりすることがあります。ログの手がかりにもなるので、試す価値はあります。
コマンドプロンプト：net useで割り当て
net use Z: \\192.168.1.50\Share /user:NASユーザー名 NASパスワード /persistent:yes- うまくいけば、そのままZドライブが作成されます
- 失敗した場合は、エラーコードが出やすく切り分けが進みます
既存の割り当てが邪魔しているときは一度消します。
net use Z: /delete
net use * /deletePowerShell：New-PSDriveで永続マップ
資格情報を明示して永続化したい場合に便利です。
$user = "NASユーザー名"
$pass = ConvertTo-SecureString "NASパスワード" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($user, $pass)
New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\192.168.1.50\Share" -Credential $cred -Persist※パスワードを平文で書くのに抵抗がある場合は、実運用では対話入力や資格情報マネージャー利用へ寄せましょう。トラブルシュートでは“原因切り分けのために一度だけ”明示するのは有効です。
状態確認：本当にSMBでどう繋がっているかを見ておく
割り当て後、SMBの接続状態を確認しておくと「直った／直ってない」の判断がブレません。特に“なぜこのPCだけダメだったのか”を後から説明しやすくなります。
SMBクライアント設定の確認
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature| 項目 | 意味 | 目安 |
|---|---|---|
| RequireSecuritySignature | 署名を必須にするか | 基本はTrue（暫定回避でFalse） |
| EnableSecuritySignature | 署名を使えるなら使うか | True推奨 |
現在のSMB接続一覧
Get-SmbConnectionここでDialect（SMB 3.x/2.x）やSigned（署名の有無）などが見える場合があります。環境によって表示項目は異なりますが、“繋がっている事実”の確認には十分役立ちます。
よくある落とし穴（WD My Cloud Mirrorでも起きやすいポイント）
「NASは見える」のに「割り当てだけ失敗」する
ネットワーク一覧にNASが表示されるのは、あくまで探索（発見）の話です。割り当ては認証とSMB交渉が必須なので、探索が成功しても割り当てが失敗することは珍しくありません。特に24H2のようにセキュリティ要件が強めの環境では、この差が出やすいです。
ユーザー名の書式（NAS側の想定）
NASによっては「NAS名\ユーザー名」で通ることもあれば、「ユーザー名だけ」で通ることもあります。迷ったら、WD側の管理画面で作ったユーザー名をそのまま入力し、通らない場合に書式を変えます。
固定IP（DHCP固定）にしておかないと、次回から繋がらない
一度マップに成功しても、NASのIPが変わると「昨日まで繋がったのに今日ダメ」になります。名前解決が不安定な環境ほど、最初はIP直打ちで成功させ、次にDHCP固定でIPを固定し、最後に必要ならNAS名アクセスへ戻すのが堅い進め方です。
まとめ：最短で直し、最終形は“安全寄り”に戻す
- Windows 11 24H2でNASのネットワークドライブ割り当てが失敗する場合、SMB署名要件が引っかかっていることがある
- 暫定回避として、管理者PowerShellで
Set-SmbClientConfiguration -RequireSecuritySignature $false→ 再起動 → 「別の資格情報」で割り当て、が効くケースがある - ただし署名必須OFFはリスクがあるため、可能ならNAS側で署名対応し、Windowsは
$trueに戻すのが理想 - うまくいかないときは、IP直打ち、資格情報の削除、ポート445疎通、ネットワークプロファイル（プライベート）を順に確認すると切り分けが早い
ネットワークドライブは日常的に使うほど“ちょっとした仕様差”がストレスになります。今回のように新PCだけが失敗する場合は、闇雲にSMB1へ逃げるより、まず署名・資格情報・名前解決を正面から整えるのが近道です。
コメント