Using Samba
Robert Eckstein, David Collier-Brown, Peter Kelly 共著第一版 1999 年 11 月
1-56592-449-5, 注文番号: 4495
416 ページ, 34.95 ドル
|
|
Using SambaRobert Eckstein, David Collier-Brown, Peter Kelly 共著第一版 1999 年 11 月 1-56592-449-5, 注文番号: 4495 416 ページ, 34.95 ドル |
9.2 Fault Tree
nakano 訳注: Fault Tree Analysis (FTA) とは、 信頼性・安全性の評価や解析に用いられる手法です。 詳細は Sandia National Lab. のサイト などをご覧ください。
fault tree は、Sambaをインストールしたり、設定変更を行なったりした際に発生する問題を調査し、解決するためのものである。これはSambaディストリビューションに付属するトラブル診断のドキュメントを大幅に拡張したものである。
Sambaスイートのどの部分のトラブルシューティングを行なうにあたっても、以下の情報については把握しておくべきである:
余計な混乱を避けるため、以下の例ではサーバマシンを server.example.com に、クライアントマシンを client.example.com にしてある。
9.2.1 fault tree の使い方
ここからテストを開始する。テストに時間はかからない(約5分程度)し、最終的には手戻りの時間を節約できる筈であるため、省略せずに順番に行なっていくこと。テストが成功したら、省略してもよいセクション名とページ番号が示される。
9.2.2 IPレベルのトラブルシューティング
最初に行なうテストは、Samba を実行する上で必要な低レイヤのサービスに関するものである。このセクションのテストでは、以下を確認する:
以降のセクションで、TCPレベル、Samba デーモンの smbd と nmbd、ホスト単位のアクセス制御、認証とユーザ単位のアクセス制御、ファイルサービス、ブラウジングについても順次テストを行なっていく。技術指向のエンドユーザと経験を積んだネットワーク管理者の双方が理解できるものとするため、テストは非常に詳細に記述を行なっている。
9.2.2.1 ping を用いたネットワーク層のテスト
サーバとクライアントとで最初に入力するコマンドは
ping 127.0.0.1である。これは ループバック アドレス であり、これをテストすることで、ネットワーク層が正しく動作しているかどうかを確認することになる。UNIX の場合、統計オプション付きでping127.0.0.1を行ない、数行の出力後に停止させる。Sun ワークステーションの場合、コマンドは通常以下のようになる/usr/etc/ping-s127.0.0.1。Linux ではping127.0.0.1. Windows クライアントではping127.0.0.1を MS-DOS ウィンドウで実行するが、これは4行出力後に自動的に停止する。以下は、Linux サーバでの実行例である:
server%ping 127.0.0.1PING localhost: 56 data bytes 64 bytes from localhost (127.0.0.1): icmp-seq=0. time=1. ms 64 bytes from localhost (127.0.0.1): icmp-seq=1. time=0. ms 64 bytes from localhost (127.0.0.1): icmp-seq=2. time=1. ms ^C ----127.0.0.1 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1"ping: no answer from..." や "100% packet loss"というメッセージが表示された場合、マシンにIPネットワーク機能がインストールされていない。
127.0.0.1というアドレスは内部のループバックアドレスであり、コンピュータが物理的にネットワークに接続されているかどうかには依存しない。このテストに失敗した場合は、ローカルマシンに致命的な問題が存在することになる。TCP/IP がインストールされていないか、致命的な設定ミスが存在することが考えられる。UNIX サーバの場合は、OS のドキュメントを参照すること。Windows クライアントの場合、ネットワーク機能をインストールをするには、Chapter 3 Windowsクライアントの構成を参照のこと。もし あなた自身がネットワーク管理者なら、Craig Huntの TCP/IP Network Administrationの第11章や、Craig HuntとRobert Bruce Thompsonが新たに執筆した Windows NT TCP/IP Network Administrationが、参考書としてよいだろう。共にO'Reillyより出版されている。
9.2.2.2 ping を用いたローカル名前解決サービスのテスト
次に ping
localhostをSamba サーバ上で実行してみる。localhostは 127.0.0.1 のループバックを指す便利なホスト名であり、このアドレスに解決される必要がある。pinglocalhostを入力すると、以下のような出力が表示されるはずである:server%ping localhostPING localhost: 56 data bytes 64 bytes from localhost (127.0.0.1): icmp-seq=0. time=0. ms 64 bytes from localhost (127.0.0.1): icmp-seq=1. time=0. ms 64 bytes from localhost (127.0.0.1): icmp-seq=2. time=0. ms ^Cこれが成功したら、クライアント上で同様のテストを行なってみる。失敗した場合:
"unknown host: localhost,"というメッセージが表示された場合は、localhost というホスト名を正しいIP アドレスに変換する部分に問題がある(これは単純にローカルな hosts ファイル中にエントリがないだけかも知れない)。 セクションh 9.2.8, 名前解決サービスのトラブルシューティングを参照すること。
"ping: no answer," もしくは "100% packet loss," と表示されるが、ping 127.0.0.1 が動作する場合、名前解決サービスはアドレスを解決しているが、解決されたアドレスが正しくないことが考えられる。エントリを修正するために、名前解決サービスがアドレスを解決する際に用いるファイルやデータベース(通常UNIXでは /etc/hosts)を確認すること。
9.2.2.3 ping によるネットワークハードウェアのテスト
次に、サーバから自分自身のIP アドレスに対してping を行なってみる。これは、ping 127.0.0.1 と同様の結果が返却されるはずである:
server%ping 192.168.236.86PING 192.168.236.86: 56 data bytes 64 bytes from 192.168.236.86 (192.168.236.86): icmp-seq=0. time=1. ms 64 bytes from 192.168.236.86 (192.168.236.86): icmp-seq=1. time=0. ms 64 bytes from 192.168.236.86 (192.168.236.86): icmp-seq=2. time=1. ms ^C ----192.168.236.86 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1サーバ上で動作したら、同じことをクライアントでも行なう。動作しなかった場合:
9.2.2.4 ping による接続の試験
ここで、(IPアドレスではなく)名前を指定して、サーバからとクライアントから1回ずつpingを行なう。これはネットワークのハードウェアが動作しているかどうかを確認する一般的なテストである:
server%ping serverPING server.example.com: 56 data bytes 64 bytes from server.example.com (192.168.236.86): icmp-seq=0. time=1. ms 64 bytes from server.example.com (192.168.236.86): icmp-seq=1. time=0. ms 64 bytes from server.example.com (192.168.236.86): icmp-seq=2. time=1. ms ^C ----server.example.com PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1Microsoft Windows の場合、サーバに対する ping は 図 9.1のようになる。
図 9.1: Windows クライアントからSamba サーバへの ping
成功した場合、このテストから以下の5つのことが確認できる:
ホスト名がFQDN に展開されている(例えば server.example.com)。
このテストに失敗した場合、ネットワークで以下の事項のどれかに問題があると考えられる:
"ping: no answer," や "100% packet loss" と表示される場合、自分がネットワークに接続されていないか、もう一方のマシンがネットワークに接続されていないか、どちらかのアドレスが不正であるかのどれかであろう。
pingコマンドが各マシンについて報告したアドレスが最初に設定したとおりになっているかを確認すること。違っている場合、2台のマシンの少なくとも一方はアドレスが違っていることになる。arp -a コマンドを
arp-aのように実行し、別のマシンのエントリがないかどうかを確認する。arpコマンドは Address Resolution Protocol 関連の処理を行ない、arp-aコマンドは、ローカルマシンが認識しているすべてのアドレスを表示する。以下に確認事項を示す:もし "192.168.236.86 at (incomplete)," のようなメッセージが表示されている場合、192.168.236.86 の Ethernet address が認識されていない。これは接続性が全く失われていることを意味し、恐らくTCP/IPのネットワークを管理するプロトコルのかなり下層であるイーサネットのインタフェース層でトラブルが発生している。これについては TCP/IP Network Administration (O'Reilly)の第5章と第6章で記述されている。
もし "server (192.168.236.86) at 8:0:20:12:7c:94,"のようなメッセージが表示されている場合、 一時的にサーバに接続されたか、別のマシンが応答を行なってきている。これは、 ping 自体は動作しているということである。恐らくネットワークが瞬断しているかARPの問題である。
"ping: network unreachable" や "ICMP Host Unreachable," というメッセージが表示される場合、応答が受信できておらず、おそらくネットワークをまたがった問題であろう。
原則的に、異なったネットワーク上にいるSMBクライアントとサーバのトラブルシューティングを行なう前に、サーバとクライアントを同じネットワークに配置して行なうべきである。以下のテストは複数ネットワークの環境を想定したものである:
まずは、このセクションで前述したno answerのテストを行なう。これで問題が解決できない場合、残る可能性は以下のようなものである: アドレスが不正である、ネットマスクが不正である、ネットワークが停止している、Firewallによってフィルタされている。
通信元と通信先双方のアドレスとネットマスクを確認し、設定に誤りがないことを確認する。両方のマシンが同じネットワーク中に存在する場合、ネットマスクの値は同一であり、 ping は正しいアドレスを報告する筈である。アドレスがおかしい場合は、正しく修正する必要がある。アドレスが正しい場合、不正なネットマスクによりプログラムが混乱している可能性がある。この章で後述する セクション 9.2.9.1, ネットマスクを参照のこと。
コマンドがnetwork is unreachableと表示するか、前述した2点に問題がある場合は、どちらかのネットワークがもう一方から到達できなくなっている。これはネットワーク管理者側の問題である。
"ICMP Administratively Prohibited"と返却された場合は、何らかのfirewallか設定を誤っているルータで通信が遮断されている。ネットワークのセキュリティ管理者に話をする必要があろう。
"ICMP Host redirect"と返却された場合、 pingはパケットが通過できたことを報告しており、基本的に無害である。これは単にルーティングがしなおされたというだけである。
リダイレクトメッセージを受信したが、 pingの応答がない場合は、リダイレクトされたが、誰も応答していなかったということになる。これは"Network unreachable"の応答と同様に考え、アドレスやネットマスクを確認する。
"ICMP Host Unreachable from gateway gateway_name"と返却された場合、ping パケットは別のネットワークにルーティングされたが、宛先のマシンが応答せず、ルータが問題を報告している。これも"Network unreachable"の応答と同様に考え、アドレスやネットマスクを確認すること。
"ping: unknown host hostname"と返却された場合、マシンの名前が不明になっている。これは名前解決サービスの問題を示唆しているが、
localhostの名前解決には関係しない。この章で後述する セクション 9.2.8を参照のこと。成功したりしなかったりする場合、すなわち幾つかのpingは成功するが残りは失敗するという場合は、マシン間に間欠的に問題が発生しているか、ネットワークが過負荷である。pingを続けて、3%以上のパケットが失敗するようであれば、ネットワーク管理者と一緒に確認をすること。恐らく問題が発生している。ただし、何回か失敗があるだけの場合や、ネットワークに負荷をかけるプログラムが実行中なのを知っている場合は、それほど問題視する必要はない。pingのICMP (および UDP) は時おりパケットをとりこぼすことがある。
client.example.comにpingを行なっているにも関わらず、"smtsvr.antares.net is alive" のようなメッセージを受け取った場合、恐らく別のマシン用のアドレスを使ってしまっているか、マシンが複数の名前やアドレスを持っているかのどちらかである。もしアドレスが不正だった場合は、名前解決サービスが犯人である。名前解決サービスのデータベース中のアドレスが正しいマシンを指すように修正する必要がある。これについては、この章の後半部にある セクション 9.2.8で記述されている。
サーバマシンでは マルチホームになっていることも多い。このサーバは複数のネットワークに接続されており、ネットワーク毎に異なった名前を持っている。もしマルチホームのサーバ上で予期しない名前から応答があった場合は、アドレスを確認してそれが自分のネットワーク上のものかどうかを確認する(この章で後述する セクション 9.2.9.1を参照のこと)。自分のネットワーク上のものであれば、パフォーマンスと信頼性の観点から、別のネットワーク上のアドレスよりは、このネットワーク上のアドレスを利用すべきである。
サーバでは1つのEthernet アドレスに対して複数の名前が割り当てられていることもある。特にWebサーバでは多い。これは無害である。恐らく変更されるかも知れないエイリアス名よりも、公式な(そして固定的な)名前を利用する方がよいであろう。
全てうまく行っているが、IPアドレスが 127.0.0.1 と表示される場合、名前解決サービスに問題が発生している。これは通常OSのインストールプログラムが /etc/hosts 中に
127.0.0.1localhosthostnamedomainnameのような行を生成してしまうのが原因である。localhost の行は127.0.0.1localhostか127.0.0.1localhostloghostのようになっていなければならない。誰がマスタブラウザかの判断に失敗しないように、設定を修正すること。この設定は後のテストで(曖昧な)エラーが出力される原因にもなり得る。サーバから行なって成功した場合は、クライアントからも試してみること。
9.2.3 TCPのトラブルシューティング
ここまでで、 pingを用いてのIP、UDP、および名前解決サービスのテストは完了した。次はTCPのテストである。 ping やブラウジングはICMP と UDP を利用するが、ファイル、印刷サービス(共有)は、TCPを利用する。どちらもIPやそれ以下の層や名前解決サービスに依存している。TCPのテストにはFTP(File Transfer Protocol)プログラムを用いて行なうのが便利である。
9.2.3.1 FTPを用いたTCPのテスト
FTPを用いてサーバ自身からとクライアントからとそれぞれ接続を行なってみる:
server%ftp serverConnected to server.example.com. 220 server.example.com FTP server (Version 6.2/OpenBSD/Linux-0.10) ready. Name (server:davecb): 331 Password required for davecb. Password: 230 User davecb logged in. ftp>quit221 Goodbye.これが動作した場合、セクション Section 9.2.4, Troubleshooting Server Daemonsに進む。うまく行かなかった場合は、以下を参照する:
"server: unknown host"というメッセージを受け取った場合、名前解決サービスに不具合がある。関連する ping のテストである セクション 9.2.2.2, pingを用いたローカル名前解決サービスのテストに戻って、名前解決が失敗している原因を探るため、再度テストを行なってみる。
"ftp: connect: Connection refused"というメッセージを受け取った場合は、そのマシン上でFTPデーモンが実行されていない。これはUNIXサーバではあまり一般的なことではない。この場合FTPの代わりにtelnetを用いてマシンに接続することでこのテストを行なうことができるだろう。telnetもTCPを利用しており、表示されるエラーメッセージはほぼ同様である。
長時間の経過後に、"ftp: connect: Connection timed out"というメッセージが出力された場合、マシンには接続できていない。セクション Section 9.2.2.4, Testing connections with pingに戻って確認を行なうこと。
"530 Logon Incorrect"というメッセージを受け取った場合は、接続は成功しており、別のレベルの問題が発生している。恐らく不正なユーザ名かパスワードが入力されている。UNIXサーバ上にあるユーザ名を入力しているか、パスワードを正しく入力しているかを確認して再度接続を行なってみること。
9.2.4 サーバデーモンのトラブルシューティング
TCPが正しく動作していることを確認できれば、次はデーモンがサーバ上で動作しているかどうかの確認である。単一のテストではサーバが正しく動作していることを確認できないため、動作を確認するには3つの独立したテストが必要である。
動作していることを確認するためには、以下を確認する必要がある:
9.2.4.1 まず確認すること
まずはログを確認する。デーモンが開始されていた場合、"smbd version some_number started" というメッセージがあるはずである。メッセージがない場合は、Sambaデーモンを再起動する必要がある。
デーモンが起動したというログが存在している場合は、"bind failed on port 139 socket_addr=0 (Address already in use)"というメッセージを探す。これは別のデーモンがポート139(smbd)で起動しているということを意味する。 nmbdもポート137にバインドできないと同様のエラーを出力する。この原因はデーモンを二重起動しようとしたか、 inetd サーバにSambaのデーモンが登録されているかである。後者の場合、すぐに切り分けを行なうことができる。
9.2.4.2 psによるデーモンプロセスの確認
次に必要なのはデーモンが本当に起動しているかどうかの確認である。サーバ上で
psコマンドにマシンに応じたlongオプション(通常psaxかps-ef)を付けて実行することで、 smbd と nmbd が既に実行されているかどうかを確認できる。この結果は通常以下のようになる:server%ps axPID TTY STAT TIME COMMAND 1 ? S 0:03 init [2] 2 ? SW 0:00 (kflushd) (...many lines of processes...) 234 ? S 0:14 nmbd -D3 237 ? S 0:11 smbd -D3 (...more lines, possibly including more smbd lines...)この例では smbd と nmbd は単体のデーモンとして(
-Dオプション)、ログレベル3で起動されている。9.2.4.3 デーモンがバインドされているポートの確認
TCP/IPのポートにアクセスするには、デーモンがOSによって登録されている必要がある。
netstatコマンドはこれが行なわれているかどうかを表示する。サーバ上でnetstat-aを実行し、netbios,137,139という行を参照する:server%netstat -aActive Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 *.netbios- *.* tcp 0 0 *.netbios- *.* LISTEN tcp 8370 8760 server.netbios- client.1439 ESTABLISHEDもしくは:
server%netstat -aActive Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 *.137 *.* tcp 0 0 *.139 *.* LISTEN tcp 8370 8760 server.139 client.1439 ESTABLISHED少なくとも
*.netbios-もしくは*.137というUDPの行が1行はある筈である。これは nmbd サーバが登録されており、(恐らく)要求を待ち受けていることを示すものである。また*.netbios-もしくは*.139というTCPの行も1行はある筈であり、これは恐らく LISTENING 状態になっているはずである。 これは smbd が起動しており、接続を待ち受けていることを示す。その他にも smbdからクライアントへの接続を示すTCPの行が各クライアント毎に存在することもある。これらは通常 ESTABLISHED の状態になっている。 smbd 行が ESTABLISHED になっている場合、 smbd は起動していると結論づけられる。LISTENING 状態の1行だけだった場合は、まだ断定はできない。1行も出力されていない場合は、デーモンは起動に成功していない。ログファイルをチェックした上で、Chapter 2に戻って確認を行なうこと。
クライアントの接続を示す行が存在している場合、それはSambaデーモンによって生成されたものかも知れないが、スーパーデーモンである inetdによって生成されたものかも知れない。気付かないうちに、 inetd の設定ファイルにSambaデーモンを起動する設定が含まれている可能性は大いにある。例えば Linux ディストリビューションの一貫としてSambaをインストールした場合などに設定が行なわれていることがある。 inetd から起動されるデーモンはスタンドアローンなデーモンの起動を妨げる。この場合は通常ログに"bind failed on port 139 socket_addr=0 (Address already in use)"のようなメッセージが生成される。
/etc/inetd.conf を確認すること。意図的にデーモンをここから起動しているのでない限りは、
netbios-ns(udp port 137) もしくはnetbios-ssn(tcp port 139) ポートを利用するサーバは 存在してはならない。 inetd は /etc/inetd.confの設定によって多数のサービスを提供するデーモンである。システムでSMBデーモンを inetd経由で提供している場合は、以下のような行がファイル中に存在する:netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd9.2.4.4 telnetによるsmbdのチェック
皮肉にも、 smbd サーバが本当に動作しているかどうかを確認する最も簡単な方法は、無意味なメッセージを送信して、それを拒否することを確認することである。以下のようにして確認してみよう:
echo hello | telnet localhost 139これは不正ではあるが無害なメッセージを smbdに送信している。
helloというメッセージは重要である。ポート139にtelnet を行なって、適当に文字を入力したりはしないように。プロセスをハングアップさせてしまう可能性がある。helloは無害なメッセージである。server%echo "hello" | telnet localhost 139Trying Trying 192.168.236.86 ... Connected to localhost. Escape character is '^]'. Connection closed by foreign host."Connected" に引続き "Connection closed" というメッセージを受け取った場合は、テストが成功している。 smbd デーモンはポートを監視しており、不正な接続要求を拒否している。一方"telnet: connect: Connection refused"というメッセージを受け取った場合、恐らくデーモンが存在していない。ログを確認した上でChapter 2に戻ること。
不幸なことに、 nmbdをテストする簡単な方法は存在しない。
telnetのテストとnetstatのテストとで smbd が存在していることが確認できた場合、netstatにより nmbd が実行されていることも確認できることだろう。9.2.4.5 testparmを使ったデーモンのテスト
デーモンの存在が確認できた場合、
testparmを実行すべきである。以下のような出力がある筈である:server%testparmLoad smb config files from /opt/samba/lib/smb.conf Processing section "[homes]" Processing section "[printers]" ... Processing section "[tmp]" Loaded services file OK. ...
testparmプログラムは通常各セクションを解析して、成功した場合は"Loaded services file OK" という応答を返却する。成功しなかった場合は、以下のようなメッセージが返却される。これはログにも書き込まれる:
- "Allow/Deny connection from account (n) to service"
smb.confの中でvalid/invalid user オプションを設定していると、 testparm固有のメッセージが出力される。自分が valid user の中にいることや、root, bin 等がinvalid user の中にいることを確認したい場合もあるだろう。確認できない場合、自分が接続できず、接続できてはいけないアカウントで接続できてしまうことがある かも知れない。
- "Warning: You have some share names that are longer than eight chars"
Windows for Workgroups かそれより古いクライアントを利用している場合、長い名前を利用した共有への接続が失敗する。その際メモリがオーバーフローしたようにとれるメッセージが発生するため混乱することになる。
- "Warning: [name] service MUST be printable!"
プリンタ共有に
printable=yesの指定が抜けている。- "No path in service name using [name]"
ファイル共有でユーザに提供するディレクトリの位置が指定されていないか、プリンタ共有でスプールに利用するディレクトリが指定されていない。パスが指定されていない場合、サービスでは、 /tmp が指定されているとみなして動作する。これは期待する動作ではないだろう。
- "Note: Servicename is flagged unavailable"
共有に
available=noオプションを指定していることへの注意である。- "Can't find include file [name]"
includeオプションによって参照されている設定ファイルが存在しない。無条件でファイルを含める設定の場合、これは恐らく、共有が期待したとおりに設定されていないという致命的なエラーになってしまう。%a(architecture)のような%変数のどれかを使って含めるファイルを指定していた場合は、例えば Windows for Workgroups 用の設定ファイルが存在しないと問題かどうかといったことを自分で判断する必要がある。多くの場合問題ではないだろう。- "Can't copy service name, unable to copy to itself"
smb.conf セクションのコピーをそのセクション自身に対して行なおうとした。
- "Unable to copy service - source not found: [name]"
copy=オプションで指定されたセクションが存在しないかスペルを誤っている。- "Ignoring unknown parameter name"
通常無効になったか、スペルを誤ったかサポートされていないオプションを設定している。
- "Global parameter name found in service section"
個々の共有中にGlobalセクションのみで、用いることができるパラメータが含まれている。Sambaはこのパラメータを無視する。
testparmのテストを行なった後で、以下の3つのパラメータ、 smb.confの名前、クライアントの名前、そのIPアドレスを用いて再度テストを行なってみる:testparmsamba_directory/lib/smb.conf client 192.168.236.10
hostallowおよびhostdenyオプションがホスト名やアドレスに対して動作しているかどうかを確認するために、このテストを何回か行なうことになるだろう。このテストは "Allow/Deny connection from account account_name" というメッセージをクライアントに返却する。このメッセージは valid/invalid host オプションが smb.conf 中にあり、オプションによってクライアントからのアクセスが拒否されていることを示すものである。testparm/usr/local/lib/experimental.confのように入力するのも、実験的(experimental)な smb.conf ファイルを実環境に置く前にテストを行なうのに有用な方式である。9.2.5 SMB接続のトラブルシューティング
ここまででサーバは起動した。次はサーバが正しく動作しているかの確認である。まずは
samba_directory/lib ディレクトリに存在する smb.confファイルから見ていこう。9.2.5.1 最低限のsmb.confファイル
以下のテストを行なう上で、テスト用として
[temp]という共有を定義した。更に最低限1つのアカウントが必要である。これらを満たす smb.confファイルを以下に示す:[global] workgroup =EXAMPLEsecurity = user browsable = yes local master = yes [homes] guest ok = no browseble = no [temp] path = /tmp public = yes警告しておくが、
public=yesオプションを[temp]共有に設定したのはテストの便を図ってのことである。アカウントを持たない利用者が、Sambaサーバ上にデータを蓄積できてしまうことは望ましいことではないであろう。テストが終ったらこれはコメントアウトすべきである。9.2.5.2 smbclientクライアントを用いたローカルでのテスト
最初におこなうのはサーバが自分のサービス(共有)を一覧できるかどうかのテストである。
smbclientコマンドに-Llocalhostオプションを付けて自分自身に接続させ、-U%でゲストユーザを指定している。以下のような出力が得られるはずである:server%smbclient -L localhost -U%Server time is Wed May 27 17:57:40 1998 Timezone is UTC-4.0 Server=[localhost] User=[davecb] Workgroup=[EXAMPLE] Domain=[EXAMPLE] Sharename Type Comment --------- ----- ---------- temp Disk IPC$ IPC IPC Service (Samba 1.9.18) homes Disk Home directories このマシンはブラウズリストを保持していない。このような出力を受け取ったら、次のテスト、 Section 9.2.5.3, Testing connections with smbclientに進もう。一方エラーが出力された場合は、以下を確認すること:
"Get_hostbyname: unknown host localhost,"という返答を受け取った場合は、名前をスペルミスしているか、本当に問題が発生しているかのいずれかである(問題の解析については Section 9.2.2.2を参照のこと)。後者の場合、"Troubleshooting Name Services."を参照すること。
"Connect error: Connection refused,"という返答を受け取った場合は、サーバマシンは見付かっているが、 nmbd デーモンが走行していない。 Section 9.2.4に戻ってデーモン関連を再度テストすること。
"Your server software is being unfriendly,"というメッセージを受け取った場合、最初のセッションリクエストパケットに対するサーバからの応答が不正である。サーバがクラッシュしているか、正しく開始されていない。一般的な原因はログを検索することで発見できる:
smbdの起動時を妨げるような致命的な問題が smb.confにある。 Section 9.2.4.5, testparmを用いたデーモンのテストで記述したように変更を行なう度に確認を行なうこと
スタンドアローンではなく inetdを利用している場合、 /etc/inetd.conf と /etc/services のエントリについて、マニュアルページを参照してエラーがないことを確認する。
Password:プロンプトが出てくる場合、ゲストアカウントが正しく設定されていない。%Uオプションを確認することで、 smbclient が、ゲストアカウントが存在していれば、特に権限を必要としない"null login"を行なおうとしているかを確認できる。"SMBtconX failed. ERRSRV - ERRaccess,"というメッセージを受け取った場合、サーバへのアクセスが許可されていない。これは通常
validhostsオプションにサーバが含まれていないか、invalidhostsオプションにサーバが含まれていることを意味する。testparmsmb.confyour_hostnameyour_ip_address(セクション Section 9.2.4.5を参照のこと)コマンドを用いて設定を再確認し、意図しないアクセス拒否の設定を修正すること。9.2.5.3 smbclientによる接続のテスト
smbclient\\server\tempというコマンドを実行する。これはサーバの /tmpに対する共有に接続を行なうことで、ファイルサービスに接続することができることを確認するものである。以下のような応答があるはずである:server%smbclient '\\server\temp'Server time is Tue May 5 09:49:32 1998 Timezone is UTC-4.0 Password:smb:\>quit
"Get_Hostbyname: Unknown host name,"や "Connect error: Connection refused,"、もしくは "Your server software is being unfriendly,"という応答が返却される場合は、セクション Section 9.2.5.2, Testing locally with smbclientをみて問題の切り分けを行なうこと。
"servertemp: Not enough `\' characters in service,"という返答が返却された場合は、恐らくアドレスをクォートしていないため、UNIXがバックスラッシュ(monyo 訳注: \記号)を取り除いてしまっている。コマンドを以下のように記述すること:
smbclient\\\\server\\tempもしくは以下のように記述することもできる:
smbclient //server/temp
Passwordプロンプトに対しては、UNIXアカウントのパスワードを入力する。smb\>プロンプトが現れたら、サーバは動作していると考えて良い。quitを入力して、引続き Section 9.2.5.4, Testing connections with NET USEを行なっていこう。"SMBtconX failed. ERRSRV - ERRinvnetname,"という応答が返却された場合、以下のいずれかの問題が発生している:
共有名が間違っている。スペルを誤っている、名前が長すぎる、大文字と小文字が混在している、共有が利用可能でないなどが考えられる。testparm を用いて(セクション Section 9.2.4.5を参照のこと)、自分が意図したように設定されていることを確認すること。
security=shareになっている。この場合、 smbclientコマンドに-U your_accountというオプションを追加するか、temp という名前の UNIXアカウントのパスワードを知っている必要があるsmb.conf中の
invalidusersもしくはvalidusersオプションにより、そのアカウントでの接続が許可されていない。testparmyour_hostname your_ip_address( Section 9.2.4.5を参照のこと)を用いてsmb.confを再度チェックすること。 .
validhostsオプション中でそのサーバが指定されていないか、invalidhostsオプションでサーバが指定されている。 こちらも testparmコマンドを用いて確認すること。サーバでシャドウパスワードやPAM(Password Authentication Module(monyo 訳注: Pluggable Authentication Module?))がサーバで用いられているにも関わらず、Sambaがそれらを利用するようにコンパイルされていないため、認証に問題が発生している。これは稀なことであるが、SunOS 4 の Samba バイナリ(シャドウパスワードを利用していない)をSolaris システム(シャドウパスワードを利用している)上で再コンパイルせずに利用した場合などに発生することがある。
設定ファイル中で
encryptedpasswords=yesになっているが、 smbpasswd ファイル中にアカウントのパスワードが存在しない。
[temp]に接続しようとしているが、guestok=yesオプションが smb.confファイル中の[temp]セクションで指定されていない。ホームディレクトリに接続する前に
[temp]に接続しようとしており、ゲストアカウントの設定が正しく行なわれていない。ホームディレクトリに接続してから、[temp]に接続しようとした場合に発生する。基本的なSamba設定ファイルの作成に関する情報については、Chapter 2を参照のこと。ゲストアカウントの設定に問題があると、ホームディレクトリに接続するまで、印刷やブラウジングができないといった問題も発生する。
もう一つ、パスワードとは全く無関係な理由も考えられる。 smb.confファイル中の
path=行が存在しない場所を指定していた場合である。これは testparmコマンドで切り分けすることもできず、ほとんどのSMBクライアントはユーザアカウントの問題と区別することができない。これについては手作業で確認するしかない。
[temp]に接続できたら、今度は接続先をホームディレクトリに替えて再度試験を行なって(例えば、server\davecbをネットワークドライブに割り当てる)、エラーが発生しないことを確認する。接続させるために何か設定を変更する必要がある場合は、再度[temp]に対するテストを行なうこと。9.2.5.4 NET USEを用いた接続のテスト
Windowsマシンからサーバに接続できることを確認するために、DOSやWindowsクライアントから
netuse*\server\tempを実行してみる。パスワードを求めるプロンプトが表示されてから、 図 9.2のような、"The command was completed successfully,"という応答を受け取るはずである。図 9.2: NET USE コマンドの実行結果
これが成功したら、セクション Section 9.2.5.5, Windows Explorer を用いた接続性のテストの手順を続行する。失敗した場合は、以下を確認する:
"The specified shared directory cannot be found,"もしくは"Cannot locate specified share name,"という応答を受け取った場合、ディレクトリ名をスペルミスしているか、そもそも smb.confファイル中に存在しない。このメッセージは、名前に大文字と小文字が混合している場合、スペースを含む場合、8文字より長い場合にも出力されることがある。
"The computer name specified in the network path cannot be located,"もしくは"Cannot locate specified computer,"という返答を受け取った場合、ディレクトリ名をスペルミスしている、名前解決サービスに問題がある、ネットワークの問題である、
hostsdeny=オプションに自分のホストが含まれているといった可能性が考えられる。
スペルミスでない場合、少なくともセクション Section 9.2.5.3まで戻って、なぜ接続できないかを調査する必要がある。
smbclient で動作する場合、クライアント側の名前解決サービスの問題であろう。先にあるセクション Section 9.2.6.2, Testing the server with nmblookupを見て、 nmblookupを用いてクライアントとサーバの双方から互いの名前解決ができるかどうかを確認する。
"The password is invalid for
\server\username"という応答が返却された場合、クライアント側にキャッシュされたパスワードがサーバ側と合致していない。プロンプトが表示されるので、パスワードを再度入力する。Windows 95 および 98 クライアントはローカルに パスワード ファイルを保持するが、これはSambaやNTサーバに認証のために送ったパスワードを複製してキャッシュしたものに過ぎないため、プロンプトが表示されたのである。Windowsマシンにはパスワードなしでログオンできる(しかしNTは違う)。
パスワードを再入力してもなお接続に失敗する場合、入力したパスワードがサーバ側のものと合致していないか、
validusersもしくはinvalidusersによってアクセスを拒否されているか、NetBEUI が悪影響を与えているか、次のパラグラフで説明する暗号化パスワードの問題が起こっているかのいずれかであろう。クライアントがNT 4.0、NT 3.5 with Patch 3、Windows 95 with Patch 3、Windows 98もしくはInternet Explorer 4.0を搭載したマシンである場合(monyo 訳注: この記述は錯乱している。NT 4.0 SP3以上か、Windows 95 OSR2.1以上、もしくはWindows 98が正しい)、デフォルトで Microsoftの暗号化方式を用いてパスワードを暗号化する(代替策も含めた記述がChapter 6, Users, Security, and Domains's Section 6.4, Passwords in Chapter 6セクションにある)。通常最近の主なMicrosoft製品をインストールした場合は、アップデートを行なって暗号化パスワードを有効にしていることだろう(monyo 訳注: 最近の製品では全て暗号化パスワードがデフォルトになっている)。
Internet Explorerが file://somehost/somefileといったURLに対してSMB接続を行なうため、Windows 95 Patch Level2(monyo 訳注: これも具体的に何のバージョンを表しているかが不明である。恐らく Windows NT 4.0 SP2のことだと考えられる)までのクライアントでは簡単にパスワードをインターネット上のどこかにあるSMBサーバに対して平文のまま送信してしまう。これは問題のある仕様であり、Microsoftも早急にSMBプロトコルで暗号化パスワードしか送信しないように変更し、以降にリリースされたプロダクトは仕様が変更になっている。Internet Explorer 4.0をファイアウォールなしで用いているのでない限り、暗号化パスワードは実際のところ必要ではないため、自ネットワーク上で非暗号化パスワードを利用し続けるのもよいだろう(monyo 訳注: 現行のセキュリティに対する考え方では、暗号化パスワードの利用は必須と見なされている筈である)。
UNIXで大文字と小文字が混在したパスワードを利用している場合も、クライアントは恐らくパスワードの大文字小文字を統一して送信している(monyo 訳注: 暗号化パスワードを利用している場合は、この問題は原理的に発生しない)。パスワードの文字の大きさを統一すると動作するようであれば、これが問題の原因だと考えられる。残念なことに、非常に古いクライアントは大文字のパスワードしかサポートしていないため、Sambaは一度送信されたパスワードを大文字にして、次に小文字にして認証を行なう。大文字と小文字が混在したパスワードを用いたい場合は、対策に付いてはChapter 6の
passwordlevelオプションを参照すること。smbclientでテストを行なった際の
validusersの問題も考えられる( Section 9.2.5.3を参照のこと)。NetBEUI プロトコルが、Microsoft クライアント(monyo 訳注: 正しくはMicrosoft ネットワーククライアントである)にバインドされているのかも知れない。この場合応答に時間がかかったり、エラーが発生したりすることが頻繁に発生する。また過去のパスワードを受け入れてしまうという問題が発生するという問題も指摘されている(monyo 訳注: これが具体的に何の障害を表しているかは不明である)。
ここで"バインド"という言葉は、あるソフトウェアを別のソフトウェアと協調させる意味で用いられている。Microsoft SMB クライアントは Windows 95/98 のコントロールパネルにあるネットワークアイコンからたどれるTCP/IPのプロパティの"バインド"タブでTCP/IPと"バインド"される。TCP/IPは更にEthernetカードとバインドされている。この"バインド"はSMBデーモンをTCP/IPポートと"バインド"するという際の"バインド"とは別のものである。
9.2.5.5 Windows Explorer を用いた接続性のテスト
Explorer が /tmpディレクトリに接続できることを確認するために、Windows Explorer や NT Explorer (Internet Explorerではない)を起動して、[ツール]→[Map Network Drive]を選択して、\\
server\tempと入力する。 図 9.3のような画面が現れるはずである。この場合、接続は正常に行なわれており、次のセクションに Section 9.2.6, Troubleshooting Browsingに進んで良い。図 9.3: Windows Explorer での /tmp ディレクトリへのアクセス
Windows Explorer や NT Explorer は、診断ツールとしてはあまり適切ではない。何か問題があるということは分かっても、何が問題なのかが分かることはほとんどないからである。問題が発生したら、NET USE コマンドを用いて切り分けを行なう必要がある。NET USE コマンドでは詳細なエラー出力がおこなわれる:
"The password for this connection that is in your password file is no longer correct,"という応答が返却された場合は、以下のいずれかの問題が発生している:
"The network name is either incorrect, or a network to which you do not have full access,"もしくは"Cannot locate specified computer"という応答が返却された場合、以下のいずれかが原因であろう:
"You must supply a password to make this connection"という応答が返却された場合、クライアントのパスワードとサーバ側でのパスワードが異なっているか、このクライアントからその共有に対して行なわれるはじめての接続であり、クライアントはパスワードをまだローカルにキャッシュしていない。
"Cannot locate specified share name,"という応答が返却される場合、指定した共有名が誤っているか、8文字以上の共有名を指定する、大文字と小文字が混在していたり、名前にスペースが含まれているなど指定方法に文法ミスがある(monyo 訳注: Windows NTマシンからアクセスする場合は...)。
[temp]ディレクトリに接続できたら、今度はホームディレクトリに接続を行なってみる。ホームディレクトリのアクセスに際して設定を変更する必要があった場合は、再度[temp]共有に対して、セクション Section 9.2.5.4で記述したようにして接続してみる。また Explorer から接続を行なうと失敗する場合も、上記セクションに戻って再度切り分けを行なうこと。9.2.6 ブラウジングのトラブルシューティング
最後にブラウジングに付いて扱う。これは深刻な問題ではなく、パケットの送達を保証しないプロトコルに部分的に依存するため、最後まで残しておいた。他の全てのサービスが実行していることを確認していないと、ブラウジングの診断は困難である。
ブラウジングは本質的に必須のものではない。これはネットワーク上のサーバやサーバが提供する共有を見付ける方法に過ぎない(monyo 訳注: サーバが提供している共有の一覧取得は厳密には、ブラウジングの機能ではない)。UNIXはこうした機構を持たないことで、幸せに暮らしている。ブラウジング機能は全てのマシンがブロードキャストが到達可能なLAN上に存在していることを前提としている。
また、ブラウジング機構は、信頼性のないUDPプロトコルを用いてマシンの特定を行なっている。ただし、マシンが提供する共有を一覧する際には通常の(信頼性のある)TCP/IP接続が用いられる。
9.2.6.1 smbclientによるブラウジングのテスト
まず信頼できる接続で確認することから始めよう。サーバから
-Lに自分のサーバ名を指定して smbclient を実行して自分自身の共有を一覧してみよう。以下のような出力が得られるはずである:server%smbclient -L serverAdded interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Server time is Tue Apr 28 09:57:28 1998 Timezone is UTC-4.0 Password: Domain=[EXAMPLE] OS=[Unix] Server=[Samba 1.9.18] Server=[server] User=[davecb] Workgroup=[EXAMPLE] Domain=[EXAMPLE] Sharename Type Comment --------- ---- ------- cdrom Disk CD-ROM cl Printer Color Printer 1 davecb Disk Home Directories This machine has a browse list: Server Comment --------- ------- SERVER Samba 1.9.18 This machine has a workgroup list: Workgroup Master --------- ------- EXAMPLE SERVER
共有名の一覧が取得できないときは、サーバが共有のブラウジングを全く許可していない。WindowsのExplorerやNET USEコマンドを用いたテストが正常の場合、このこと自体は問題でない。
smbclient-Llocalhost-U%テスト(see Section 9.2.5.2)を行なっていない場合は、それを今行なうこと。ゲストアカウントの設定を誤ると共有の一覧ができなくなる。 smb.conf ファイルをチェックして、browsable=noがないことも確認する。最小限の smb.conf ファイル(see Section 9.2.5.1, 最低限のsmb.confファイル)を利用することを推奨する。少なくとも[temp]共有を見るためにbrowseableを有効にする必要がある。ブラウズリストを入手できない場合、サーバがネットワーク上のマシンの情報を提供していない。ネットワーク上で少なくとも1台のマシンがブラウズリストを提供する必要がある。Sambaにローカルマスタブラウザをさせたい場合は、 smb.confファイル中で
localmaster=yesに設定する。ブラウズリストは入手できたが /tmpを入手できない場合、恐らく smb.confに問題がある。 Section 9.2.4.5に戻ること。
ワークグループのリスト中に自分のワークグループ名がない場合、恐らく自分のワークグループ名が smb.confファイル中で正しく設定されていない。
ワークグループ名のリストを全く入手できないときは、
workgroup=EXAMPLEという行が smb.confファイル中にあるかどうかを確認すること。何も入手できない場合は、NetBIOS名とワークグループ名を大文字にした上で、
-Iip_address-nnetbios_name-Wworkgroup-d3(-d3オプションはログのデバッグレベルを3にする)といったオプションを付けて再度試してみること。これでも何も出力されない場合は、根本的に問題がある。少なくとも Section 9.2.3.1, Testing TCP with FTP か、恐らく Section 9.2.2.4まで戻ること。そうでない場合は以下を確認のこと:
"SMBtconX failed. ERRSRV - ERRaccess,"と返却された場合は、サーバにアクセスする権限がない。これは通常
validhostsオプションでサーバ自身が指定されていないか、invalid hosts オプションに指定されてしまっている。ゲストアカウントがどうなっているか( Section 9.2.5.2を参照)を確認してから、
testparmsmb.confyour_hostname your_ip_addressコマンドを用いて smb.conf ファイルをチェックし( Section 9.2.4.5を参照)、hostsallow,hostsdeny,validusers,invalidusersの行を変更するかコメントにする。"Connection refused,"と返却された場合、 smbdサーバが動作していないか、クラッシュしている。 netstatコマンドを使って、 smbdが起動して接続を待機しているかどうかを確認する。 Section 9.2.4.5を参照のこと。
"Get_Hostbyname: Unknown host name,"と返却された場合、スペルを誤っており、UNIXとNetBIOS名の整合性がとれていないか、名前解決サービスに問題がある。 Section 9.2.5.4の方法で名前解決サービスのデバッグを開始すること。名前解決が動作している場合は、名前の不整合が考えられる。 Section 9.2.10, NetBIOS名のトラブルシューティングの手順を実行すること。
"Session request failed,"と返却された場合、サーバが接続を拒否している。これは通常プロセスをフォークするのに必要なメモリが不足しているなどの内部エラーによって発生する。
"Your server software is being unfriendly,"と出力される場合、最初のセッションリクエストパケットに対するサーバからの応答が不正である。サーバがクラッシュしているか、正しく開始されていない。まずは Section 9.2.5.2に戻って問題を解析すること。
サーバが動作していないと思われる場合は、 Section 9.2.4.2, Looking for daemon processes with psに戻って、なぜデーモンが応答しないかを見極めること。
9.2.6.2 nmblookupによるサーバのテスト
ここではWindowsの名前解決サービスとブラウジングの為に、システムが"アナウンス(monyo 訳注: 原文はadvertising)"されているかどうかをテストする。"アナウンス"はマシンの存在や提供しているサービスの情報をブロードキャストすることで行なわれる。これはブラウジングの一部であり、信頼性のないプロトコル(UDP)を使って行なわれており、Ethernetのようなブロードキャストネットワークでのみ機能する。 nmblookupは入力された名前についてブロードキャストで問い合わせを行ない、DNSで nslookupが行なっているように、マシンの名前とIPアドレスを返却する。 ここで
-dは (debug level、もしくはlog level) オプションであり、-B(ブロードキャストアドレス)は、特定のマシンに対して直接問い合わせるオプションである。まず、サーバ上で自分自身を確認してみよう。 nmblookup コマンドに
-Bオプションで自分のサーバ名を指定して、問い合わせがSambaサーバに行くようにした上で、問い合わせを行なう名前として__SAMBA__を指定して実行する。以下のように出力されるはずである:server% nmblookup -Bserver__SAMBA__ Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Sending queries to 192.168.236.86 192.168.236.86 __SAMBA__
__SAMBA__という名前とともにサーバのIPアドレスが取得できるはずだ。これはサーバが__SAMBA__というサービスを正常にアナウンスできており、少なくともNetBIOS名前解決サービスのある部分に付いては動作しているということである。
"Name_query failed to find name __SAMBA__"と返却された場合、
-Bオプションで誤ったアドレスを指定しているか、 nmbdが動作していない。-Bオプションは通常ブロードキャストアドレスを指定するが、ここではユニキャストアドレスであるマシンの名前を指定することで、サーバが__SAMBA__という名前を登録(monyo 訳注: 原文はclaim)しているかどうかを問い合わせた。
-Bip_addressでもう一度試してみる。これも失敗する場合は、 nmbdは名前を登録していない。 nmbdが起動しているかどうかを確認するために、少しの間"testparmを用いたデーモンのテスト"に戻って確認をしてみる。起動していても、名前が登録されていないかも知れない。これはSambaがブラウジングサービスを提供していないということであり、設定の問題である。この場合は、 smb.conf にbrowsing=noがないことを確認する。9.2.6.3 nmblookup によるクライアントのテスト
次にサーバ上で nmblookupに
-Bオプションを付けてクライアントの名前を指定した上で、"全て"を意味する'*'という引数も付けて以下のように起動し、クライアントのIPアドレスを確認する:server% nmblookup -B client '*' Sending queries to 192.168.236.10 192.168.236.10 * Got a positive name query response from 192.168.236.10 (192.168.236.10)
"Name-query failed to find name *,"と返却された場合は、スペルを誤っているか、PC上でクライアントのソフトウェアがインストールされていないか、起動していないか、もしくはTCP/IPにバインドされていないかである。Chapter 2 もしくは Chapter 3に戻って、クライアントソフトウェアがインストールされており、起動していることを確認すること。
エラーが発生した場合は、以下のオプションを付けてコマンドを再度発行する:
nmblookup-Bclient_IP_addressは成功するが、-Bclient_nameが失敗する場合、クライアントの名前を解決する際の名前解決サービスに問題がある。 Section 9.2.8を参照すること。
nmblookup-B127.0.0.1 '*'は成功するが、-Bclient_IP_addressは失敗する場合、ハードウェアに問題が発生しており、pingも失敗する筈である。ネットワーク管理者に連絡すること。9.2.6.4 nmblookupによるネットワークのテスト
再度 nmblookup コマンドに
-dオプション(debug level)を2にした上で、'*'を引数にとって実行する。今回は、プログラム( nmbd 等)がブロードキャストを用いていることを確認する。これは基本的にデフォルトのアドレスにブロードキャストを行なうことによる接続性のテストになる。多くのネットワーク上のNetBIOS/TCP-IPホストは"got a positive name query response"というメッセージで応答する。Sambaは短時間でその全てを受信することはできないかも知れないため、ネットワーク上の全てのSMBクライアントが確認できるわけではないが、そのほとんどを確認できる筈である:
server% nmblookup -d 2 '*' Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Sending queries to 192.168.236.255 Got a positive name query response from 192.168.236.191 (192.168.236.191) Got a positive name query response from 192.168.236.228 (192.168.236.228) Got a positive name query response from 192.168.236.75 (192.168.236.75) Got a positive name query response from 192.168.236.79 (192.168.236.79) Got a positive name query response from 192.168.236.206 (192.168.236.206) Got a positive name query response from 192.168.236.207 (192.168.236.207) Got a positive name query response from 192.168.236.217 (192.168.236.217) Got a positive name query response from 192.168.236.72 (192.168.236.72) 192.168.236.86 *うまく行かない場合:
先程テストを行なったクライアントからも返答がない場合は、デフォルトのブロードキャストアドレスが不正である。奥の手(全てのホストに対するブロードキャストアドレス)を用いて
nmblookup-B255.255.255.255-d2'*'を実行してみる。これで応答が来るようであれば、先程用いたブロードキャストアドレスは不正であるといえる。このトラブルシューティングについては、本章の後の方にある Section 9.2.9.2, Broadcast addresses のセクションで記述している。255.255.255.255に対するブロードキャストも失敗する場合は、PCとサーバが異なったサブネットに存在していないことを Section 9.2.2.4で記述した方法で確認する。この問題はクライアントとサーバを同一のサブネット上に置いて診断すべきであるが、それが不可能な場合は、リモートサブネットのブロードキャストアドレスを
-Bオプションで指定することもできる。アドレスを算出する方法に付いては、ブロードキャストアドレスのトラブルシューティングと同じセクションで、本章の後の方にある Section 9.2.9.2に記述されている。-Bオプションはルータがブロードキャストアドレスへのパケットをサポートしている場合のみ動作する。サポートされていない場合は、クライアントとサーバを同じネットワーク上に置いてテストを行なう必要がある。9.2.6.5 net view によるクライアントのブラウジングのテスト
クライアント側のDOSウインドウで
net view \\serverというコマンドを実行することで、クライアントがサーバに接続して共有しているリソースの一覧を問い合わせることが可能であることを確認できる。 図 9.4に示すようにサーバ上で利用可能な共有の一覧が返却されるはずである。図 9.4: net view コマンドの利用
このような応答を受け取ったら、引続き Section 9.2.7, その他の問題のセクションへと進むこと。
セクション Section 9.2.6.3, nmblookyupによるクライアントのテストでテストした名前に付いても"Network name not found"という応答が返却された場合は、クライアントのソフトウェア自身に問題が発生している。 nmblookupをクライアント上で実行することで、これを確認できる。これが動作するがNET VIEWが動作しない場合、クライアントに異常が発生している。
nmblookupも失敗した場合は、NetBIOSの名前解決サービスの問題である。これはセクション Section 9.2.10で記述している。
"You do not have the necessary access rights,"か"This server is not configured to list shared resources,"という応答が返却された場合は、ゲストアカウントの設定に問題があるか( Section 9.2.5.2を参照)、
hostsallowやhostsdenyの行で、テストしたマシンからの接続が禁止されている。これらの問題は Section 9.2.6.1, Testing browsing with smbclient の冒頭にある、 smbclient を用いたテストで発見することができる。"The specified computer is not receiving requests,"という応答が返却された場合、名前のスペルを誤っていて、マシンがブロードキャスト("Testing the network with nmblookup"でテストを行なっている)に応答していないか、 nmbdが実行されていない。
"Bad password error,"という応答が返却された場合、恐らくMicrosoftの暗号化パスワードによる問題である。これについてはChapter 6で対処方法が記述されている。
9.2.6.6 クライアントからサーバをブラウズする
ネットワークコンピュータより(古いソフトウェアではファイルマネージャより)サーバをブラウズしてみる。Sambaサーバが自分の所属するワークグループ内に現れる筈である。サーバの名前の付いたアイコンをダブルクリックすることで、 図9.5に示したような共有の一覧が見えるはずである。
図 9.5: サーバ上の共有一覧
"Invalid password"というエラーがNT 4.0, NT 3.5 with Patch 3, Windows 95 with Patch 3, Windows 98もしくは、Internet Explorer 4.0を搭載したマシン上(monyo 訳注: この記述は錯乱している。NT 4.0 SP3以上か、Windows 95 のOSR2.1以上もしくはWindows 98が正しい)で発生した場合、これも恐らく暗号化パスワードの問題である。これらのクライアントはデフォルトでパスワードをMicrosoftの暗号化方式を用いて暗号化する(Chapter 6を参照のこと)。
"Unable to browse the network"というエラーが返却された場合、以下のいずれかが発生している:
9.2.7 その他の問題
ここに来たということは、問題が解決されたか、見たことのない問題に遭遇しているかのどちらかである。次のセクションでは、Samba自身ではなく、Sambaを実行するのに必要な環境のトラブルシューティングを扱う。
9.2.7.1 Not logging on
典型的な問題として、クライアントにログオンするのを忘れたり、不正な(Sambaにアカウントのない)ユーザでログオンしたりしている場合がある。前者を診断するのは不可能である。Windowsは、親切にもそのままログオンを続行してしまう。ローカルマシン上で、後者に関する唯一の警告はログオン時に新しいアカウントについての質問を行なって来ることである。これらはどのようにパスワードを入力しても拒否されるという繰り返しとなって現れる。他にできることがなければ、ログオフかシャットダウンを行なってから再度ログオンしてみること。
9.2.8 Troubleshooting Name Services
このセクションでは、名前解決サービス全般に付いての単純だがSambaに影響を及ぼすよくある問題についてのトラブルシューティングを紹介する。
特定の名前解決サービスについてのトラブルシューティングについては、幾つかの良書が出版されている: Paul Albitz と Cricket Liuによる DNS and Bind はドメインネームサービス(DNS)について、Hal Sternによる NFS and NIS (両書ともO'Reilly出版) はNIS ("Yellow pages")について記述されている。WINS (Windows Internet Name Service)、 hosts/LMHOSTSファイルや NIS+については各ベンダのマニュアルを参照するのが一番であろう。
このセクションで扱う問題は以下のとおりである:
9.2.8.1 Identifying what's in use
まず、サーバとクライアント各々が与えられた名前のIPアドレスを検索する際にDNS、WINS、NIS、 hosts ファイルの何を用いるかを確認する。マシンの種類毎にこの優先順位は異なっている:
Windows 95 と 98 マシンは、まず WINS と LMHOSTS ファイルを参照してから、ブロードキャストを行ない、最後にDNS と hosts ファイルを参照する(monyo 訳注: この記述は誤りであり、実際はWindows NTと同様である)。
標準規格であるWINSOCKを用いたWindowsのプログラム(PC-NFSなど)は、hosts ファイル、DNS、WINSの順であり、最後にブロードキャストが用いられる。あるプログラムで名前解決が正常に動作しているからといって、SMBクライアントのプログラムの名前解決も正常に行なわれていると勘違いをしないこと。
Samba デーモンは、 LMHOSTS、WINS、UNIXホストの名前解決方式の順であり、最後にブロードキャストを用いる。
UNIXホストはDNS、 hostsファイル NIS NIS+をどのような組合せででも、また一般的にはどのような順序でも設定できる(monyo 訳注: 全てのUNIXがそうとは限らない。特にNIS+を利用できないUNIXは多い。また古いUNIXでは順序の指定はできないことが多い)。
クライアントマシンはWINSとDNSを利用するように、SambaデーモンもWINSとDNSを利用するように、UNIXサーバはDNSを利用するように設定することを推奨する。現在どのようになっているかを知るためには、実際のマシンやメモを見る必要があるだろう。
クライアント側の名前解決サービスは、Chapter 3で記述したように、全て「コントロールパネル」の「ネットワーク」中にあるTCP/IPのプロパティで設定する。現在の設定がどうなっているかを確認するには、ここをチェックする必要がある。サーバ側では、 /etc/resolv.conf ファイルが存在しているかどうかを確認すること。存在していれば、DNSを利用しているということである。もちろんその他の機構を利用しているかも知れない。NISやその他のサービスに付いてもチェックする必要がある。
SolarisなどのSystem V系のOSでは /etc/nsswitch.confファイルを確認すること(monyo 訳注: LinuxなどSystem V系以外のUNIXでも上記ファイルの構文を利用していることがある)。ファイルがあれば、
host:からはじまり、files,bind(monyo 訳注: 少なくともSolaris、HP-UXやLinuxではdnsになっている),nis,nis+が1つ以上後に続いている行を確認する。これが利用されている名前解決サービスになり、記述された順に利用される。また特別なオプションがブラケット(monyo 訳注: []記号)中に記述されていることもある。 files は hosts ファイルを利用することを意味し、 bind(Berkeley Internet Name Daemon)はDNSの利用を意味する。クライアントとサーバで利用する名前解決サービスが異なっていた場合、最初にすべきことはそれを合わせることである。クライアントはDNS、WINS、 hosts ファイル、 lmhosts ファイルだけを利用可能で、NIS や NIS+ は利用できない。サーバは hostsファイル、DNS、NIS、NIS+を利用できるが、SambaサーバがWINSサービスを提供していたとしても、WINSは利用できない。全てのシステムで同じ名前解決サービスを利用することができない場合、サーバとクライアントが同じ情報を利用できているかどうかを注意深く確認する必要がある(monyo 訳注: 実際のところ、Sambaを利用する上では、WINSが正しく動作していれば良く、DNSは関係ない。個人的にはUNIXとWindowsクライアントの名前解決サービスを合致させる必要性というのはあまり感じられない)。
Samba 2.0 (およびバージョン1.9の後半)では、 smbclientに
-R(resolve order) オプションが付加されている。WINSのトラブルシューティングを行なうときは、以下のようにすればよい:smbclient -Lserver-R wins設定可能なオプションは
hosts(これはUNIXマシンが利用している名前解決サービスを意味し、 /etc/hostsファイルだけを表すものではない)、lmhosts、wins、bcast(ブロードキャスト)である。以下のセクションでは、
server.example.comのような完全修飾ドメイン名(FQDN)のことを 長い名前(long name)という用語で記述し、serverのようなFQDNのホスト部のことを 短い名前(short name)という用語で記述する。9.2.8.2 ホスト名が見付からない
以下を試してみること:
nslookupnameを実行する。これに失敗する場合は、 resolv.conf の記述ミス、DNSサーバの停止、短い名前と長い名前の不整合(次のセクションを参照)が考えられる。以下を確認すること:Your /etc/resolv.conf に1行以上のname-server(monyo 訳注: nameserverが正しい)の行が存在し、各々にIPアドレスが記載されていること。これらはDNSサーバのアドレスを示すものである。
記述されていた、各サーバのアドレスにpingを行なってみる。これが失敗するサーバがある場合、そのサーバに障害がある可能性がある。全てのサーバに対して失敗する場合は、ネットワーク自体に問題がある可能性がある。
前に短い名前を用いて名前解決を行なったのであれば、FQDN(例えば server.example.com)を用いて名前解決を行なってみる。長い名前を用いて行なったのであれば、短い名前で行なってみる。結果が前と異なる場合は、次のセクションに進む。
ブロードキャストやWISは
serverのような短い名前だけを解決する(server.example.comsのような長い名前は解決できない)。nmblookup-Sserverを実行する。これはブロードキャストでそのサーバに関連して登録された全ての名前を出力する。今回の例では、以下のようになる:Looking up status of 192.168.236.86 received 10 names SERVER <00> - M <ACTIVE> SERVER <03> - M <ACTIVE> SERVER <1f> - M <ACTIVE> SERVER <20> - M <ACTIVE> ..__MSBROWSE__. <01> - <GROUP> M <ACTIVE> MYGROUP <00> - <GROUP> M <ACTIVE> MYGROUP <1b> - M <ACTIVE> MYGROUP <1c> - <GROUP> M <ACTIVE> MYGROUP <1d> - M <ACTIVE> MYGROUP <1e> - <GROUP> M <ACTIVE>
必要なエントリは、
SERVER<00>である。これはserverマシンのNetBIOS名(monyo 訳注: コンピュータ名)を示す。何度か出てきたワークグループ名も確認できる。これらの行が出力されない場合、ブロードキャストやWINSによる名前解決が行なわれておらず、注意が必要である。大なり小なり記号(<>)内の数字は、NetBIOS名がワークグループ名、ワークステーション名、メッセンジャーサービスで利用するユーザ名、マスタブラウザ、ドメインマスタブラウザ、ドメインコントローラ等を示すものである。ここでは基本的に
<00>をマシンやワークグループを識別する名前として、<20>をマシンがサーバであることを識別するものとして用いる。完全なリストに付いては、 http://support.microsoft.com/support/kb/articles/q163/4/09.aspを参照のこと。
ypmatchnamehostsを実行のこと。これが失敗する場合は、NISが動作していない。 ypwhichコマンドを実行してNISサーバ名を捜し出し、マシンにアクセスできるかどうかをpingで確認すること。NIS+を実行している場合は、
nismatchnamehostsコマンドを実行する。これに失敗する場合は、NIS(monyo 訳注: NIS+の誤りか)が動作していない。 niswhichコマンドを実行して(monyo 訳注: niswhich というコマンドは存在しない。これは筆者のNIS+に対する理解不足による誤記と思われる)NISサーバ名を捜し出し、マシンにアクセスできるかどうかをpingで確認すること。クライアントの /etc/hosts ファイル(
C:\WINDOWS\HOSTS)を調査する。各行には、IPアドレスと1つ以上の名前が記述されているはずである。プライマリネームが先頭であり、それ以外はオプションのエイリアス名である。以下に例を示す:127.0.0.1 localhost 192.168.236.1 dns.svc.example.com 192.168.236.10 client.example.com client 192.168.236.11 backup.example.com loghost 192.168.236.86 server.example.com server 192.168.236.254 router.svc.example.com
UNIXの場合、
localhostは常に127.0.0.1でなければならないが、PC上ではホスト名に対するエイリアスの場合もあるかも知れない。クライアント上では、#XXXという識別子が行の最後にないことを確認すること。これはLAN Manager/NetBIOSの識別子であり、 LMHOSTSファイル(C:\WINDOWS\LMHOSTS)でのみ奇術可能である。このファイルは、LAN Manager (NetBIOS)名のローカルマシン上での解決方法である。これは /etc/hostsファイルと非常に類似した形式であるが、長い形式のドメイン名(例えば
server.example.com)をサポートしておらず、名前に引続き#XXXという識別子を記述することが可能になっている。通常このファイルは lmhosts.sam (サンプルの意) という名前でC:\WINDOWSにあるが、C:\WINDOWS\LMHOSTSに名前を変更するまで有効にならない。9.2.8.3 長い名前と短い名前
長い形式のホスト名だと動作するが、短い形式では動作しない場合(例えば
client.example.comは動作するが、clientは動作しない場合)、以下を確認すること:
これは、通常短い名前を検索する際に用いるデフォルトドメインが定義されていないことを意味する。Sambaサーバ上の /etc/resolv.confに
default行(monyo 訳注: domain の誤りだと考えられる)があり、自分のドメインになっているか、search行があり、1つ以上のドメイン名が記載されていることを確認する。短い名前を利用可能にするためにはいずれかが必要である。どちらになっているかは、ベンダーやDNSリゾルバのバージョンによる。 resolv.confにdomainyour domainを追加し、ネットワークやDNSの管理者にファイルをどのように記述すれば良いかを確認すること。ブロードキャストやWINSは長い名前をサポートしていないため、この問題は発生しない。
ypmatchhostnamehostsコマンドを実行すること。もしこれがうまく行かないようであれば、テーブルには短い名前が入っていない。ネットワーク管理者に申告してみよう。短い名前が入っていないか、そういうポリシーになっているかのどちらかであろう。サイトによっては(曖昧な)短い名前を利用していない。
nismatchhostnamehosts(monyo 訳注: nismatchというコマンド自体はあるが、文法は異なっている)を実行して、失敗した場合は前述したNISと同様に対処する。短い名前が /etc/hosts中にない場合は、エイリアスとして追加することを検討する。可能であれば、短い名前をプライマリ名(行の最初の名前)にすることは避けるべきである。システムに問題がなければエイリアスとして記述すること。
LAN Managerは長い名前をサポートしないため、この問題は発生しない。
一方、短い名前だと動作するが、長い名前では動作しない場合は、以下を確認すること:
これは奇妙である。ネットワークやDNSの管理者に確認してもらおう。恐らくDNSの設定のミスである。
これは考えられることである。ブロードキャストやWINSは長い形式の名前を利用しないが、DNSが利用されている可能性がある。MicrosoftはDNSで名前解決が行なわれることがあると記述している。ただし、<00>のような形式での名前解決は行なわれない。
ypmatchコマンドで短い形式の名前を検索できるが、長い形式はできないときは、長い形式の名前をエイリアス等で追加してもらうようにする。NISと同様であるが、名前の検索に
nismatchコマンドをypmatchコマンドの代わりに用いる点だけが異なる(monyo 訳注: 実際は前述したように違いはこれだけではない)。長い形式の名前を最低でもエイリアスで、できればプライマリ名として追加する。実用上はDNSの導入も検討すること。
これは考えられることである。LAN Managerは長い形式の名前を利用しない。DNSや hostsの利用を検討すること。
9.2.8.4 異常な遅延
結果が返却されるまでに非常に長時間かかる場合は以下を確認する:
nslookup コマンドを使って応答が遅いマシン(クライアントかサーバ)上で幾つかの名前を確認してみる。 nslookup コマンドでも遅い場合は、DNSに問題がある。クライアント上での動作がより遅い場合、Ethernetカードにプロトコルをバインドしすぎている可能性がある。非常に遅いことで有名なNetBEUIを削除し、不要であれば、Novel(monyo 訳注: IPX/SPXのことを指していると考えられる)も削除する。多数のプロトコルがあると特に問題が発生しやすいWindows 95において、これは重要である。
nmblookupを用いてクライアントをテストする。これが高速に実行される場合は、前述した複数プロトコルの問題が発生していると思われる。
ypmatchコマンドを実行してみる。これが遅い場合は、ネットワーク管理者に問題を報告しよう。
nismatchコマンドを同様に実行する。hosts ファイルは適切な大きさであれば、常に高速である。恐らくDNSの項で述べたプロトコルの問題が発生しているのであろう。
名前解決の問題は発生しない。 LMHOSTSファイルは hostsファイルと同様に高速である。
9.2.8.5 localhost問題
localhostが127.0.0.1でない場合は、以下を確認する:
9.2.9 ネットワークアドレスのトラブルシューティング
IPアドレスのルーティングやIPアドレスの設定ミスによる問題もありがちである。このセクションでは、アドレスがどうなっているかを確認する方法について説明する。
9.2.9.1 ネットマスク
ネットマスクはどの範囲のアドレスが直接到達でき(すならちローカルネットワーク上にあり)、どのアドレスがルータ経由でのパケットのフォワードが必要であるかを設定するものである。ネットマスクが不正だと、マシンには以下のどちらかの誤動作が発生する。一つはローカルアドレス向けのパケットをルータ経由でルーティングしようとしてしまうことで、これは時間の無駄であり、そこそこの速さで動作するかも知れないが、遅くなるかも知れず、全く通信できないかも知れない。二つめはリモートマシン向けのパケットをルータに送信せず、リモートマシンに対するパケットの転送ができなくなってしまうことである。
ネットマスクはIPアドレスのような数字で表され、1になっているビットがネットワーク部を表し、0がホスト部を表す。ネットマスクは、文字通りTCP/IPの内部的な実装でアドレスの一部をマスクするのに用いられる。マスクが255.255.0.0の場合、最初の2バイトがネットワーク部であり、後の2バイトがホスト部になる。一般的なのは255.255.255.0であり、これは先頭から3バイトがネットワーク部であり、最後の1バイトがホスト部になる。
例えば、自分のIPアドレスが192.168.0.10であり、SambaサーバのIPアドレスが192.168.236.86だとしよう。ネットマスクが255.255.255.0の場合、アドレスのネットワーク部は先頭から3バイトになり、ホスト部は最後のバイトになる。そのため、両者のネットワーク部は異なっており、マシンは異なったネットワークに属していることになる:
ネットワーク部
ホスト部
192 168 000
10
192 168 235
86
ネットマスクが255.255.0.0の場合は、ネットワーク部は先頭から2バイトになる。この場合はネットワーク部は同一であり、2台のマシンは同じネットワークにいることになる:
ネットワーク部
ホスト部
192 168
000 10
192 168
236 86
もちろん、自分のマシンのネットマスクがネットワーク管理者が指定したものと異なっていれば、ネットマスクが不正であることになる。
9.2.9.2 ブロードキャストアドレス
ブロードキャストのアドレスは通常のアドレスであるが、ホスト部のビットが全て1になっている。これは"ネットワーク上の全てのホスト"を意味する。このアドレスは自分のアドレスとネットマスクから簡単に算出することができる。自分のアドレスに対して、ネットマスクで0になっている部分(ホスト部)のビットを全て1にしてみればよい。以下の表にこれを図示する:
ネットワーク部
ホスト部
IPアドレス
192 168 236
86
ネットマスク
255 255 255
000
ブロードキャスト
192 168 236
255
この例では、192.168.236ネットワークのブロードキャストアドレスは、192.168.236.255になる。また"universal"ブロードキャストアドレスとして、255.255.255.255というアドレスも古くから存在する。ルータではこのアドレスのルーティングは禁止されているが、ローカルネットワーク上にあるほとんどのマシンは、このアドレスに対するブロードキャストに応答する。
9.2.9.3 ネットワークアドレスの範囲
幾つかのアドレスの範囲はテスト用や内部ネットワーク用として予約されている。本書でもこの範囲のアドレスを利用している。IPアドレスを持っていないのであれば、以下のうちどれかを利用するとよいだろう。これには1つのclass Aネットワーク、10.*.*.*と254のclass Cネットワーク、192.168.1.* から192.168.254.*がある(monyo 訳注: 実際には上記以外に172.16.*.*から172.31.*.*のclass Bアドレスも自由に使えるアドレスとして定義されている)。本書では後者の範囲から192.168.236.*というアドレスを利用している。 example.comというドメイン名も、内部ネットワークや、書籍等での説明の例に用いるために、予約されているものである。
実際にインターネットに接続する際には、通常接続回線を提供する会社経由で、ネットワークアドレスとドメイン名を取得する必要がある。
9.2.9.4 ネットワークアドレスを確認する
IPアドレスをメモしていないのであれば、UNIXでは ifconfigコマンド(UNIXの種別によって必要なオプションに付いて、マニュアルページを参照すること。Sunの場合は
ifconfig-aになる)、Windows 95やNTではIPCONFIG コマンド(monyo訳注: Windows 95にIPCONFIGコマンドは存在しない。代わりにWINIPCFGコマンドを用いる)を用いることで表示させることができる。以下のような出力が行なわれるはずである:server% ifconfig -a le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING > inet 192.168.236.11 netmask ffffff00 broadcast 192.168.236.255 lo0: flags=49<<>UP,LOOPBACK,RUNNING<>> inet 127.0.0.1 netmask ff000000インタフェースの一つはループバック(上記の例では
lo0)であり、もう一つが通常のIPインタフェースになる。フラグの値は、このインタフェースが有効であり、Ethernetインタフェースがブロードキャストをサポートしていることを示している(PPPインタフェースではブロードキャストはサポートされない)。IPアドレスの情報は /etc/hostsファイル、Windowの HOSTS ファイルや LMHOSTSファイル、NIS、NIS+、DNSで確認することもできる。9.2.10 NetBIOS名のトラブルシューティング
歴史的な理由で、SMBプロトコルはLAN Managerネームシステムとも呼ばれるNetBIOSネームシステムに依存している。これは各マシンが20文字(monyo 訳注: 15文字の筈)の名前を持ち、相手を知るのにはLAN上にブロードキャストを行なうという簡単なシステムであった。TCP/IPの場合、DNSやWINSや /etc/hostsファイルに格納された client.example.comのような名前が用いられる。
通常 server.example.comのようなDNS名のマッピングは、単純に serverを大文字に変換したものをNetBIOS名として用いることで行なわれる。しかしこれが常に正しく動作するとは限らない。特に21文字(monyo 訳注: 16文字)以上の名前のマシンが存在するときが該当する。また誰もが同じNetBIOS名とDNS名を用いるとも限らない。例えば vm1.corp.comが corpvm1という名前になっていることも珍しくない。
NetBIOS名とDNS名が異なっているマシンは、トラブルシューティングの時の混乱の元となるので、可能な限り避けることを推奨する。NetBIOS名は smbclient コマンドを利用することで見付けることができる:
smbclientを用いてSambaサーバ上の共有を一覧するには、
-L(共有一覧)オプションにサーバの短い名前を引数にとって実行する。なお短い名前とはNetBIOS名のことである。もし"Get_Hostbyname: Unknown host name,"と出力された場合は、恐らく名前解決に不整合が発生している。 smb.confファイルを確認して、NetBIOS名が明示的に設定されているかどうかを確認すること。
更に、
-Iオプションで(smbclient-Lserver-I192.168.236.86のようにして)SambaサーバのIPアドレスを指定して実行する。これは名前解決機構を無視して、パケットが指定したIPアドレスに行くように強制する。これで動作するのであれば、名前解決に不整合がある。Try with
-Iオプションを用いて(smbclient-Lserver-Iserver.example.comのようにして)サーバのFQDN名を指定して実行する。このテストでは、Sambaサーバが利用可能な名前解決機構(DNSなど)を用いてDNS名を解決する。これが失敗する場合、名前解決サービスに問題がある。NetBIOS名のトラブシューティングが終ったら、 Section 9.2.8を再度参照すること。
-n(NetBIOS名) オプションを用いて(smbclient-nserver-Lserver-12のようにして)期待している名前を指定するが、-IオプションでのIPアドレスの指定は行なわずに実行する。これが動作すれば、-nオプションで指定した名前は、サーバの実際のNetBIOS名であるといえる。"Get-Hostbyname: Unknown host MARY,"のような返答が行なわれた場合は、正しいサーバの名前ではない。全く動作しないのであれば、ユーザ名やワークグループ名の不整合により問題が発生していないかどうかを確認するため、
-Uusernameや-Wworkgroupで、ユーザ名やワークグループ名を大文字で指定してテストを再度行なってみる。それでも動作しない場合は、明らかに名前解決に問題がある。 Section 9.2.8にある名前解決サービスのトラブルシューティングを行なってから、NetBIOS名前解決サービスのトラブルシューティングに戻ること。
 |
 |
 |
| 9.1 道具袋 |
 | 9.3 更なる情報源 |
© 1999, O'Reilly & Associates, Inc.
