Command-1　Windowsファイルサーバにアクセスできない

「わたしのマシンだけファイルサーバにアクセスできなくなった」という苦情を聞いたことがないWindows管理者の方は（よほど幸運な方を除き）まずいないでしょう。考えられる原因はいろいろありますが、この際にまずやるべきは、利用者からの報告を鵜呑みにせずに、本当にサーバにアクセスできていないかを確認することです。

サーバアクセスに成功しているかどうかの確認

筆者のお薦めは、コマンドラインから図1のnet useコマンドを用いてのアクセス確認です。

図1　net useコマンド

C:\>net use \\192.168.135.44\temp /user:user1
\\192.168.135.44\temp のパスワードまたはユーザー名が無効です。

'user1' のパスワードを入力してください。'192.168.135.44' に接続します:
コマンドは正常に終了しました。


C:\>

※ Windowsのバージョンによって若干表示されるメッセージが異なる場合があります。

net useコマンドではアクセス先を「\\サーバ名（またはIPアドレス）\共有名」というUNC名で指定する必要があります。トラブルシューティングの観点からは、まずサーバ名ではなくIPアドレスでアクセスしてみることを強くお勧めします。

/userオプションは指定しなくても構いませんが、その場合は現在マシンにログオンしているユーザ名とパスワードが送出される点に留意してください。Windows XPで「ようこそ画面」を有効にしていない限り、現在誰としてログオンしているかは、[Ctrl]＋[Alt]＋[Del]を押下すると表示される図2の画面から確認できます。

なお、これと並行してpingコマンドによる疎通確認を行ってもいいですが、pingコマンドによる応答がなかったからといってアクセスできないと早合点しないようにだけ、気を付けてください。

図1のようにユーザ名やパスワードを確認するメッセージが表示され、正しい情報を入力することで「コマンドは正常に終了しました」というメッセージが表示された場合、アクセスは成功しています。クライアントとサーバが同一ドメインの場合など、ユーザ名とパスワードを聞かれずに、このメッセージが表示される場合がありますが、この場合もアクセスは成功しています。こうした場合は再度「\\サーバ名\共有名」でアクセスを試行してみましょう。これでアクセスに失敗する場合は、サーバ、ネットワーク、クライアントの動作に問題はなく、サーバ名の名前解決の問題であると原因のしぼり込みができます。

サーバの名前解決の状態を確認

サーバ名でのアクセスに失敗する場合は、まず図3のipconfig /allコマンドで、WINSサーバやDNSサーバについて適切なサーバが指定されていることを確認してください。

図3　WINSサーバ、DNSサーバの確認

C:\>ipconfig /all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : mizuki
        Primary Dns Suffix  . . . . . . . : samba400tp5.local
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : samba400tp5.local

Ethernet adapter LAN2:

        Connection-specific DNS Suffix  . : localdomain
        Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter #2
        Physical Address. . . . . . . . . : 00-0C-29-11-C0-EF
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.135.153
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.135.2
        DHCP Server . . . . . . . . . . . : 192.168.135.254
        DNS Servers . . . . . . . . . . . : 192.168.135.42
        Primary WINS Server . . . . . . . : 192.168.135.2
        Lease Obtained. . . . . . . . . . : 2007年8月1日 9:02:19
        Lease Expires . . . . . . . . . . : 2007年8月1日 9:32:19

※ DHCP Server(s)欄、Primary WINS Server欄、Secondary WINS Server欄を確認します。

適切なサーバが指定されている場合は、図4のipconfig /displaydnsや、図5のnbtstat -cコマンドで、クライアント上の名前キャッシュの情報を確認してみましょう。

図4　ipconfig /displaydnsによる名前キャッシュの確認

C:\>ipconfig /displaydns

Windows IP Configuration

         1.0.0.127.in-addr.arpa
         ----------------------------------------
         Record Name . . . . . : 1.0.0.127.in-addr.arpa.
         Record Type . . . . . : 12
         Time To Live  . . . . : 544265
         Data Length . . . . . : 4
         Section . . . . . . . : Answer
         PTR Record  . . . . . : localhost


         localhost
         ----------------------------------------
         Record Name . . . . . : localhost
         Record Type . . . . . : 1
         Time To Live  . . . . : 544265
         Data Length . . . . . : 4
         Section . . . . . . . : Answer
         A (Host) Record . . . : 127.0.0.1

図5　nbtstat -cによる名前キャッシュの確認

C:\>nbtstat -c

VMware Network Adapter VMnet8:
Node IpAddress: [192.168.135.1] Scope Id: []

                  NetBIOS Remote Cache Name Table

        Name              Type       Host Address    Life [sec]
    ------------------------------------------------------------
    W2KPRO1        <00>  UNIQUE          192.168.135.44      590
    W2KPRO1        <20>  UNIQUE          192.168.135.44      597

サーバのエントリが存在しているのに異なるIPアドレスが設定されている場合は、名前解決機能を提供するhostsやLMHOSTSファイル、WINSやDNSの設定に誤りがある、もしくは古いキャッシュの情報が残っている可能性が考えられます。hostsおよびLMHOSTSファイルについては、%SystemRoot%System32\Drivers\Etc以下にある該当ファイルを参照して、該当サーバのエントリがある場合は、内容に不備がないかを確認してください。さらに図6のようにしてクライアント上のキャッシュを消去した上で、再度アクセスしてみましょう。

図6　名前キャッシュの消去

C:\>nbtstat -R
    Successful purge and preload of the NBT Remote Cache Name Table.

C:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

再度アクセスに失敗した場合は、再度nbtstat -cコマンドで名前キャッシュの内容を確認してください。誤ったエントリが復活している場合は、WINSサーバやDNSサーバの設定に誤りがある可能性が高いでしょう。

そもそも名前キャッシュに情報がない場合は、hostsやLMHOSTSファイル、WINSサーバやDNSサーバ等に該当サーバのエントリがないか、WINSサーバやDNSサーバへのアクセスが拒否されている、もしくはLMHOSTSファイルが有効になっていないといった原因が考えられます。

ネットワークで用いている名前解決機構に従って、各種サーバやファイルの設定確認を行ってください。

サーバのアクセス許可設定の確認

図1のユーザ名とパスワードを確認するメッセージが出力されるが、正しい情報を入力してもアクセスできないという場合、結果としてサーバから応答があったことから、サーバへのアクセス自体は成功していると判断できます。この場合、サーバ、ネットワークの動作に問題はありません。通常はサーバのアクセス許可の設定に問題がありますので、共有やファイルシステム上のアクセス許可の設定を確認しましょう。

ただし、後述するセキュリティ設定に起因している場合もありますので、適切な共有にアクセスしようとしているにもかかわらず、アクセスできないと判断される場合は、ローカルセキュリティポリシー等も確認しましょう。

図7のようなメッセージが出力されてアクセスできない場合は、本当にサーバにアクセスできていない可能性が高いと考えられます。ただし、存在しない共有名を指定した場合にもこのメッセージが出力されることがありますので、念のため図8のようにして、すべてのファイルサーバが必ず持っているIPC$共有へのアクセスを試してみることをお勧めします。

図7　ファイル共有が見付からない場合に表示されるメッセージ

C:\>net use \\192.168.135.44\temp2 /user:user1
システム エラー 67 が発生しました。

ネットワーク名が見つかりません。


C:\>

図8　IPC$共有へのアクセス

C:\>net use \\192.168.135.44\ipc$ /user:user1
コマンドは正常に終了しました。


C:\>

なお、IPC$共有にはドライブ名のマッピングができませんので注意してください。IPC$共有へのアクセスが行える場合は、共有名の入力ミス、もしくはサーバ側の設定ミスなどで、サーバ上に該当する共有が存在していない可能性が高いと考えられます。IPC$共有へのアクセスも失敗する場合は、クライアントの設定不備、もしくはファイアウォールの設定不備やルーティング設定不備により、ネットワークもしくはクライアントに問題があるということが確認できます。

サーバのセキュリティ設定の確認

最後に、図9のようなメッセージが出力されてアクセスできない場合は、サーバとクライアントとのセキュリティの設定が矛盾していることが多いと考えています。適用されているローカルセキュリティポリシーあるいはGPOなどで図10のセキュリティオプションの設定に矛盾がないか確認する、パケットキャプチャで取得したパケットを詳細に解析するといった作業が必要になります。

図9　セキュリティ設定が矛盾している際に表示されるメッセージ

C:\>net use \\192.168.135.71\pub /user:monyo
システム エラー 1240 が発生しました。

そのアカウントは、このワークステーションからのログインを許可されていません。


C:\>