Windows11のある一台のPCからサーバにアクセス出来なくなったという連絡を受けて対処を実施することになったのでご報告です。
エラーの内容
エラーがあったのはあるユーザPC、sambaサーバである共有フォルダへアクセス出来なくなったという連絡から、対処をすることになりました。
対象のPCはWindows11 24H2です。いつからそうなったかは不明ですが現状はエラーが発生するため対処が必要という状況です。
そのWindows11ではデスクトップ上に共有フォルダをホストするsambaサーバへのショートカットを作成しており、そのショートカットをダブルクリックで共有フォルダの一覧をエクスプローラに表示します。
このショートカットをダブルクリックで開くと、共有フォルダの一覧が表示されるはずですが、そのPCでは
このようにエラーが表示されてしまいました。
エラーメッセージは
「名前のスペルを確認しても問題がない場合は、ネットワークに問題がある可能性があります。ネットワークの問題を識別して解決するには、[診断] をクリックします。」
「エラー コード: 0x80070035」
「ネットワーク パスが見つかりません。」
が発生します。
ちなみにこの環境はワークグループ環境です。Active Directoryではないので内部DNSサーバは存在していません。インターネット接続用のDNSサーバは存在していますが。
調べる
まず切り分けとして、他のPCからこのサーバの共有フォルダが閲覧できているためsambaサーバ上の設定については問題ないと切り分けます。sambaサーバの問題という可能性を除外すると、PCに要因があるということになります。
sambaサーバの共有フォルダへ接続できない要因の前にネットワークの疎通確認から。
ping ホスト名で疎通確認はできたので名前解決なども含めて通信の問題はないと判断していますが、以下のようなping実行結果となりました。
※画像は一部表示を改変しています。
sambaサーバのホスト名FSVR2へのpingは最初うっかりオプションを付けずに実行したのですが、FSVR2.localに名前解決されてIPv6ですが応答が返っています。で、二回目にちゃんとIPv4の「-4」オプションを指定して、sambaサーバのIPv4アドレスから応答が返ってくることが確認できました。通信の問題はないと考えられます。
通信は問題ないと判断できたので、試しにと<\\192.168.0.1>（IP直指定）でsambaサーバを開いてみたところ、特に問題なくフォルダの一覧が表示できました。ただ相変わらず<\\FSVR2>でのアクセスは前述のエラーとなります。うーん。
Test-NetConnection hostname -Port 445で確認
PowerShellコマンドレット「Test-NetConnection hostname -Port 445」で接続を確認してみました。（昔のtelnet:ポート番号で接続確認をするのと同じ仕組みです。）
SMB接続は445番のポートを確認すればいいので、「-Port 445」を付加します。
やってみました。
「TcpTestSucceeded : True」を確認できましたので、SMB接続に問題のないことははっきりしましたが、ホスト名解決がIPv6アドレス（fe80::～）になっているのが気になるところです。Windows11がSMB接続をIPv6で実行しようとしているのが要因、ということでしょうか。
対処方法：伝統のhostsファイルでIPv4アドレスを解決する
コマンドpingで応答のあるアドレスがIPv6、ワークグループ環境で同一ネットワークアドレスにPCとサーバが存在しているのでDNS不要でアクセス自体は可能なはず。実際IPv4アドレスを指定して共有フォルダにアクセスが出来ています。
ということはホスト名を指定した時だけエラーになる＝IPv6アドレスが名前解決されている、という動きが要因と思われます。Test-NetConnectionの実行結果からもIPv6アドレスが表記されていることからも関係ありそうです。WindowsはIPv6のリンクローカルアドレスで名前解決されているということです。
DNS/LLMNRでの名前解決自体はできているので、これをIPv4で解決するように設定を入れることにします。PC単体での設定はhostsファイルを使用します。（NetBIOS over TCP/IPの名前解決を有効化すればいいんじゃないかと後で思ったのですが、後の祭りです。）
hostsファイルの場所は
<C:\Windows\System32\drivers\etc\hosts>
にあります。ファイルの編集には管理者として実行したテキストエディタが必要です。
ファイルの末尾に
192.168.0.1 FSVR2
を追記しました。参考までにこんな感じです。
--------------------------------------------------------------
C:\Windows\System32\drivers\etc\hosts
--------------------------------------------------------------
--------------------------------------------------------------
hostsファイルに該当のIPとホスト名を記述しました。特にOS再起動やサービスのリスタートなどは実行することなくその後にpingの実行結果はIPv4で返答があることを確認しました。
上図のようにオプションなしでpingをしたらhosts設定前と違ってIPv4から応答がありました。さらに名前解決したホスト名のところがFSVR2.localじゃなくてFSVR2に変化しています。hostsファイルで指定した効果が見て取れます。
この状態で<\\FSVR2>でのアクセスはエラーとならず、共有フォルダの一覧が表示されるようになりました。これで問題は解消ということでユーザに返しました。
もうちょっと解説
hostsファイルを設定する前にFSVR2.localと名前解決されていたので、mDNSあたりで名前解決されていたと考えることができます。
※参考：（以前の記事）
DNS以外の名前解決でホスト名からIPを探す - treedown’s Report
mDNS（マルチキャストDNS）に興味 - treedown’s Report
hostsファイル設定後はFSVR2.localじゃなくてhostsファイルで指定したFSVR2となったので、DNSよりもhostsが優先されたということだと考えています。
hostsとDNSがNetBIOS over TCP/IPの名前解決より優先されるのは以前のWindowsからの仕様なので、mDNSで適切に名前解決が出来ていないようであればhostsファイルを使うというのが第一段階と言えそうです。
■参考：Microsoft TCP/IP のホスト名解決の順序
https://support.microsoft.com/ja-jp/topic/microsoft-tcp-ip-%E3%81%AE%E3%83%9B%E3%82%B9%E3%83%88%E5%90%8D%E8%A7%A3%E6%B1%BA%E3%81%AE%E9%A0%86%E5%BA%8F-dae00cc9-7e9c-c0cc-8360-477b99cb978a
