Windows 10／11 の大型更新や累積更新のあと、「昨日まで普通に見えていた WD MyCloud や Raspberry Pi（Samba 共有）が ネットワーク から消えた」「既存の割り当てドライブは生きているのに、いったん外すと新規マッピングできない」という相談が急増しています。本記事は原因を体系立てて整理し、最短で復旧するチェックリストと、安全性を損なわない恒久対策までを具体的な画面操作・コマンド付きで解説します。
症状（よくあるパターン）
- エクスプローラーの「ネットワーク」に WD MyCloud／Raspberry Pi（Samba）が表示されない。
- 既に割り当て済みのドライブ（例：
Z:）はアクセスできるが、切断後に再マッピングができない。 - Windows 11 では以前あった「Mount Public Share（パブリック共有のマウント）」相当の導線が見当たらず、「資格情報（ユーザー名／パスワード）」を求められる。
- Android（SMB 対応ファイルアプリ等）や他 OS からは問題なく見えるので、NAS／Pi の故障ではなさそう。
背景：Windows 10／11 のセキュリティ強化が前提を変えた
Windows は段階的に SMB（ファイル共有プロトコル）の安全性を引き上げています。代表的な変化は次の通りです。
| 変更点 | 影響 | 困る機器の例 |
|---|---|---|
| SMB 1.0 が既定で無効（サーバー成分は削除傾向） | SMB1 前提の NAS／古い Samba は探索・接続とも失敗 | 旧世代 WD MyCloud（初期モデル等）、古い Samba 設定の Raspberry Pi |
| SMB 署名（デジタル署名）の既定強化 | 署名非対応／未署名の接続は拒否。資格情報ループが起きることも | SMB2 未満、または署名を無効にしている Samba/NAS |
| ネットワーク探索まわりの既定やサービス動作の見直し | Function Discovery 系サービス停止や「パブリック」プロファイル化で見えなくなる | 家庭内 LAN でよく発生 |
まずはこれだけ：最短復旧チェックリスト
時間がない方は、下の順に上から実施してください。途中で見える／つながるようになった時点で終了して構いません。
- ネットワーク探索と共有を有効化
設定 > ネットワークとインターネット > 共有の詳細設定で「ネットワーク探索」「ファイルとプリンターの共有」をオン。ネットワーク プロファイルが「プライベート」になっているかも確認。
services.msc を開き、次の 4 サービスを「自動（遅延開始）」＋「開始」状態に：
・Function Discovery Provider Host（fdPHost）
・Function Discovery Resource Publication（FDResPub）
・SSDP Discovery（SSDPSRV）
・UPnP Device Host（upnphost） - IP 直打ちで手動マッピング
エクスプローラーの「…（詳細）」>「ネットワークドライブの割り当て」で\\<NASやPiのIP>\<共有名>を指定。例：\\192.168.1.50\Public。探索に頼らず接続を試す。 - SMB1 を使わない方向でサーバー側を更新
Raspberry Pi の/etc/samba/smb.confに最小プロトコルを SMB2 以上へ統一（設定例は後述）。WD MyCloud も可能なら最新ファームと SMB2/3 を有効に。 - 資格情報を整理
コントロール パネル > 資格情報マネージャーで、古い NAS 向け Windows 資格情報を削除。必要なら\\<IP>形式で新しい資格情報（例：ユーザー名admin）を追加。 - （どうしても必要な場合のみ）SMB 署名「常に」を無効化
互換性が理由で接続だけでも急ぎたいとき。企業ネットワークや機密データでは非推奨。恒久対応は NAS/Samba を更新すること。 - （最終手段）SMB1 クライアントを一時的に有効化
対応更新が不可能な旧機器に限定。使い終わったら必ず無効化する。
原因と対処を体系化（詳細ガイド）
ネットワーク探索がオフ／関連サービス停止
Windows Update 後にネットワーク プロファイルが「パブリック」に戻る、Function Discovery 系サービスが停止する等で、ネットワーク 一覧からデバイスが消えます。これは「見つけられない」だけで、実体は動いています。
| 確認箇所 | 手順 | 備考 |
|---|---|---|
| ネットワーク プロファイル | 設定 > ネットワークとインターネット > Wi-Fi／Ethernet > 接続のプロパティ > ネットワークプロファイル「プライベート」 | 「パブリック」のままだと探索が制限される |
| 共有の詳細設定 | 設定 > ネットワークとインターネット > 共有の詳細設定で「ネットワーク探索」「ファイルとプリンターの共有」をオン | 更新でオフに戻ることがある |
| Function Discovery など | services.msc で fdPHost／FDResPub／SSDPSRV／upnphost を「自動（遅延開始）」＋「開始」に | 一度停止すると探索に出てこない |
PowerShell で一括確認する場合：
Get-Service fdPHost,FDResPub,SSDPSRV,upnphost | Select-Object Name, Status, StartType
名前解決の問題を回避：IP 直指定でマッピング
ネットワーク探索は WSD/WS-Discovery、NetBIOS、mDNS など複数方式が絡み、1 つでも不調だと一覧に出ません。そこで探索を迂回して、IP アドレス直指定でマッピングします。
- エクスプローラーを開き、右上の「…」>「ネットワークドライブの割り当て」。
- フォルダー欄に
\\192.168.1.50\Publicのように入力。 - 「ログオン時に再接続」にチェック。必要なら「別の資格情報を使用して接続する」にチェック。
コマンドで行う場合：
net use Z: \\192.168.1.50\Public /persistent:yes
なお、NAS の IP はルーターで DHCP 予約（固定割り当て）にしておくと再接続が安定します。
SMB 署名（Always）要件と資格情報ループ
Windows 側が「クライアントは常に署名する」を求める一方、NAS/Samba が署名を使わない（または SMB1 のみ）と、資格情報入力を繰り返しても拒否されます。恒久解はサーバー側を SMB2/3 ＋署名対応にすることです。どうしても暫定でつなぐ必要がある場合のみ、自己責任でクライアントの「常に署名」要求を無効化します。
方法 A：セキュリティ オプションで無効化（推奨手順）
管理者権限で secpol.msc（または gpedit.msc から同階層）を開き、次を 無効 にします。
- コンピューターの構成 > Windows の設定 > セキュリティ設定 > ローカル ポリシー > セキュリティ オプション
Microsoft ネットワーク クライアント: 通信に常にデジタル署名を行う
必要に応じてサーバー側も：
- Microsoft ネットワーク サーバー: 通信に常にデジタル署名を行う＝無効
注意： 署名は改ざん検出の基本機能です。恒久的には NAS/Samba を更新し、署名の無効化は元に戻してください。
方法 B：Home エディションでポリシー UI を追加
Windows Home は既定でポリシー エディターがありません。オプション機能として「Group Policy Client Tools / Client Extensions」を追加できます（管理者権限 PowerShell）。
Add-WindowsCapability -Online -Name 'Microsoft-Windows-GroupPolicy-ClientTools~~~~0.0.1.0'
Add-WindowsCapability -Online -Name 'Microsoft-Windows-GroupPolicy-ClientExtensions~~~~0.0.1.0'
追加後に gpedit.msc を実行し、前節と同じポリシーを無効化します。
方法 C：レジストリで直接切り替え（UI なしでも可）
ポリシー UI を使えない環境向けに、レジストリで 一時的に 解除する方法です（管理者権限・再起動要）。
reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters ^
/v RequireSecuritySignature /t REG_DWORD /d 0 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters ^
/v RequireSecuritySignature /t REG_DWORD /d 0 /f
戻す場合は /d 1 にします。
Raspberry Pi（Samba）側を更新：SMB1 を使わない設定
サーバー側を SMB2/3 基準に整えるのが根本解です。Raspberry Pi での例：
# （推奨）Samba を最新化
sudo apt update
sudo apt install -y samba
# 設定編集
sudo nano /etc/samba/smb.conf [global] セクションに以下を追加／調整します。
[global]
server min protocol = SMB2
client min protocol = SMB2
server signing = auto
map to guest = Bad User
# 必要に応じて
# smb encrypt = desired
保存後に再起動：
sudo systemctl restart smbd nmbd
共有定義（例）：
[public]
path = /srv/public
browseable = yes
read only = no
guest ok = yes
補足： 古い記事にある ntlm auth = yes は NTLMv1 を許可する危険な設定です。現在は推奨されません。
WD MyCloud 側の確認ポイント
- 可能なら最新ファームウェアへ更新し、SMB2/3 を有効にする。
- 「Public」共有はゲスト接続になる場合があり、Windows 側がゲストをブロックして資格情報を要求することがある。
対処 A：MyCloud 側にユーザーを作成し、そのユーザーで接続する。
対処 B：やむを得ない場合のみ、Windows の「Lanman Workstation: Enable insecure guest logons」を有効にする（企業・機密用途では非推奨）。
ポリシーの場所（参考）：
コンピューターの構成 > 管理用テンプレート > ネットワーク > Lanman ワークステーション > 安全でないゲスト ログオンを有効にする
資格情報マネージャーを整理
保存済みの資格情報が古い形式（デバイス名、NetBIOS 名など）で残っていると、IP 指定接続と競合することがあります。
- コントロール パネル > 資格情報マネージャー > Windows 資格情報。
\\NAS名や\\192.168.1.50など該当のエントリを削除。- マッピング時に「別の資格情報」で
\\<IP>を対象としたユーザー名・パスワードを登録。
SMB1 を一時的に有効化（最終手段）
脆弱性リスクが非常に高いため、恒久運用は推奨しません。「どうしても古い機器からデータを退避する間だけ」など、用途と期間を限定してください。
# 有効化（クライアントのみ）
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client -All
# 状態確認
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol* 作業後は必ず無効化します。
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client
トラブル切り分けの実践テクニック
ネットワーク到達性とポート 445 を確認
# ICMP 到達性（応答しない設定の NAS もある点に注意）
ping 192.168.1.50
# SMB ポート（445/TCP）の疎通を確認
Test-NetConnection -ComputerName 192.168.1.50 -Port 445 ファイアウォールで ファイルとプリンターの共有（SMB-In） が許可されているかも確認しましょう（wf.msc）。
エラーコードから当たりを付ける
| 現象／エラー | 主な原因 | 対処 |
|---|---|---|
| 資格情報を何度入れても弾かれる（無限ループ） | SMB 署名要件と NAS 側の不一致、ゲスト拒否 | 署名設定の一致化／NAS 側ユーザー作成／ゲスト許可の是非を見直し |
| 「指定されたネットワーク名は利用できません（エラー 67）」 | 名前解決失敗、共有名の誤り、SMB1 のみ | IP 直指定、共有名確認、SMB2 以上へ更新 |
| 「ネットワーク パスが見つかりません（エラー 53）」 | 到達性／ポートブロック、ファイアウォール | 445/TCP 確認、FW の SMB 例外、LAN 内ルーティング確認 |
| 「アクセスが拒否されました」 | 資格情報の不一致、権限不足 | 資格情報マネージャーの再登録、NAS 側共有権限を再設定 |
イベント ログで SMB の原因を掘る
イベント ビューアー > アプリケーションとサービス ログ > Microsoft > Windows > SMBClient（Operational/Security）を見ると、署名や暗号の交渉失敗が記録されます。原因が 署名 なのか プロトコル バージョン なのか、根拠を持って判断できます。
Windows 11 の UI 変更に伴う操作のコツ
- エクスプローラーのリボンから消えた項目は、タイトルバー右側の「…」メニューに移動している場合があります。「ネットワークドライブの割り当て」もそこにあります。
- 設定 内の共有項目は「共有の詳細設定」へ集約。家庭内 PC では「プライベート ネットワーク」に切り替えるだけで解決する例が多いです。
運用のベストプラクティス（安全性と再発防止）
- SMB1 廃止を前提に計画：SMB2/3 に未対応の機器は退役またはアップデート。どうしても残す場合は VLAN 分離などで被害半径を限定。
- 署名は基本オン：恒久運用では Windows/NAS/Samba すべてで署名（できれば暗号化も）を統一。暫定で無効化したら必ず元に戻す。
- NAS に個別ユーザー：ゲスト共有より、ユーザーごとにパスワードを設定。資格情報マネージャーに保存して UX も改善。
- IP を固定：ルーターで DHCP 予約（例：MyCloud＝192.168.1.50、Pi＝192.168.1.60）。マッピングは
\\IP\共有で作成。 - スクリプトで自動復旧：更新でポリシーやサービスが戻ることがあるため、起動時に確認・補正するスクリプトを用意。
起動時にドライブを確実に再接続するスクリプト例
# Map-NASDrives.ps1（管理者不要／タスク スケジューラからユーザー権限で実行）
$targets = @(
@{Letter='Z:'; Path='\\192.168.1.50\Public'},
@{Letter='Y:'; Path='\\192.168.1.60\share'}
)
foreach ($t in $targets) {
if (Test-Path $t.Letter) { Remove-PSDrive -Name $t.Letter.TrimEnd(':') -Force -ErrorAction SilentlyContinue }
New-PSDrive -Name $t.Letter.TrimEnd(':') -PSProvider FileSystem -Root $t.Path -Persist | Out-Null
} ケース別：これで解決した実例レシピ
ケース 1：WD MyCloud（旧モデル）で「Public に入れない」
現象：Windows 11 更新後、Public に入ると資格情報を要求され、admin でも失敗。Android からは閲覧可能。
解決：
- MyCloud に「ユーザー：
pcuser」を作成し、Public への読み取り権限を付与。 - Windows の資格情報マネージャーで
\\MyCloudのIPにpcuserを登録。 - エクスプローラーで
\\<IP>\PublicをZ:に割り当て。
これで署名やゲスト制限に左右されず安定化。
ケース 2：Raspberry Pi（Samba）だけ見えないが、\\IP なら開く
現象：ネットワーク一覧に出ない。\\192.168.1.60 を直打ちすると開ける。
解決：Windows 側で Function Discovery（FDResPub）を自動＋開始、Pi 側で nmbd を起動しなおし。必要に応じて avahi-daemon（mDNS）も導入。一覧に出ない＝壊れているではない点に注意。
ケース 3：更新直後から突然つながらない（複数 PC 共通）
現象：複数の Windows 11 PC で同時にマッピングが失敗。Android は接続可。
解決：SMB 署名要件の変更により、未署名の NAS が一斉に拒否されていた。暫定で「クライアント：常に署名」を無効化し、並行して NAS ファームを更新して署名を有効化。更新完了後にポリシーを元へ。
確認・復旧のための Windows コマンド集
# SMB クライアントの現設定（署名要件など）
Get-SmbClientConfiguration
# ネットワーク共有一覧（見つからないときの参考）
net view
# 特定ホストの共有一覧
net view \192.168.1.50
# 現在のドライブ マッピング
net use
# マッピング作成（永続）
net use Z: \192.168.1.50\Public /persistent:yes
# Function Discovery 周辺のサービス状態
Get-Service fdPHost,FDResPub,SSDPSRV,upnphost セキュリティ上の注意点（必読）
- SMB1 は原則禁止：どうしても使う場合は隔離ネットワークで、必要最小限の時間だけ。
- 署名の無効化は暫定措置：移行が済み次第、元に戻す（クライアント／サーバーとも）。
- ゲスト共有は避ける：ユーザーごとにパスワードを設定し、共有ごとにアクセス権を明示。
- 更新のたびに再確認：Windows Update でポリシーやサービスが初期化されていないか点検。
よくある質問（FAQ）
Q：Android からは見えるのに、Windows だけダメなのはなぜ？
A：Android の SMB クライアントは SMB1～3 を柔軟に話せるものが多く、署名の既定も緩いことがあります。Windows 側のセキュリティ強化に旧機器が追随できていないのが原因です。
Q：「ネットワーク」に出てこない＝壊れている？
A：違います。「探索に出ない」だけで、\\IP\共有 で普通に開けるケースが大半。まずは IP 直打ちで検証しましょう。
Q：SMB 暗号化（SMB3 Encryption）を使うべき？
A：安全性は上がりますが CPU に負荷がかかります。家庭内の信頼できる LAN なら署名（Integrity）で十分な場面も。要件と性能のバランスで判断を。
チェックと対処を 1 ページで振り返り
| 手順 | 操作 | ポイント |
|---|---|---|
| ① ネットワーク探索を有効化 | 共有の詳細設定で探索と共有をオン。fdPHost／FDResPub／SSDPSRV／upnphost を自動＋開始 | まずはネットワーク一覧に再表示させる |
| ② IP 指定で手動マッピング | \\<デバイスIP>\<共有名> を指定して割り当て | 探索の問題を迂回できる |
| ③ SMB を見直す | SMB1 を使わず、Samba/NAS を SMB2/3 に統一 | 恒久対策の本丸 |
| ④ 署名「常に」を無効化（暫定） | ローカル ポリシー（またはレジストリ）で解除 | 接続は復旧しやすいが恒久運用は非推奨 |
| ⑤ 資格情報を整理 | 古いエントリ削除、\\IP 形式で登録 | パスワード要求ループの解消 |
| ⑥ ドライブ文字を固定 | net use Z: \\IP\共有 /persistent:yes | 再起動後も安定接続 |
まとめ
- 見えない＝探索サービス or 名前解決の問題。まずは「プライベート」化と Function Discovery の再有効化、そして
\\IP\共有の手動マッピング。 - 接続できない＝SMB バージョン／署名不一致。根本解は NAS／Samba を SMB2/3＋署名対応に更新。暫定の緩和（署名「常に」無効や SMB1 有効）は短期限定で。
- 資格情報の整頓と IP 固定 で、更新後も安定して再接続できる環境をつくる。
この手順を押さえておけば、Windows の更新後でも WD MyCloud や Raspberry Pi の共有フォルダーを従来どおりドライブとして快適に利用できます。
コメント