第20回 ファイル共有プロトコルSMB／CIFS（その1）：基礎から学ぶWindowsネットワーク（3/3 ページ）
今回より、Windowsネットワークの核心、SMB／CIFSに入る。ネットワーク設計やトラブルシュートなどで不可欠な知識だ。
段階ごとに利用するコマンドが異なる理由
上の例で見たように、エクスプローラを利用すれば「ドメイン」→「コンピュータ」→「リソース（フォルダ）」というふうに、シームレスにアクセスすることができる。だがコマンド・プロンプト上でネットワーク・リソースを利用するためには、その段階に応じて「net view /domain:<ドメイン名>」「net view \\<サーバ名>」「dir \\<サーバ名>\<フォルダ名>」という3種類のコマンドを使い分けなければならない。「net view」で公開リソース（フォルダ）の内容を表示させることはできないし、逆に「dir」でサーバの持つ公開リソース名の一覧を表示させることもできないからだ。
このように、コマンドを区別して利用しなければならない理由は、実はWindowsネットワークの内部アーキテクチャに深く関係している。エクスプローラではシームレスに見えたそのアクセスは、実際には各段階で利用されるプロトコルなどが異なっているからだ。
最初にドメイン名を元にして、そこに属するコンピュータ名の一覧を表示させているが、ここで利用されているのは、「ブラウザ」と呼ばれるコンピュータとの通信である。ブラウザは、あるドメインやワークグループに属するコンピュータ名の一覧（「ブラウズ・リスト」という）を保持し、クライアントからの問い合わせに応じてそのリストを返す役割を担当している。一般的にはこの機能はドメイン・コントローラが担当するが、ワークグループ・ネットワークではドメイン・コントローラが存在しないため、別のコンピュータが担当する。ブラウズの機能や詳細については今後、回を改めて解説するので、ここでは詳しく触れない。ここでは、リソースを公開しているサーバとは別に、ブラウズ・リストを管理するコンピュータが存在しているということを理解しておいてほしい。Windowsネットワークでよく起こるトラブルに「コンピュータ名の一覧が見えるのに、ファイル・サーバにアクセスできない」や「サーバを直接指定するとアクセスできるが、一覧が表示されない」というものがあるが、それはこのような仕組みによっている。
ブラウズ・リストと公開リソース
ドメインやワークグループに属するコンピュータの一覧（ブラウズ・リスト）は「ブラウザ」というコンピュータが保持している。これはリソースを公開しているサーバとは別のコンピュータになる可能性があるため（同じコンピュータの場合もある）、コンピュータ名の一覧が見えることと、サーバのリソースがアクセスできることは必ずしも一致しない。一覧が見えてもサーバにアクセスできなかったり、その逆が起こったりする。
このブラウザとの通信に使われるのが「net view /domain:<ドメイン名>」というコマンドである。このコマンドを実行すると、現在のネットワーク上でアクティブなブラウザを検索して接続し、コンピュータ名の一覧を返すように要求している。
ネットワーク・アクセスの第2段階では「net view \\<サーバ名>」というコマンドを実行しているが、内部的には、指定された<サーバ>へ接続してから、そのサーバの持つリソースの一覧リストを取得している。この場合、アクセス権が設定されていれば（通常は設定されているはずである）、ユーザー名とパスワードを渡して、そのサーバに対するアクセスの許可を得る。いったんアクセスが許可されれば、そのコンピュータに対する接続では、以後同じユーザー名とパスワードを利用してアクセスする。
ネットワーク・アクセスの第3段階では「dir \\<サーバ名>\<フォルダ名>」というふうに、dirコマンドを利用してフォルダやファイルへアクセスしている。「dir」はもともとローカルのファイルやフォルダへアクセスするときに利用されるコマンドであり、ネットワーク・アクセス専用というわけではない。これに対して「net view」や後述する「net use」などのコマンドは、ネットワーク機能を利用、管理するための専用コマンドであり、MS-Networksのために、（MS-DOSに）追加されたコマンド群である。
ではなぜdirコマンドでネットワーク・ファイルへアクセスできるのかというと、ネットワーク・ファイルがローカル・ファイルと同等に見えるようにOSが作られているから、というのがその理由である。
もしローカルのファイルとネットワークのファイルで異なるコマンド体系やAPIを利用しなければならないとすると、そのシステムは非常に使いにくいものになるだろう。アプリケーションを作るのも面倒だし、ユーザーもアクセスするファイルの置き場所に応じてコマンドを使い分けなければならない。このような不便をなくすため、ネットワーク・ファイルであってもローカル・ファイルと同等に利用できるようにOSが作られている。例えば「C:\USER\YAMADA\TEST.TXT」ならばローカルのディスク上のファイルへアクセスし、「\\WINSERVER-01\USER\YAMADA\TEST.TXT」ならばネットワーク上のファイル・サーバへアクセスを依頼する。パス名の先頭部分が若干異なるが、どちらも同じような形式のファイル名として扱われている。先頭部分を解析して、「\\<サーバ名>」となっていればリモートのサーバへ要求を振り向ければよいだろう。このように、アクセスする先に応じて適切なファイル・システム・ドライバやリモート・コンピュータへと要求を振り分けるメカニズムを、Windows OSでは「リダイレクタ（redirector）」と呼ぶ。詳細については、連載第2回の「Windowsネットワークのレイヤ・モデルとファイル共有―２．共有ファイルのアクセスを追跡してみる」を参照していただきたい。
これで分かるとおり、いったん「net view \\<サーバ名>」というコマンドを実行してファイル・サーバとの接続が確立してしまえば、あとはローカルのファイルをアクセスするのと同じである。よってネットワーク・アクセスの第3段階ではdirというコマンドが利用できるようになっているし、ネットワーク・アクセス用の特別なコマンドを使う必要もない。
これに対してエクスプローラでは、一見するとシームレスにアクセスしているように見えるが、内部ではこれら3種類のコマンドをそのコンテキストに応じて自動的に使い分けている。だから何らかのトラブル（ドメインやサーバ名、リソース名の一覧が表示されない、リソースへのアクセスが拒否されるなど）が生じた場合は、どの段階でエラーが起こっているのかをよく見極め、トラブルに対処する必要がある。そのためには、それぞれのnet viewやdirコマンドの機能をよく理解し、段階的に試行して、どの段階でどのようなエラーが生じているかを把握する必要がある。
UNC表記について
Windows OSでは、ローカルのファイルとリモートの（ネットワーク上の）ファイルを統一的に扱えるように、「UNC（Universal Naming Convention）」という、汎用的な名前付け規則を使っている。例えば「C:\TEST.TXT」ならばローカルのディスク（C:ドライブ）上にあるファイルを指すが、「\\WINSERVER-01\USER\YAMADA\TEST.TXT」ならばネットワーク上のファイル・サーバに置かれたファイルを指す。
このUNC表記は、ファイル名を指定するところなら、たいていの場所で利用できるので、覚えておくとよいだろう。例えばファイルの保存ダイアログにおいて、ファイル名の前に直接UNCでパスを記述し、サーバ上のフォルダへ直接保存させることができる。また、フォルダの場所をいちいちUNCで指定するのが面倒な場合や、［マイ ネットワーク］−［ネットワーク全体］−［Microsoft Windows Network］−……を順番にたどるのが面倒な場合は、ローカルのドライブにマップ（割り当て）しておくのもよいだろう。例えば\\WINSERVER-01\USERをX:ドライブにマップしておくと、X:\YAMADA\TEST.TXTのように、短い名前で表現することができる。ドライブにマップするには、エクスプローラでサーバ中のフォルダ名を右クリックして、ポップアップ・メニューか［ネットワーク ドライブの割り当て］を実行する。もしくは「net use x: \\winserver-01\user」というコマンドを利用すればよい。詳しくはWindows TIPS「アカウントを指定してIPC$共有リソースへ接続する」を参照していただきたい。
UNC中におけるサーバの指定方法
Windows 9xといった古いWindows OSの仕様では、UNC中におけるサーバ名は、NetBIOS名（最大15文字）で指定する必要があった。だが現在のCIFSが利用できるWindows OSではこの制限が緩和され、NetBIOS名だけでなく、IPアドレス表記やFQDN名で指定することも可能になっている。例えば「\\192.168.10.12\user」や「\\winserver.example.co.jp\user」といった表記が利用できる。NetBIOS名で表現できない場合は、CIFSのみが利用されることになっている。このような拡張された表記を利用することにより、例えばActive Directory環境やTCP/IPネットワークとの親和性が高くなっている。Active Directory環境では各コンピュータは長い名前やDNSドメイン名を持つが、無理に短い名前を付けたり、NetBIOSをルーティングしたり、NetBIOS名の名前解決をさせるために面倒でトラブルの元となりやすいネットワーク設定を行ったりしなくても済むからだ。
ファイル・サーバとのセッション・セットアップ
以上の例では、net viewコマンドのあと、すぐにdirコマンドを使ってファイル・サーバへアクセスしていた。だがサーバ側の共有アクセス権の設定によっては、net viewコマンドの実行が失敗する（アクセス拒否される）ことがある。
C:\>net view \\winserver-01 …公開リソースの一覧の表示
システム エラー 5 が発生しました。 …エラーの発生
アクセスが拒否されました。
このエラーが発生する最も多い原因は、サーバ（ここではwinserver-01）へアクセスする場合のアクセス権がない、というものである。net viewコマンドで特定のサーバのリソース一覧を取得するためには、最初にそのサーバへネットワーク・ログオンする必要がある。ログオンして初めてリソースの一覧を取得できるのである。
この例のように単にnet viewコマンドを実行すると、ユーザーが現在ログオンしているときに使ったユーザー名とパスワードを使って、リモートのサーバへ接続しようとする。例えばクライアント・コンピュータへ「ユーザー名：suzuki」、「パスワード：password123」でログオンしているとすると、リモートのサーバへ接続するときにはこのユーザー名とパスワードの組を使ってネットワーク・ログオンしようとする。もしこのアカウント（ユーザー名）とパスワードの組がサーバ側に登録されていれば、ログオンは成功し、net viewコマンドの実行は成功する。だがログオンに失敗すると、net viewコマンドは以上のようにエラーとなる。もし同じアカウントがサーバ側に登録されていないのならば、別の有効なアカウントを指定しなければならない。
ファイル・サーバと最初に接続し、リソースの利用開始処理を行うことを「セッション・セットアップ」というが、net viewコマンドでは、セットアップに使用するアカウントを明示的に指定することはできない。これを行うには、まずnet useコマンドを使って、IPC$リソースへの接続を明示的に行えばよい。IPC$リソースとは、ネットワーク・ログオンの一番最初の段階で利用されるリソースの名前である。IPC$リソースへの接続が成功するとファイル・サーバとクライアント間で「セッション（通信路）」が確立され、一覧の取得やファイル入出力などといったファイル操作を行うことができる。このセッションが確立しない限り、サーバのリソースを利用することはできない。実は最初に「net view \\<サーバ名>」を実行したとき、内部ではこのIPC$への接続が行われているのである。
IPC$リソースへの接続を行うには、「net use \\<サーバ名>\ipc$」というコマンドを実行すればよい。net useでは接続に使用するユーザー名とパスワードを明示的に指定できるので、これを利用する。詳しくはWindows TIPS「アカウントを指定してIPC$共有リソースへ接続する」や「共有リソース・アクセス時にパスワード入力を求められる「IPC$」とは？」などを参照していただきたいが、例えば次のようにすればよい。
C:\>net use \\winserver-01\ipc$ /user:suzuki password123
コマンドは正常に終了しました。
※パスワードをインタラクティブに入力する方法や、ローカルのアカウントではなく、ドメインのアカウントを指定する方法、net useの基本的な使い方などについては、先のTIPSを参照のこと。
これを実行してから、net viewを実行すれば、すでにセッションが確立しているのでエラーにはならずに処理を進めることができる。なお、現在確立しているセッションの内容を調べるには、単に「net use」というコマンドを実行すればよい。
C:\>net use …接続済みセッションの一覧の表示（クライアント側）
新しい接続は記憶されます。
ステータス ローカル名 リモート名 ネットワーク名
-------------------------------------------------------------------------------
OK \\winserver-01\ipc$ Microsoft Windows Network
コマンドは正常に終了しました。
これはクライアント側での確認方法であるが、サーバ側で現在確立しているセッションを確認するには、net sessionコマンドを利用する。
C:\>net session …接続済みセッションの一覧の表示（サーバ側）
コンピュータ ユーザー名 クライアント オープン アイドル時間
-------------------------------------------------------------------------------
\\WINPC-01 SUZUKI Windows 2002 Serv 1 03:39:59
コマンドは正常に終了しました。
セッション情報ではなく、現在オープンされているファイルの情報を知りたい場合は、net fileコマンドを利用すればよい。ただしこれはサーバ上でのみ実行可能なコマンドであり、現在利用されているファイルをクライアント側で知る方法は用意されていない。
C:\>net file
ID パス ユーザー名 ロック数
-------------------------------------------------------------------------------
7555 C:\user SUZUKI 0
7680 C:\user\suzuki SUZUKI 0
コマンドは正常に終了しました。
net fileコマンドの使い方については、Windows TIPS「共有ファイルを現在使用しているユーザーを特定する方法」も参照していただきたい。
なお、現在どのユーザー・アカウントでコンピュータにログオンしているかを調べるには、「net config workstation」もしくは「net config redirector」コマンドが利用できる（いずれでも同じ）。これは「Workstaion サービス」に関する現在の状態を表示させるコマンドである。
C:\>net config workstation
コンピュータ名 \\WINPC-01
フル コンピュータ名 WINPC-01
ユーザー名 Administrator
↑…ログオン・ユーザー名。これが利用される
アクティブなネットワーク (ワークステーション)
NwlnkNb (000D569DFACD) …NetBIOS over IPX/SPX
NetbiosSmb (000000000000) …CIFS用TCPインターフェイス
NetBT_Tcpip_{2A69D55E-258D-4174-AA13-C4794A92650A} (000D569DFACD)
↑…NetBIOS over TCP/IPインターフェイス
ソフトウェア バージョン Windows 2002
ワークステーション ドメイン D-ADVANTAGE2
ワークステーション ドメイン DNS 名 (null)
ログオン ドメイン WINPC-01
COM デバイス オープン タイムアウト (秒) 0
COM デバイス送信バイト数 (バイト) 16
COM デバイス送信タイムアウト (ミリ秒) 250
コマンドは正常に終了しました。
これに対応する、Serverサービス側の状態を表示するコマンドは「net config server」である。
C:\>net config server
サーバー名 \\WINSERVER-01
サーバー コメント
ソフトウェア バージョン Microsoft Windows Server 2003
アクティブなネットワーク (サーバー)
NetbiosSmb (000000000000) …CIFS用TCPインターフェイス
NetBT_Tcpip_{3EEFDF11-FAFF-430D-A4A7-5AEA17E10098} (000d61935c13)
↑…NetBIOS over TCP/IPインターインターフェイス
隠しサーバー No
最大ユーザー数 無制限
各セッションのオープン ファイルの最大数 16384
アイドル セッション時間 (分) 15
コマンドは正常に終了しました。
いずれの出力にもある「アクティブなネットワーク」というインターフェイス名は、現在利用できるトランスポート層プロトコルを表している。「NetbiosSmb」は、CIFSで用いられる、TCPの445番を経由するインターフェイス、「NetBT_Tcpip …」はNBT（NetBIOS over TCP/IP）インターフェイスをそれぞれ表している。もしNetBEUIプロトコルも導入していると、「Nbf_ …」という名前も表示されるはずである。サーバ側とクライアント側の双方に、同じ種類のインターフェイスがないと通信することができない。
次回は、SMB／CIFSプロトコルの詳細なパケット構造の定義とその動作について解説する。
Copyright© Digital Advantage Corp. All Rights Reserved.