Windows 11から共有フォルダーへアクセスできないときは、「ネットワークが見えない」「サーバー名を解決できない」「SMB接続が届かない」「認証に失敗する」「共有またはNTFS権限がない」を順番に分けます。エクスプローラーの「ネットワーク」に相手PCが表示されないことと、\\server\shareへ直接接続できないことは同じではありません。最初に正確なUNCパスとエラー全文を記録し、名前解決、TCP 445、資格情報、権限の順に確認すれば、ファイアウォール停止やSMB 1.0有効化のような危険な回避をせず原因を絞れます。
最初にそろえる情報
- 共有を提供するPCまたはファイルサーバーの正式名とIPアドレス
- 共有名を含む完全なUNCパス。例：
\\filesrv01\sales - エラー全文、エラーコード、発生時刻、操作した利用者名
- 同じ利用者が別PCから接続できるか、別利用者が同じPCから接続できるか
- 社内LAN、家庭内LAN、VPN、ゲストWi-Fiなど現在の接続経路
- 以前は使えた場合、最後に成功した日時と、その後の更新・パスワード変更・VPN変更
「アクセスできません」だけでは原因を判断できません。「ネットワークパスが見つかりません」「アクセスが拒否されました」「ユーザー名またはパスワードが正しくありません」では調査先が異なります。画面を撮る場合は、共有内のファイル名、社員名、サーバー構成などを公開しません。組織のファイルサーバーでは、管理者へ発生時刻と利用者名を伝えると監査ログと照合しやすくなります。
「ネットワーク」表示に頼らずUNCパスを試す
WindowsキーとRを押し、確認済みのUNCパスを入力します。最初はドライブ割り当てではなく、\\server\shareを直接開きます。エクスプローラーの「ネットワーク」一覧は探索機能に依存するため、一覧にサーバーが出なくても直接パスは開ける場合があります。逆に、サーバー名だけは見えるのに共有を開けない場合は、認証や権限を調べます。
正しい共有名が不明なら推測で管理共有へ接続せず、共有の所有者または管理者へ確認します。末尾のフォルダー名、全角・半角、古いサーバー名、DFS名前空間、VPN接続時だけ有効な名前などを確認してください。ショートカットや割り当てドライブが古いサーバーを指している場合は、直接UNCパスで成功してから新しい割り当てを作ります。
同じネットワーク経路にいるか確認する
「設定」→「ネットワークとインターネット」を開き、Wi-FiまたはEthernetの接続先、IPv4アドレス、VPN状態を確認します。家庭や小規模オフィスで相互に信頼できる端末間の共有を使う場合は、ネットワークプロファイルが「プライベート」であることを確認します。公共Wi-Fiを共有のためにプライベートへ変更してはいけません。企業ネットワークでは、プロファイルやファイアウォールは管理ポリシーで決まるため管理者へ相談します。
VPN経由の共有なら、VPN接続が確立していること、組織のDNSと経路が配布されていることを確認します。インターネットが見られるだけでは社内ファイルサーバーへの経路があるとは限りません。Wi-Fiの「クライアント分離」やゲストネットワークでは、同じSSIDに見えても端末間通信が禁止される場合があります。ルーターの保護機能を無効にするのではなく、共有を許可した信頼できるLANへ接続します。
名前解決とSMBポートを読み取り専用で調べる
PowerShellで次の確認を行うと、名前解決とTCP 445への到達を分けられます。filesrv01は実際のサーバー名へ置き換えます。これらは接続状態を確認するコマンドで、ファイアウォールや共有設定を変更しません。
Resolve-DnsName filesrv01
Test-NetConnection filesrv01 -Port 445Resolve-DnsNameが失敗するなら、綴り、DNSサフィックス、VPN、DNSサーバーを確認します。IPアドレスでは接続でき、名前では接続できない場合は名前解決が中心です。ただしIP指定で接続すると、Kerberos認証が使えず別の認証経路になる場合があるため、恒久的な代替としてIPアドレスをドライブへ割り当てません。正しいDNS登録を管理者に修正してもらいます。
TcpTestSucceededがFalseなら、サーバー停止、VPN経路、ネットワークACL、Windows Defenderファイアウォール、ファイルサーバーサービスなどを管理者が確認します。クライアントやサーバーのファイアウォールを丸ごと無効にして試すと保護を失い、許可すべき通信も特定できません。必要な場合は、信頼するネットワーク範囲に対する「ファイルとプリンターの共有」の規則を管理者が確認します。
共有を提供する側の基本状態を確認する
- 共有元PCが起動し、スリープや更新再起動の途中ではないことを確認します。
- 共有元で対象フォルダーを開けること、ディスクがオンラインで空き容量があることを確認します。
- フォルダーの「プロパティ」→「共有」で、現在の共有名と許可された利用者を確認します。
- 「セキュリティ」タブでNTFS権限を確認し、共有権限との両方で必要な権限があるかを見ます。
- Windows Updateとサーバー管理ツールで異常がないか、イベントログに同時刻のSMBエラーがないか確認します。
- 業務サーバーでは設定を変更せず、共有名、利用者、時刻、クライアントIPを担当者へ渡します。
共有権限とNTFS権限は別に評価され、ネットワーク経由では実効的に制限の厳しい組み合わせになります。共有をEveryoneへ開放して直す方法は、機密データを不必要に公開するため使いません。利用者または適切なセキュリティグループへ、読み取り、変更など業務に必要な最小権限を付与します。権限変更は監査対象になり得るため、所有者の承認と変更記録を残します。
資格情報の食い違いを確認する
サーバーへ到達できるのにユーザー名やパスワードを求められる場合は、サインインに使うIDの形式を確認します。ドメイン環境ならDOMAIN\usernameまたは組織が指定するUPN、ワークグループなら共有元PCのローカルアカウントなど、管理者の案内に従います。Microsoftアカウント、Windows HelloのPIN、ローカルパスワードを混同しないでください。PINは端末へのサインイン手段であり、共有先へ送るパスワードとは限りません。
パスワード変更後から失敗する場合は、コントロールパネルの「資格情報マネージャー」→「Windows資格情報」で対象サーバー名の登録を確認します。古い資格情報を削除する前に、正しいユーザー名と新しいパスワード、多要素認証やVPNの利用条件を確認します。対象サーバーの項目だけを扱い、無関係なWeb資格情報やすべてのWindows資格情報を一括削除しません。削除後は必要に応じて再起動し、正式なUNCパスから再認証します。
同じサーバーへ異なる利用者資格情報で同時接続しようとすると、資格情報競合のエラーになることがあります。既存の割り当てドライブ、別共有、バックアップソフトが同じサーバーへ接続していないか確認します。作業中のファイルを閉じ、既存接続の利用者へ影響がないことを確認してから、管理者と切断・再接続を計画します。セッションを強制的に切ると未保存変更が失われる場合があります。
共有とNTFSの実効権限を確認する
| 状況 | 確認点 | 対応 |
|---|---|---|
| 共有のルートも開けない | 共有権限、サーバー認証 | 利用者またはグループの共有権限を確認 |
| 共有は開くが特定フォルダーだけ拒否 | NTFS権限、継承 | 対象フォルダーの実効アクセスを確認 |
| 読めるが保存できない | 変更権限、読み取り専用、空き容量 | 必要な変更権限と保存先を確認 |
| 新規ファイルは作れるが既存を変更できない | 所有者、個別ACL、アプリのロック | ファイル単位の権限と利用中状態を確認 |
| 別利用者は成功する | 所属グループ、拒否ACL、資格情報 | 成功者との権限差を管理者が比較 |
「拒否」エントリは許可より優先される場合があり、ネストしたグループや継承停止によって見た目だけでは判断しにくいことがあります。Windowsの「詳細設定」や管理ツールで実効アクセスを確認し、個別利用者を大量に追加するのではなく、役割に対応するグループを使います。アクセスできないからと所有権を奪取したりACLを初期化したりすると、監査と既存業務へ影響するため行いません。
SMB 1.0を有効にしない
古いNASや複合機だけへ接続できない場合、機器がSMB 1.0しか対応していない可能性があります。しかしMicrosoftのSMBトラブルシューティングでは、SMB 1.0は既定で導入されず、無効化が推奨されています。Windows 11側でSMB 1.0を有効にして症状だけを回避するのではなく、NASや機器のファームウェア更新、SMB 2または3への対応、サポートされる代替共有を機器メーカーと確認します。
古いゲストアクセスを許可するため認証要件を緩める方法も、なりすましや情報漏えいの危険を増やします。利用者名と強いパスワード、サポートされるSMB、適切な署名・暗号化、限定されたネットワークを使う構成へ更新します。管理ポリシーによりSMB署名が必須化された後に接続できなくなった場合も、ポリシーを無効にするのではなく、共有先を対応させます。
ネットワークのリセットは最後に判断する
Microsoftはネットワークリセットを最後の手段として案内しています。実行するとネットワークアダプターと設定が削除・再導入され、VPNクライアントやHyper-Vの仮想スイッチを再設定する必要が生じる場合があります。また既知の接続がパブリックプロファイルへ戻ることがあります。共有フォルダーだけの問題で、名前解決、TCP 445、資格情報、権限のいずれかに原因が絞れているなら、ネットワークリセットは適切な第一選択ではありません。
実施を検討する場合は、Wi-Fi認証情報、固定IP、DNS、VPN、仮想スイッチ、プロキシ、証明書、管理ポリシーを記録し、業務管理者の承認を得ます。再起動後にインターネットだけでなく、VPN、DNS、SMB、業務アプリを順に確認します。ネットワークが戻っても共有権限は変わらないため、権限エラーの修復にはなりません。
復旧確認と再発防止
- 正式なサーバー名のUNCパスで共有を開ける。
- 読み取りだけでなく、許可された利用者はテストファイルを作成、保存、再読込できる。
- 許可されていない別利用者にはアクセスが開放されていない。
- サインアウトまたは再起動後も、正しい資格情報で接続できる。
- SMB 1.0、ファイアウォール全停止、Everyoneへの過剰権限を使っていない。
- 変更したDNS、共有権限、グループ、資格情報を記録し、所有者へ伝えた。
再発する場合は、成功時と失敗時のResolve-DnsName、Test-NetConnection、利用者、VPN、エラー時刻を並べます。サーバー側のSMB監査ログ、認証ログ、権限変更履歴と照合すれば、クライアントを初期化せずに原因へ近づけます。
コメント