Windows 10/11でネットワーク共有フォルダーにアクセスできない・ドライブをマップできないときの原因と対処法

Windows 10やWindows 11から、NAS、Sambaサーバー(Linux)、または旧バージョンのWindows(Windows 7 / XP / Server 2003など)が稼働するコンピューター上の共有フォルダーを開けない、あるいはネットワークドライブとしてマップできない場合、その多くは現在のWindowsでレガシーかつ安全性の低いSMBプロトコルのバージョンが無効化されていることが原因です(SMBプロトコルは、Windowsがネットワーク上の共有フォルダーやファイルへアクセスするために使用します)。

Microsoftは近年のWindowsにおいて、レガシーで安全性に問題のあるSMBプロトコルを段階的に無効化しています。Windows 10 バージョン1709以降およびWindows Server 2019(Datacenter/Standard両エディション)では、危険性の高いSMBv1プロトコルが既定で無効になり、さらにネットワーク共有フォルダーへの匿名(ゲスト)アクセスも禁止されています。

具体的な対処方法は、共有フォルダーへのアクセス時に表示されるエラーメッセージと、共有をホストしているリモート側SMBサーバーの設定内容によって異なります。以下、代表的なケースごとに解説します。

セキュリティポリシーにより未認証のゲストアクセスがブロックされ共有フォルダーに接続できない

Windows 10 ビルド1709(Fall Creators Update、Enterprise/Educationエディション)以降、「近隣のコンピューター上のネットワーク共有フォルダーを開こうとするとエラーが表示される」という報告が多数寄せられるようになりました。

ネットワーク接続の復元
Y: を \\nas1\share に再接続中にエラーが発生しました
Microsoft Windows Network: 組織のセキュリティポリシーにより、未認証のゲストアクセスがブロックされているため、この共有フォルダーにアクセスできません。これらのポリシーは、ネットワーク上の安全でない、または悪意のあるデバイスからPCを保護するのに役立ちます。

一方、同じ共有フォルダーは、Windows 8.1、Windows 7、またはビルド1709以前のWindows 10がインストールされた他のコンピューターからは問題なく開けます。これは、新しいバージョンのWindows 10(ビルド1709以降)では、SMBv2プロトコルを使用した共有フォルダーへのゲストアクセスが既定で無効になっているためです。ゲスト(匿名)アクセスとは、認証なしでネットワーク共有フォルダーへアクセスすることを指します。SMBv1/v2プロトコルでゲストアカウントを使ってネットワークフォルダーへアクセスする場合、SMB署名や暗号化といったトラフィック保護機能が使用されないため、セッションがMiTM(中間者)攻撃に対して脆弱になります。

なお、Windows 10 Homeエディションにはこの変更は適用されず、ゲストアカウントによるネットワークアクセスは引き続き動作します。

ゲストアカウントでSMB v2プロトコルを使用して共有ネットワークフォルダーを開こうとすると、クライアント側のイベントビューアーに次のようなエラーが記録されます。

ログ名: Microsoft-Windows-SmbClient/Security
ソース: Microsoft-Windows-SMBClient
イベントID: 31017
安全ではないゲストログオンを拒否しました。

このエラーは、クライアント側のコンピューターがゲストアカウントによる未認証アクセスをブロックしていることを示しています。

この問題は主に、古いNASデバイス(設定の手間を省くためゲストアクセスが有効になっていることが多い)や、匿名(ゲスト)アクセスが有効な古いWindows 7 / 2008 R2 / XP / 2003マシン上の共有フォルダーにアクセスする際に発生します。

推奨される解決策： リモート側の設定を変更する

Microsoftが推奨するのは、共有フォルダーをホストしているリモートコンピューターやNASデバイス側の設定を変更する方法です。可能であればネットワーク共有をSMBv3モードに切り替えるか、デバイスがSMBv2までしか対応していない場合は認証付きアクセスを構成してください。これが最も正しく安全な解決策です。

共有フォルダーを保存しているデバイスでゲストアクセスを無効にします。

• NASデバイス — NASの管理画面でゲストアクセスを無効にします(ベンダーや機種によって手順は異なります)。
• Linux上のSambaサーバー — smb.confの[global]セクションに以下を追加します:map to guest = neverさらに、共有フォルダーのセクションで匿名アクセスを制限します:guest ok = no
• Windowsの場合 — コントロールパネル→「ネットワークと共有センター」→「共有の詳細設定」から、パスワード保護付き共有を有効にできます。「すべてのネットワーク」の「パスワード保護共有」で「パスワード保護共有を有効にする」を選択してください。これにより匿名(ゲスト)アクセスが無効になるため、ローカルユーザーを作成し、共有フォルダーやプリンターへのアクセス権を付与したうえで、それらのアカウントを使ってリモートコンピューターの共有フォルダーに接続する必要があります。

暫定措置： クライアント側でゲストアクセスを許可する(非推奨)

もう一つの方法として、Windowsデバイス側の設定を変更し、ゲストアカウントでの共有フォルダーアクセスを許可することもできます。ただしこの方法はあくまで一時的な回避策としてのみ使用してください(!!!)。認証なしでフォルダーへアクセスできる状態は、コンピューターのセキュリティを大幅に低下させます。

グループポリシーエディター(gpedit.msc)を開き、「コンピューターの構成→管理用テンプレート→ネットワーク→Lanman Workstation」へ移動します。「安全でないゲストログオンを有効にする」ポリシーを見つけて「有効」に設定します。このポリシーは、SMBクライアントがSMBサーバーへの安全でないゲストログオンを許可するかどうかを決定します。

設定後、次のコマンドでグループポリシーを更新します:

gpupdate /force

ローカルグループポリシーエディターがないWindows 10 Homeでは、レジストリエディターから同様の変更を行えます:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters "AllowInsecureGuestAuth"=dword:1

または、以下のコマンドでも設定できます:

reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v AllowInsecureGuestAuth /t reg_dword /d 00000001 /f
reg add HKLM\Software\Policies\Microsoft\Windows\LanmanWorkstation /v AllowInsecureGuestAuth /t reg_dword /d 00000001 /f

古いSMB1プロトコルが必要なためファイル共有に接続できない

Windows 10からネットワークフォルダーへアクセスする際のもう一つの典型的な問題は、サーバー側がSMBv1プロトコルしかサポートしていないケースです。Windows 10 1709以降ではSMBv1クライアントが既定で無効になっているため、共有フォルダーを開こうとしたりネットワークドライブをマップしようとしたりすると、次のようなエラーが表示されます。

安全ではないため、ファイル共有に接続できません。この共有では、安全でない廃止予定のSMB1プロトコルが必要です。システムが攻撃にさらされる可能性があります。システムにはSMB2以上が必要です。

この場合、ローカルネットワーク上の近隣コンピューターが表示されなかったり、UNCパスで共有フォルダーを開く際に0x80070035エラーが発生したりすることもあります。

エラーメッセージから、対象のネットワーク共有フォルダーがSMBv1クライアントプロトコルしかサポートしていないことがわかります。まずはリモート側のSMBデバイスを少なくともSMBv2以上を使用するよう再設定することを試みてください(これが正しく安全な方法です)。

LinuxのSambaサーバーでファイル共有を行っている場合は、smb.confでサポートするSMBプロトコルの最小バージョンを次のように指定できます:

[global]
server min protocol = SMB2_10
client max protocol = SMB3
client min protocol = SMB2_10
encrypt passwords = true
restrict anonymous = 2

Windows 7 / Windows Server 2008 R2では、次のPowerShellコマンドでレジストリ経由によりSMB 1を無効化し、SMBv2を有効化できます:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 –Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type DWORD -Value 1 –Force

Windows 8.1 / Windows Server 2012 R2では、次のコマンドでSMBv1を無効化し、SMBv2/SMBv3を許可できます(ネットワーク接続にプライベートまたはドメインプロファイルが使用されていることを確認してください):

Disable-WindowsOptionalFeature -Online -FeatureName "SMB1Protocol"
Set-SmbServerConfiguration –EnableSMB2Protocol $true

最終手段： SMBv1クライアントを有効にする(非推奨)

ネットワークデバイス(NAS、Windows XP、Windows Server 2003など)がSMB1プロトコルしかサポートしていない場合は、Windows 10/11やWindows ServerでSMB1Protocol-Client機能を個別に有効化できます。ただし、この方法は推奨されません!!!

リモートデバイスがSMBv1を要求しており、Windows側でこのプロトコルが無効になっている場合、イベントビューアーに次のエラーが記録されます:

ログ名: Microsoft-Windows-SmbClient/Security
ソース: Microsoft-Windows-SMBClient
イベントID: 32000
説明: ローカルコンピューターがSMB1をネゴシエートできない状況で、リモートデバイスからSMB1ネゴシエート応答を受信しました。

管理者権限のPowerShellを起動し、SMB1Protocol-Clientが無効であること(State: Disabled)を確認します:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

SMBv1クライアントプロトコルを有効化します(再起動が必要です):

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

また、Windows 10/11ではoptionalfeatures.exe(Windowsの機能の有効化または無効化)から追加機能をオン/オフすることもできます。「SMB 1.0/CIFS ファイル共有のサポート」を展開し、「SMB 1.0/CIFS クライアント」を有効にしてください。

なお、Windows 10 バージョン1809以降では、SMBv1クライアントが15日以上使用されないと自動的に削除されます(「SMB 1.0/CIFS 自動削除」コンポーネントが担当)。

この例ではSMBv1クライアントのみを有効にしています。自分のコンピューターが旧クライアント向けのSMBサーバーとして共有フォルダーを提供していないのであれば、SMB1Protocol-Server機能は有効にしないでください。

SMBv1クライアントのインストール後は、共有フォルダーやプリンターへ問題なく接続できるはずです。しかし、この回避策はコンピューターのセキュリティを低下させるため、推奨されていない点は十分理解しておいてください。

共有フォルダーへのアクセス権限がないエラーが出る場合

リモートコンピューター上の共有ネットワークフォルダーへ接続する際、次のようなエラーが表示されることがあります。

ネットワーク エラー
\\PC12\Share にアクセスできません
\\PC12\Share にアクセスするアクセス許可がありません。ネットワーク管理者に問い合わせてアクセスを要求してください。

このエラーが発生した場合は、以下を確認・実施してください。

1. 共有フォルダーへのアクセスに使用しているユーザーに、リモート共有上でアクセス許可が付与されていることを確認します。サーバー上で共有フォルダーのプロパティを開き、ユーザーに少なくとも読み取り権限があるかチェックしましょう。PowerShellでリモートホストの共有アクセス許可を確認することもできます:
   Get-SmbShareAccess -Name "tools"
   続いてNTFSフォルダーのアクセス許可を確認します:
   get-acl C:\tools\ |fl
   必要に応じて、フォルダーまたは共有のプロパティでアクセス許可を編集してください。
2. ネットワークフォルダーへのアクセスに使用しているユーザー名とパスワードが正しいことを確認します。ユーザー名とパスワードの入力を求められない場合は、Windows資格情報マネージャーからリモート共有用に保存された(キャッシュされた)資格情報を削除してみてください。rundll32.exe keymgr.dll, KRShowKeyMgrコマンドを実行し、アクセス先のリモートコンピューターに関するキャッシュ資格情報を削除します。
   次回共有フォルダーへ接続する際にユーザー名とパスワードの入力を求められるので、リモートコンピューター上の共有フォルダーへのアクセス資格情報を指定してください。資格情報マネージャーに保存するか、手動で追加することも可能です。

その他の対処法： 共有フォルダーにアクセスできない場合のトラブルシューティング

ここでは、Windowsでネットワークフォルダーが開けない問題のその他のトラブルシューティング手法を紹介します。

• リモートコンピューターが、SMBプロトコル(TCPポート445)による共有フォルダーへの着信接続を許可していることを確認します。Test-NetConnectionコマンドでリモートコンピューターの445番ポートの可用性をチェックできます:Test-NetConnection -ComputerName HomePC212 -Port 445
  コマンドレットがTcpTestSucceeded : Falseを返す場合、リモートコンピューターのネットワークフォルダーへのアクセスがファイアウォールでブロックされていることを意味します。接続はサードパーティ製またはWindows Defenderファイアウォールなどのアンチウイルスソフトによってブロックされている可能性があります。Windows Defenderを使用している場合は、ファイル共有ホスト側で3つのネットワークプロファイルすべてに対して「ファイルとプリンターの共有」ルールを有効にしてください(コントロールパネル\システムとセキュリティ\Windows Defender ファイアウォール\アプリの許可)。あるいは、PowerShellでファイアウォールルールを作成することもできます:New-NetFirewallRule -DisplayName "Allow_SBM-FileSharing_In" -Direction Inbound -Protocol TCP –LocalPort 445 -Action Allow
• マップ済みネットワークドライブ(フォルダー)を開けない場合は、Windows資格情報マネージャーから保存済みのキャッシュ資格情報を削除し、マップ済みネットワークドライブを削除(Net Use * /deleteコマンド)してから再接続してみてください。
• フォルダーへアクセスする際、コンピューター名の代わりにIPアドレスを使用してみてください。例:Win+R→\\192.168.12.20→OK。
• すべてのコンピューターが同じワークグループに参加していることを確認します。PowerShellでワークグループ名を確認できます:(Get-WmiObject Win32_ComputerSystem).domain
• TCP/IPスタックの設定をリセットし、IPアドレスを更新します:
  netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew