Windows 11（24H2）にした途端、昨日まで普通に開けていたQNAP（NAS）の共有フォルダーが急に開けなくなり、「ネットワーク資格情報（ユーザー名／パスワード）」の入力を求められる…。しかも正しいはずの資格情報でも拒否される。この記事では、原因の切り分けポイントと、復旧までの具体的な手順を“安全寄りの順番”で整理します。
症状：QNAPのネットワークドライブに突然アクセスできず、資格情報を要求される
今回のトラブルは、次のような形で発生しやすいです。
- エクスプローラーで \\NAS名\共有 や \\IPアドレス\共有 を開くと、資格情報入力のダイアログが出る
- 保存済みの情報で接続できていたのに、急に「入力が必要」になった
- 正しいユーザー名／パスワードを入れたつもりでも「拒否」される（あるいはループする）
- ネットワークドライブ（割り当て済みドライブ）が「×」になり、再接続できない
この手の現象は、体感として「Windowsの更新がきっかけ」で急に出ます。理由は、Windows 11 24H2でSMB（Windowsのファイル共有）の安全性が強化され、以前は“つながってしまっていた”条件が通らなくなるケースがあるためです。
まず押さえる結論：原因は大きく「Windows側」と「QNAP側」に分かれる
最初にここを整理すると、ムダな試行錯誤が減ります。
| 分類 | よくある根っこ | 典型的な見え方 | 最優先でやること |
|---|---|---|---|
| Windows側（資格情報・接続状態） | 保存済み資格情報の不整合／別ユーザーでの既存接続が残っている | 資格情報を求められ、何を入れても通らない／別の共有は開ける | 資格情報削除＋既存接続（net use）を一度完全に切る |
| Windows側（24H2のSMB強化） | SMB署名（Signing）が必須になった／ゲスト接続の扱いが変わった | 突然つながらない、パスワードが合っているのに弾かれるように見える | NAS側でSMB署名・SMB2/3・ユーザー認証を整える |
| QNAP側（ユーザー・権限） | ユーザーがロック／無効／権限が外れた／設定が壊れた | 特定ユーザーだけ通らない、他PCでも同じ | ユーザー状態と共有権限を再確認、必要なら新規ユーザー作成 |
| QNAP側（SMB設定） | SMBバージョンが古い／匿名（ゲスト）前提／署名設定が合っていない | 24H2以降に顕在化、特にWindows 11 Pro系で起きやすい | SMB3中心、匿名制限、署名設定の確認 |
そして今回のケースでは、最終的に「QNAP側で新しいユーザーを作り、その資格情報でWindowsから接続し直す」ことで復旧しています。これは、Windows側の“キャッシュ削除”だけでは直らないタイプ（NAS側のユーザー状態・権限・認証のズレ）で特に効きやすい対処です。
Windows 11 24H2で起こりやすくなった背景（知っておくと早い）
「昨日までつながっていたのに、今日から資格情報を要求されて拒否される」現象は、ユーザーの操作ミスというより、OS側の前提が変わって表面化することがあります。
Windows 11 24H2では、SMBの安全性に関して大きく次の変更が強調されています。
- SMB署名（SMB signing）が既定で必須になり、署名に対応しない／署名できないSMBサーバーだと接続が失敗することがある
- ゲスト（匿名）接続へのフォールバックが無効化され、ユーザー名・パスワードなしでつながっていた構成が止まることがある（特にPro系）
さらに、Microsoftのドキュメントでは、Windows 11 24H2のエディションによって署名の必須度合いが異なる点も明記されています。たとえば、24H2のEnterprise/Pro/Educationでは送受信の署名を要求する一方、Homeでは要求しない、といった整理です。
要するに、24H2になってから「NAS側の設定（署名・匿名・SMB2/3）」が弱いと、資格情報の入力ダイアログが出たり、入力しても通らない挙動になりやすい、ということです。
最短で復旧させる“結論ルート”：QNAPで新規ユーザー作成 → Windowsで接続し直す
「とにかく仕事（バックアップ）を再開したい」「原因の深掘りは後でもいい」という場合、次のルートが現実的に最短です。
QNAP側：新しいユーザーを作って、必要な共有だけ権限を付ける
- 既存ユーザー（これまで使っていたアカウント）は一旦置いておき、新規ユーザー（例：win11access）を作成
- アクセスしたい共有フォルダーに対して、読み取り／読み書きなど必要な権限だけ付与
- 「とりあえずadminで…」は避け、Windowsからの接続専用の一般ユーザーにする（権限最小化）
QTS（5.x系）では、Microsoft Networking（Samba/SMB）設定は概ね Control Panel > Network & File Services > Win/Mac/NFS/WebDAV > Microsoft Networking 配下にまとまっており、Advanced OptionsでSMBの上限／下限や署名なども調整できます。
Windows側：保存済みのNAS資格情報を消して、新規ユーザーで接続する
- 資格情報マネージャーで、NAS（ホスト名／IP）に関する項目を削除
- 既存の接続（隠れたセッション）を切る
- IPアドレス指定で共有を開き、ユーザー名の形式を工夫して入力
この“結論ルート”で復旧できると、少なくとも「ネットワーク疎通」「共有フォルダーそのもの」「Windowsの基本機能」は生きていることが分かり、原因をNAS側のアカウントやSMB設定に絞りやすくなります。
Windows側の対処：順番通りにやると成功率が上がる
いったん「接続状態」を完全にリセットする（隠れセッション潰し）
Windowsは同じNASに対して、見えない接続（セッション）を握ったままになることがあります。これが残っていると、資格情報を変えても通らない／拒否される、のように見えます。
管理者のコマンドプロンプトで、まず現状確認：
net useNASに向いた接続が残っていれば削除：
net use \\NAS名 /delete
net use \\192.168.1.100 /deleteどれが悪いか分からない・大量に残っている場合は、影響範囲を理解した上で全削除も選択肢です：
net use * /delete「別ユーザーでつないだ覚えがないのに…」でも、バックアップソフト／同期ツール／エクスプローラーの自動再接続が原因で残っていることがあります。
資格情報マネージャー（保存済み）を削除して“新規入力”させる
GUIなら以下です。
- コントロールパネル → 資格情報マネージャー → Windows 資格情報
- NASのホスト名（例：QNAP）やIP（例：192.168.1.100）に関係する項目を削除
コマンドでやるなら、一覧表示してから削除します。
cmdkey /listcmdkey /delete:ターゲット名ここまでやってから再接続すると、Windowsが古い情報で勝手に試して失敗するループを断ち切れます。
ユーザー名の形式を変えて試す（ここで通るケースが多い）
資格情報入力ダイアログで、ユーザー名は“ただの user”より、次のように明示すると通りやすいです。
| 入力例 | 意味 | 向いている状況 |
|---|---|---|
| NAS名\user | NAS側のローカルユーザーとして認証 | ホスト名解決が安定している |
| IPアドレス\user | IPを“接続先の識別子”として認証 | 名前解決が怪しい／別名でつないでいた |
| user | Windowsが解釈に失敗するとPC側のユーザーとして扱われることも | 最初に試すには弱い |
「正しいはずの資格情報なのに通らない」パターンの一部は、実はユーザー名の解釈違い（PC側のアカウントとして送ってしまっている等）で起きます。
複数の資格情報で同じNASに接続できない（エラー1219系）
Windowsには設計上の制約があり、同一サーバー（同一NAS）に対して複数のユーザー資格情報を混在させると、接続が破綻することがあります。MicrosoftのKBでも、別ユーザーで別共有に接続しようとするとエラーが出るシナリオが説明されています。
この制約の厄介なところは、次のような状態を自分で作ってしまいやすい点です。
- 普段は \\QNAP\share で接続している
- トラブル時に \\192.168.1.100\share でも試す
- さらに別ユーザーでも試す
結果、Windows側は「別サーバー」扱いになったり「同一サーバー」扱いになったりが混ざり、資格情報が競合して余計にこじれます。Microsoftの回避策として、IPアドレスや別DNSエイリアスで“別サーバーに見せる”という考え方も紹介されています。
対策としては、まず既存接続をすべて切った上で、使う接続先（NAS名かIP）を決め、資格情報も1種類に揃えるのが安定です。
ネットワークプロファイルと共有関連の基本設定を見直す
ネットワークが「パブリック」扱いになると、探索や共有が制限され、見え方が不安定になります。
- Windowsのネットワークプロファイルをプライベートにする
- 「ネットワーク探索」「ファイルとプリンター共有」を有効化
ここは“資格情報拒否”の根本解決にならないことも多いですが、切り分けとして先に整えておくと混乱が減ります。
疎通確認：SMB（445/TCP）が通っているか
資格情報の問題に見えて、実はポートが閉じている／VPNやセキュリティ製品が遮断しているケースもあります。PowerShellで簡易チェックできます。
Test-NetConnection 192.168.1.100 -Port 445ここがNGなら、Windows設定ではなくネットワーク機器・ファイアウォール・セキュリティソフト側の確認が先です。
Windows 11 24H2特有の“詰まりどころ”：SMB署名とゲスト接続
24H2で急に発生しやすいのは、次の2点です。
SMB署名（Signing）が必須になり、NAS側が追従できない
Microsoftは、24H2でSMB署名を既定で必須にすることを「セキュリティ向上」として説明しています。NAS側が署名に対応していない（または署名が成立しない）と、接続エラーになり得ます。
特にWindows 11 24H2のPro/Enterprise/Education系では署名の要求が強くなるため、「同じ24H2でもHomeはつながるのにProはつながらない」のような差が出ることもあります。
ゲスト（匿名）前提の共有は、24H2で止まりやすい
以前は、ユーザー名・パスワードなし（あるいは実質的にゲスト）でつながっていたNASやルーター内蔵ストレージが、24H2でつながらなくなる事例が増えました。Microsoftは、Pro系でゲストフォールバックを既定で無効にする旨を説明しています。
また、ゲストログオンを無理に許可するには、SMB署名やSMB暗号化のポリシーを無効化しなければならない（＝安全性が落ちる）ことも明記されています。
つまり、24H2で安定させる王道は「NAS側でゲストをやめ、ユーザー認証＋SMB2/3＋署名対応に寄せる」です。
QNAP側の確認：ユーザー権限とSMB設定を“24H2前提”で整える
共有フォルダー権限：最初に見るべきは「そのユーザーに権限があるか」
QNAP側で次を確認します。
- 対象の共有フォルダーに、そのユーザーが明示的に許可されているか（読み取り／読み書き）
- グループ権限と個別権限が競合していないか
- ユーザーが無効化／ロック／パスワード期限などの状態になっていないか
ここで“怪しい”と感じたら、深追いより新規ユーザーを作り直すほうが早く復旧することがよくあります（今回の解決パターン）。
SMB（Microsoft Networking）の有効化と、SMBバージョンの上下限
QTS 5.xのドキュメントでは、Microsoft Networking（Samba/SMB）の設定画面と、Advanced Optionsでの項目が整理されています。ここで重要なのは以下です。
- Highest SMB version / Lowest SMB version を確認し、基本は SMB3（上限）＋SMB2（下限） を目安にする
- Restrict anonymous users from accessing SMB shared folders（匿名ユーザーの制限）を有効化し、ゲスト前提を避ける
QNAPの古い記事（QTS 4.2例）でも、Microsoft NetworkingのAdvanced Optionsで「Highest SMB versionをSMB 3.0にする」手順が案内されています。機種やQTS世代が違っても“設定の場所”の考え方は近いです。
SMB署名（Server signing）：Windows 11 24H2側に合わせる
QTS 5.0の設定項目には「Server signing」があり、署名をOptional / Requiredなどで選べることが示されています。Windows 11 24H2側で署名が必須になっている環境では、NAS側も署名が成立する設定が必要です。
ここはネットワーク構成や古いクライアントの有無で最適が変わりますが、少なくとも“署名できない状態”を放置しないことがポイントです。
SMB1は最終手段（セキュリティ上の理由で非推奨）
どうしても古い環境でSMB1が必要になることはありますが、QNAP自身も「SMB1には重大な脆弱性があり推奨しない」と警告しています。
SMB1を有効にすると一時的に“つながる”場合はあります。ただし、これは「直った」のではなく「安全性を下げて通した」に近いので、基本は避け、NASのファームウェア更新やSMB2/3運用への移行を優先してください。
切り分けに効く手順：ホスト名ではなくIPで割り当て直す
DNSや名前解決が不安定だと、資格情報問題と見分けがつきません。切り分けとして、いったんIPで固定してみます。
\\192.168.1.100\SharedFolderここで通るなら「名前解決（DNS/WINS/WS-Discovery）」側の問題が濃厚です。QTS 5.xにはWS-Discoveryや名前解決優先順位の設定項目もあるため、環境に合わせて見直します。
具体例：ネットワークドライブの再割り当て（成功しやすい形）
Windows側で再割り当てをするなら、エクスプローラーの「ネットワークドライブの割り当て」でもOKですが、トラブル時はコマンドのほうが挙動が読みやすいです。
| 目的 | コマンド例 | ポイント |
|---|---|---|
| ドライブとして割り当て | net use Z: \\192.168.1.100\SharedFolder /user:192.168.1.100\win11access パスワード /persistent:yes | ユーザー名にIP\ユーザーを付けて解釈ズレを防ぐ |
| 接続一覧の確認 | net use | “残っている接続”が見つかる |
| NASへの接続を削除 | net use \\192.168.1.100 /delete | 資格情報競合の解消に効く |
「何を入れても拒否される」状態からの復旧では、“接続削除 → 資格情報削除 → 再割り当て”をセットでやるのがコツです。
このケースで効いた決め手：QNAP側が“以前の資格情報を受け付けなくなっていた”
今回の結論はここです。
- Windows側の資格情報削除やユーザー名形式変更だけでは改善しない
- QNAP側で新規ユーザーを作成し、共有フォルダー権限を付け直す
- Windows側でその新規ユーザーの資格情報を入力して接続し直す
このパターンは、次のような“NAS側の状態変化”がきっかけで起きやすい印象があります。
- NAS側のユーザーが何らかの理由でロック／無効扱いになった
- 権限の継承やグループ設定の変更で、共有に入れなくなった
- SMB設定（署名、匿名制限、SMBバージョン）の変更で認証の前提が変わった
Windows側だけをいじり続けて泥沼化しやすいので、「Windowsで資格情報を消してもダメなら、NAS側のユーザーを作り直す」を早めに選択肢に入れると復旧が早いです。
よくある質問
正しいユーザー名とパスワードなのに「間違っています」と言われるのはなぜ？
実際にパスワードが間違っているケースもありますが、24H2以降はSMB署名の不整合などが“資格情報エラーっぽく”見えることがあります。24H2で署名必須が強化された点は公式にも説明があります。
どうしてもゲスト（パスワードなし）で運用したい
おすすめしません。どうしても必要ならWindows側に「Enable insecure guest logons」を設定する手がありますが、ゲストログオンは署名や暗号化と相性が悪く、セキュリティを落とす必要がある点が明記されています。まずはNAS側でユーザー認証に移行するのが現実的です。
同じNASに別ユーザーでつなぎたい（共有ごとにアカウントを分けたい）
Windows側の制約で、同一サーバーに対して複数資格情報を混在させるとエラーになることがあります。MicrosoftのKBでは、IPアドレスや別DNSエイリアスを使って“別サーバーに見せる”回避策が紹介されています。
ただし、家庭内NAS運用では、まず「接続専用ユーザーを1つ作って統一」するほうがトラブルが少ないです。
再発防止のコツ（運用を少し変えるだけで安定する）
- NASアクセス専用ユーザーを作り、PCログオン用ユーザーと分ける（権限も最小限に）
- QNAP側のSMBはSMB2/SMB3中心にし、匿名（ゲスト）前提の共有をやめる
- Windows側は「ホスト名で接続するのか／IPで接続するのか」を決め、混在させない（資格情報の競合を避ける）
- Windows UpdateやQTSアップデート後は、共有に入れるかの動作確認を短時間で実施（問題が出た時に“いつから”が特定できる）
Windows 11 24H2は、ローカルネットワークでもSMBの安全性を強める方向に進んでいます。だからこそ、NAS側を「ユーザー認証＋SMB3＋署名対応」に寄せるほど、今後の更新でも安定しやすくなります。
コメント