Windows 11からNASに接続しようとしたとき、「サーバー名（\\nas01）はつながるのに、IPアドレス（\\192.168.1.10）は認証エラーになる」という相談は意外と多くあります。しかも同じPCの別ユーザーや別PCからは問題なくアクセスできるため、原因が分かりづらいパターンです。本記事では、Windows 11 と TrueNAS/SMB の組み合わせで実際に発生したケースをベースに、原因の考え方と再発しにくい解決手順を整理して解説します。
現象の概要：IPアドレスだけ認証エラーになる SMB 接続トラブル
今回のケースは、次のような状況でした。
- NAS：TrueNAS（SMB 共有）
- クライアント：Windows 11
- 問題が出るのは「特定ユーザーのプロファイル」でログオンしたときだけ
- エクスプローラーで
\\<サーバー名>なら無人で接続できる - しかし
\\<IPアドレス>にアクセスすると資格情報を求められ、正しく入力しても拒否される - 同じPCの別ユーザーや、別PCからは
\\<IPアドレス>でも問題なく接続できる - TrueNAS 側のログには目立ったエラーなし
一見すると「NAS 側のユーザー設定が怪しい」と感じますが、同じアカウントでも別PCや別ユーザープロファイルからは接続できることから、原因はWindows クライアント側の「特定ユーザープロファイル」内にあると絞り込めます。
特にポイントになるのは、次の2点です。
- SMB は「接続先の識別子（名前・FQDN・IP）」ごとに別セッションとして扱う
- Windows はユーザープロファイル単位で資格情報やネットワーク接続のキャッシュを保持している
つまり、同じ TrueNAS であっても \\nas01 と \\192.168.1.10 は、Windows の中では別サーバーとして扱われるため、IP側だけ資格情報やセッションが壊れていると、今回のような「名前ならOK、IPはNG」が起こり得ます。
なぜ「\\名前」と「\\IP」で挙動が変わるのか
まずは仕組みを押さえておくと、原因のイメージが掴みやすくなります。
SMB 接続は「接続先ごと」に資格情報が管理される
Windows の SMB クライアントは、内部的に「接続先識別子（ターゲット名）」単位でセッションを貼ります。大雑把に言うと、
\\nas01\\nas01.example.local\\192.168.1.10
はすべて別セッションです。これに紐づいているのが、
- 資格情報マネージャーに保存された資格情報
net useで張られた永続的なネットワークドライブ/セッション- Kerberos/NTLM などの認証トークン
です。同じ NAS でも「名前でつないだセッション」と「IPでつないだセッション」は独立しているため、片方だけ壊れたり不整合が起こることがあります。
名前接続と IP 接続で変わるポイントを整理
代表的な違いを表にまとめると、次のようになります。
| 項目 | \\サーバー名（NetBIOS/FQDN） | \\IPアドレス |
|---|---|---|
| 識別子 | \\nas01 / \\nas01.example.local | \\192.168.1.10 |
| DNS / NetBIOS 解決 | 必要（名前解決が遅いと接続も遅くなる） | 不要（直接IP指定） |
| 認証方式 | ドメイン環境では Kerberos になりやすい | 多くの場合 NTLM にフォールバック |
| 資格情報のスコープ | nas01 用に別管理 | 192.168.1.10 用に別管理 |
| トラブルの典型例 | 名前解決の遅延、SPNミスマッチなど | 資格情報の衝突や古い接続が残っている |
今回のように「名前なら何事もなくアクセスできる」場合、認証自体は成功しており、TrueNAS 側のユーザーやパスワードがおかしい可能性は低いと考えられます。むしろ、
- IPアドレス向けにだけ、壊れた資格情報が残っている
- IPアドレス向けのセッションが中途半端な状態で張りっぱなしになっている
といった、クライアント側の「ゴミ」が疑わしい状況です。
優先度順の解決アプローチ
ここからは、実際の対処手順を優先度順に整理していきます。いきなりユーザープロファイルを消すのはリスクが大きいので、まずは安全な手順から順番に試していくのがおすすめです。
| 優先度 | 対応内容 | 想定所要時間 | データ消失リスク |
|---|---|---|---|
| 高 | 資格情報マネージャーの該当項目を削除 | 5〜10分 | ほぼなし |
| 中 | net use で永続接続をクリア | 5分 | なし（ドライブ再接続は必要） |
| 低（最終手段） | ユーザープロファイル再作成 | 30〜60分 | 大（事前バックアップ必須） |
1. Windows 資格情報のリセット（該当ユーザーで実施）
まず試したいのは、資格情報マネージャーに保存されている SMB 関連の資格情報を一度リセットする方法です。
- 問題が出ているユーザーで Windows にログオンします。
- スタートメニューを開き、「資格情報マネージャー」と入力して起動します。
- 「Windows 資格情報」タブを開きます。
- 一覧の中から、TrueNAS に関連しそうな項目を探します。
- ターゲット名に
\\192.168.x.xなどのIPアドレスが含まれるもの \\nas01や\\truenasなど、NASのサーバー名が含まれるもの
- ターゲット名に
- 該当しそうな項目を一つずつ選択し、「削除」をクリックします。
- いったん Windows を再起動します。
- 再起動後、エクスプローラーで
\\<IPアドレス>にアクセスし、資格情報を求められたら TrueNAS の正しいユーザー名・パスワードを入力します。- 必要に応じて「資格情報を記憶する」にチェックを入れます。
ポイントは、「IP用」と「名前用」で別々の資格情報が保存されている場合、それぞれを一度リセットすることです。特に過去に設定変更（NAS側のユーザー名やパスワード変更）を行った場合、古い情報が残りやすくなります。
2. 永続的なネットワーク接続のクリア（net use）
資格情報マネージャーをきれいにしても改善しない場合、net use コマンドを使って SMB セッションを一掃してみましょう。管理者権限は不要です。
- スタートメニューから「cmd」または「コマンド プロンプト」を検索し、通常起動します。
- 現在張られているネットワーク接続を確認します。
net use
ここで、
\\<IPアドレス>\共有名\\<サーバー名>\共有名
といった接続が残っていないか確認します。特に「状態」が OK 以外になっている項目や、古そうな接続が見つかった場合は、一度すべて削除してしまうのが手っ取り早いです。
- すべての SMB セッションを削除するには、次のコマンドを実行します。
net use * /delete
「この操作を続行しますか？」と確認された場合は Y を入力して Enter を押します。
- コマンド実行後、再度
net useを実行し、一覧が空（または必要最小限の接続のみ）になっていることを確認します。 - エクスプローラーで
\\<IPアドレス>へ接続を試し、資格情報を入力して挙動を確認します。
この手順により、IPアドレス向けに張られていた壊れたセッションや、古いマッピングが一度リセットされます。特に、過去にネットワークドライブとして割り当てていた場合や、複数のユーザー名で同じ NAS に接続した履歴がある場合は効果的です。
3. どうしても直らないときの最終手段：ユーザープロファイル再作成
上記の「資格情報の削除」と「net use のクリア」を行っても改善しない場合、問題の原因はさらに深い場所、つまりユーザープロファイル内の何らかのキャッシュや設定ファイルの破損にある可能性が高くなります。
実際に、本記事の元となったケースでは、最終的にユーザープロファイルの再作成によって問題が解消しました。
ユーザープロファイル再作成の流れ
大枠の手順は次の通りです。
- 問題のユーザーでログオフする。
- 管理者アカウント（ローカル管理者またはドメイン管理者）でログオンする。
C:\Users\<対象ユーザー名>配下の必要なデータを別フォルダーに退避しておく。- デスクトップ、ドキュメント、ダウンロードなど
- ブラウザのプロファイルやアプリの設定など、必要に応じてバックアップ
- 「システムの詳細設定」からユーザープロファイルを削除する。
- 対象ユーザーで再度ログオンし、新しいプロファイルを作成させる。
- バックアップしておいたデータを、新しいプロファイル配下に戻す。
- エクスプローラーで
\\<IPアドレス>接続をテストする。
ユーザープロファイル削除の具体的な操作
管理者としてログオンした状態で、次のように操作します。
- 「設定」→「システム」→「バージョン情報」を開く。
- 右側（または下部）の「システムの詳細設定」をクリック。
- 「ユーザープロファイル」欄の「設定」ボタンをクリック。
- 一覧から問題のユーザーを選択し、「削除」をクリック。
削除すると、次回そのユーザーでログオンしたときに、C:\Users\<ユーザー名> 以下が新規に作り直されます。この中には、
- アプリの設定
- キャッシュファイル
- 各種認証情報・一部のログオン情報
など、多くの「見えない設定」が含まれているため、何かが壊れていた場合でもまとめてリセットできます。
もちろん、プロファイル削除はリスクが大きいため、必ず事前にユーザーデータのバックアップを取り、業務影響の少ないタイミングで実施してください。
追加の診断テクニック：原因をもう一歩掘り下げる
上記の対応で改善するケースが多いですが、「なぜこうなるのか」をもう少し掘り下げておくと、今後のトラブル対応や設計にも役立ちます。
明示的なユーザー指定での接続検証（net use）
「どの資格情報が使われているのか」を切り分けるために、net use で明示的にユーザーを指定して接続を試す方法があります。
net use \\<IPアドレス>\<共有名> /user:<サーバー名またはワークグループ>\<ユーザー名>
例：
net use \\192.168.1.10\share /user:TRUENAS\labuser
net use \\192.168.1.10\share /user:[email protected]
この方法で接続が成功する場合、少なくとも
- TrueNAS 側のユーザー・パスワード設定は正しい
- ネットワーク経路やファイアウォールにも大きな問題はない
と言えます。つまり、エクスプローラーでの通常アクセス時に使われている「自動選択された資格情報」や「キャッシュされたセッション」が怪しい、という絞り込みができます。
cmdkey で保存済み資格情報を一覧・削除する
GUI の資格情報マネージャーだけでは分かりづらい場合、コマンドラインから資格情報の一覧を見ることもできます。
cmdkey /list
ここに、NAS の IP アドレスやサーバー名が含まれている項目があれば、
cmdkey /delete:<ターゲット名>
で削除可能です。とはいえ、SMB 接続に関しては GUI の方が分かりやすいので、日常的な運用では「資格情報マネージャー」での削除をメインにし、cmdkey は「どうしても謎のエントリが消えない」ときの補助として使うイメージで良いでしょう。
Kerberos / NTLM の違いを意識する（klist）
ドメイン参加している PC であれば、\\サーバー名 で接続した場合に Kerberos が使われ、\\IPアドレス では NTLM が使われることが多くなります。認証方式の違いに起因するトラブルを切り分けるために、Kerberos チケットをクリアしてから再接続を試す方法があります。
klist purge
上記を実行後、いったんログオフ・再ログオンしてから再度接続を試します。これにより、古い Kerberos チケットが原因で発生している問題をリセットできます。
ただし、今回のように「名前では問題なし、IPだけNG」の場合、Kerberos 側はむしろ正常で、IP側（NTLM側）の資格情報・セッションが壊れているパターンが多いため、優先度としては資格情報や net use のクリアのほうが上になります。
名前解決が遅くて IP でアクセスしたくなる場合の対処
そもそも、「わざわざ IP アドレスで接続しているのは、名前解決が遅いから」というケースもよくあります。この場合、根本的には名前解決の改善を図った方が長期的に楽になります。
- DNS に NAS の Aレコードを登録する
- 例：
nas01.example.local → 192.168.1.10 - TTL を適切に設定し、クライアントが安定して名前解決できるようにする
- 例：
- クライアント側の DNS 設定を整理する
- 不要・無効な DNS サーバーが設定されていないか確認
- 検索サフィックスの設定が過剰でないか確認
- 短期的な対処として hosts ファイルに登録
C:\Windows\System32\drivers\etc\hostsに192.168.1.10 nas01のように追記- ただし台数が多い環境では管理コストが高くなるため、恒久対策には向きません
IPアドレスで接続したくなる気持ちは分かりますが、SMB の世界では「名前とIPが別セッションとして扱われる」ことが厄介な原因になりがちです。可能であれば、「原則は名前（FQDN）で接続する」というルールに寄せていくと、トラブルの芽を減らせます。
再発防止のポイント：資格情報のスコープを意識した運用
今回のような問題を防ぐための運用ポイントを、いくつか挙げておきます。
同じNASへ「\\名前」と「\\IP」を混在させない
もっとも重要なのは、同じ NAS に対して「\\nas01」と「\\192.168.1.10」を同時に使わないことです。これをやってしまうと、Windows 内部で次のような状態が起こり得ます。
- 同じ NAS に対して異なるユーザー名で接続しようとして資格情報が衝突する
- 片方のセッションが切れているのに、もう片方は生きていて混乱する
- どの接続でどの権限が使われているのか分かりづらくなる
複数人で共有する PC や、複数の NAS を扱う現場では、
- 社内標準として「NAS は必ず
\\nas01.example.local形式で接続する」 - ドキュメントや配布資料、バッチファイルでも統一した表記を使う
といったルールを決めておくと、こうしたトラブルをかなり減らせます。
問題が特定ユーザーに限定されるときの「お約束ルーティン」
「同じPCの別ユーザーでは再現しない」「他のPCでは問題なし」といった状況になった場合、まずは次の3つをルーティンとして実施すると切り分けがスムーズです。
- 資格情報マネージャーで NAS 関連の資格情報を削除
net use * /deleteで SMB セッションをクリア- それでも改善しなければ、ユーザープロファイルの再作成を検討
この流れを「テンプレ」として覚えておくと、TrueNAS だけでなく、他ベンダーの NAS や Windows ファイルサーバーでも応用できます。
TrueNAS 側で確認しておきたい最低限のポイント
本記事は主に Windows 側に焦点を当てていますが、念のため TrueNAS 側で確認しておきたいポイントも簡単に触れておきます。
- SMB サービスが正常に起動しているか
- 対象ユーザーが SMB 共有の ACL で必要な権限（読み/書き）を持っているか
- パスワードを最近変更している場合、Windows 側で古い資格情報が残っていないか（→ 本記事の手順が有効）
- 同じユーザーで別PCからは問題なく接続できるか
特に、別PCからは同じユーザーで問題なく接続できるのであれば、TrueNAS 側ではなくWindows クライアント固有の問題とほぼ断定できます。その場合は、本記事で紹介した Windows 側の対応に集中して問題ありません。
まとめ：原因と解決策をひとことで振り返る
最後に、本記事のポイントをコンパクトに振り返ります。
- 原因の本質：
- SMB は「\\名前」と「\\IP」を別々の接続先として扱う
- 問題のユーザープロファイル内で、
\\IP宛ての資格情報やセッションが破損していた可能性が高い
- 解決の流れ：
- 資格情報マネージャーで NAS 関連の資格情報を削除する
net use * /deleteで永続的なネットワーク接続をクリアする- それでも改善しない場合は、ユーザープロファイルを再作成する（本ケースではこれが決め手）
- 運用上のポイント：
- 同じ NAS に対して
\\名前と\\IPを混在させない - できるだけ「サーバー名（FQDN）で接続する」運用を標準化する
- 特定ユーザーだけおかしい場合は、まず資格情報と
net useのクリアを routine にする
- 同じ NAS に対して
「IPでは接続できないがサーバー名なら接続できる」という現象は、一見すると NAS やネットワークの問題に見えますが、実際にはWindows のユーザープロファイルに閉じた資格情報やセッションの不整合であることが少なくありません。仕組みを理解しておくことで、同じようなトラブルが発生したときに落ち着いて原因を切り分け、最小限の手戻りで解決できるようになります。
コメント