この章には、Sambaサーバの検証が行えるテストの一覧が含まれている。また、それらの手順の どこかで失敗した問題を起こす可能性の高いものが何かと言うことについても説明している。 もしも、すべてのテストをパスしたら、おそらく正しく動いているだろう。
すべてのテストを示された順で行うべきである。後のテストが、前のテストで確認された 機能のみを使うように、テストを注意深く選ぶようにしてある。しかし、最初のエラーで 止まってはならない:テストの継続が、問題の解決を手助けするという事例があったからで ある。
もしも、“It does not work,”というタイトルでメールをSambaメーリングリストの どこかに送り、このテスト手順に従わないならば、メールが無視されても驚いてはいけない。
すべてのテストにおいて、SambaサーバはBIGSERVERで、PCクライアントがACLIENTで、両者とも TESTGROUPというワークグループに属していることを仮定する。
手続きは、他のクライアントのタイプと同様である。
smb.conf中の有効な共有名も分かっているものとする。ここでの例における共有の名前は
tmpである。これは、次の例
で示される行を追加することで、このようなtmp共有を追加できる。
これらのテストはバージョン3.0.0以降のSambaシステムを仮定する。以前のバージョンでは いくつかのコマンドは存在しない。
受け取ったエラーメッセージに注意をはらってほしい。もしもエラーメッセージが、使用している
サーバが調子が悪いという事を報告しているのであれば、まず初めに使用しているIPを名前解決
する方式が正しく設定されているかどうかをチェックすべきである。実際に存在している
ネームサーバを、/etc/resolv.confが正しく指し示しているようにする
こと。
また、もしも、名前解決用のDNSサーバアクセスが出来ないならば、smb.confに
dns proxy = noが設定されているかをチェックする。
これをチェックする最も良い方法は、testparm smb.confである。
別のターミナルコンソール(X中で複数のターミナルを使うには、ctrl-alt-F1からF6を使用)で、
tail -F log_file_nameを使うことで、テストの間ログファイルをモニタする
のは便利である。適切なログファイルは(既定値によるインストールでは)、
/usr/local/samba/varにある。また、マシンからの接続ログは、ここか、
/var/log/sambaか、あるいは
smb.confファイル中でロギングを指定した場合には、それに依存する場所にある。
もしも、それらのテスト中にsmb.confファイルを変更したならば、smbdとnmbdの再起動を
忘れないこと。
Procedure 38.1. 使用しているSambaサーバの診断
smb.confファイルを格納しているディレクトリ中で、testparm smb.confを
実行する。もしも何らかのエラーが発生した場合、そのsmb.confの設定には間違いがある。
PCからping BIGSERVERコマンドを動かし、UNIXマシンから
ping ACLIENTを動かす。正常な応答がない場合、TCP/IP層の設定が
うまくいっていない。
PC上でpingを動かす場合には、“DOS プロンプト”を起動する必要がある。
もしも、“host not found”か同様なメッセージが
表示されたならば、DNSソフトウェアか/etc/hostsファイルが正しく
設定されていない。もしもDNSを使っている場合、/etc/resolv.confに、
正しい、最新のエントリがあるかどうかをチェックする。DNSエントリなしにSambaをサーバと
クライアントとして動作させることは可能であるが、この後のテストでは、正しいエントリが
あると仮定している。
pingが失敗するかもしれない他の理由としては、使用しているホスト上でファイアウォール
ソフトウェアが動作している場合である。ワークステーションからの問い合わせに対して
ルールをゆるめる必要がありえ、それはおそらく、他のサブネットからのアクセスを許可する
ことであろう(Linux上では、これは、ipchainsか
iptablesという、適切なファイアウォール管理コマンドによって行える)。
最新のUNIXディストリビューションでは、既定値でipchains/iptablesをインストールしている。 これは、しばしばよく見落とされる問題である。
もしも、テスト中にシステム中どのようなファイアウォールルールが存在しているかを調べたい
場合、単純にiptables -L -vか、あるいは
ipchainsベースのファイアウォールを使っている場合には、
ipchains -L -vを入力する。
以下は、Sambaが有効になっていない外部向けのイーサネットインタフェース(eth1)とSambaが 有効になっている内部向けの(プライベートネットワーク)インタフェース(eth0)を持つ、 システムからの結果例である。
frodo:~ # iptables -L -v
Chain INPUT (policy DROP 98496 packets, 12M bytes)
pkts bytes target prot opt in out source destination
187K 109M ACCEPT all -- lo any anywhere anywhere
892K 125M ACCEPT all -- eth0 any anywhere anywhere
1399K 1380M ACCEPT all -- eth1 any anywhere anywhere \
state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
978K 1177M ACCEPT all -- eth1 eth0 anywhere anywhere \
state RELATED,ESTABLISHED
658K 40M ACCEPT all -- eth0 eth1 anywhere anywhere
0 0 LOG all -- any any anywhere anywhere \
LOG level warning
Chain OUTPUT (policy ACCEPT 2875K packets, 1508M bytes)
pkts bytes target prot opt in out source destination
Chain reject_func (0 references)
pkts bytes target prot opt in out source destination
UNIXマシン上でsmbclient -L BIGSERVERを動かす。
これで有効な共有の一覧が得られる。
もしも“bad password”という文字列があるエラーメッセージが表示されたら、
不正なhosts allow、hosts denyか
valid users行がsmb.confにあるか、ゲストアカウントが無効に
なっている。testparmでゲストアカウントが何かを調べ、一時的に
hosts allow, hosts deny,
valid users, かinvalid users行を
削除してみる。
もしも、connection refusedというメッセージが帰ってきたら、
smbdサーバが動いていないかもしれない。もしも
inetd.conf経由で動作するようにしていたら、おそらくこのファイルの
編集が間違っている。もしもdaemonとして動作するようにしていたら、動作しているかを調べ、
netstat -aを使ってnetbios-ssnポートがLISTEN中かを確認する。
ある種のUNIX/Linuxシステムでは、inetdの代わりに
xinetdを使っている。ネットワークスーパーデーモンの、
特定のシステム実装についての、制御ファイルの位置の説明文書を調べること。
もしも、session request failedというメッセージが表示されたならば、
サーバは接続を拒否している。もしも“Your server software is being unfriendly”
というメッセージが表示されたならば、それはおそらくsmbdに対するコマンドラインオプションを
間違えているか、smbdの初期起動時に同様の致命的な問題がある。testparmで設定ファイル
(smb.conf)の文法と、ログとロックファイルを保持する種々のディレクトリもチェックする。
セッション要求を拒否するか、断るかもしれない数多くの理由がある。それらは、
次の例で示されているsmb.confファイルのエントリ
によって発生する。
特定のサブネットからのみ接続を受け付ける設定例では、 ループバックアダプタアドレス 127.0.0.1へ自動的に変換される任意のセッション要求は 許可されない。この問題を解決するためには、以下の例で 示されているような行に変更する。
他の、よくある2つのエラーの例は、Samba(すでにinetd経由で
smbdが動いている)か、DECのPathworksのような、ポート139上で
何かがすでに動いているものである。デーモンでsmbdを動かす前に
inetd.confファイルをチェックすること。そうすれば
多くのトラブルを防げる!
さらに、このテストが失敗する、他のあり得そうな例としては、サブネットマスクか
ブロードキャストアドレスの設定が不正な場合である。ネットワークインタフェースの
IPアドレス、ブロードキャスト、サブネットマスクが正しいかと、それらが
log.nmbdファイル中に正しくSambaが記録しているかを確認すること。
nmblookup -B BIGSERVER __SAMBA__コマンドを動かす。
使用しているSambaサーバのIPアドレスが表示されるはずである。
そうでない場合、nmbdが駄々しくインストールされていない。inetd.conf
経由で動かしている場合はそこを、あるいはデーモンが動いていてUDPポート137をリッスン
しているかどうかをチェックする。
ある1つのよくある問題は、多くのinetdの実装が、コマンドライン上に多数のパラメータを使えない というものである。もしもこの場合、正しいパラメータを含む1行のみのスクリプトを作成し、 それをinetdから起動する。
nmblookup -B ACLIENT `*'を起動する。
PCのIPアドレスが表示されるはずである。もしもそうでなければ、PC上のクライアント ソフトウェアの設定が間違っているか、開始していないか、PCの名前が間違っているか である。
もしもACLIENTがDNS経由で名前解決できない場合、上記のテストで、クライアントのIP アドレスを使用してみる。
nmblookup -d 2 `*'コマンドを動かす。
この時点では前述のテストと同じ事を試みるが、既定値のブロードキャストアドレスに、
ブロードキャスト経由で行う。それをリッスンしているSambaは短時間にすべての応答を
受け取れないかもしれないが、ネットワーク上にある、たくさんのNetBIOS/TCP/IPホストが、
これに応答する。いくつかのホストからの、
got a positive name query responseメッセージを受け取るはずである。
もしも、上記のテストのような結果が得られないのであれば、nmblookupが、その自動
メカニズムによる、使用しているブロードキャストアドレスを正しく入手できていない。
この場合、使用するIPアドレス、ブロードキャストとサブネットマスクを、
smb.conf中のinterfacesオプションに、手動で設定する
ことをやってみるべきである。
もしも、使用しているPCとサーバが同じサブネットにない場合、そのPCのサブネットの
ブロードキャストアドレスを指定する-Bオプションを使う必要がある。
このテストは、サブネットマスクとブロードキャストアドレスが間違っている場合、おそらく 失敗する(3つ前の注意(Note)を参照)。
smbclient //BIGSERVER/TMPコマンドを動かす。パスワード要求が来る
はずである。UNIXマシンにログインするアカウントのパスワードを入力する。もしも他の
アカウントで、テストを行いたいならば、コマンドラインの最後の所に、
-U accountnameオプションを追加する。 たとえば、
smbclient //bigserver/tmp -Ujohndoeである。
以下のように、ユーザ名に引き続いてパスワードを指定することも出来る:
smbclient //bigserver/tmp -Ujohndoe%secret.
パスワードを入力すると、smb>プロンプトが出るはずである。もしも
そうでなければ、エラーメッセージが表示される。もしもそれが
“invalid network name”であれば、サービス
tmpがsmb.conf中で正しく設定されていない。
“bad password”という表示がされたならば、 あり得そうな原因は以下の通り:
shadowパスワード(かその他のパスワードシステム)を使っているが、smbd中で それをサポートするようにコンパイルされていない。
使用しているvalid usersの設定が間違っている。
大文字小文字を混ぜたパスワードを使っているが、十分に大きなレベルを password levelオプションで有効にしていない。
smb.conf中のpath行が間違っている。testparmで
検査すること。
パスワード暗号化を有効にしているが、SambaユーザにUNIXユーザをマップしていない。
smbpasswd -a usernameを実行する。
接続後、コマンドdir, get,put
などが使えるようになっているはずである。どう入力するかを調べるために、
help commandを入力する。dirコマンドを入力した
時に、空きディスクスペースが正しいかを、特にチェックすべきである。
PC上で、net view \\BIGSERVERコマンドを入力する。これは、DOSウィンドウ
内で入力する必要がある。サーバ上で有効な共有一覧が表示されるべきである。
network name not foundか似たようなエラーが表示された場合、NetBIOS
名前解決が動作していない。これは通常nmbdの問題である。これを解決
するために、以下のどれかを行う(どれか1つを選ぶのみでよい):
nmbdのインストールを修正する。
PC上のTCP/IP設定中にある「詳細設定」においてwinsタブ中に
BIGSERVERのIPアドレスを追加する。
TCP/IP設定中にある「詳細設定」においてDNS経由での名前解決を有効にする。
PC上のlmhostsファイルにBIGSERVERを追加する。
もしも、“invalid network name”か
“bad password error,”というメッセージが表示された
ならば、smbclient -Lテストでのと同じ修正を行う。特に、
hosts allow行(マニュアルページを参照)が正しいかを確認すること。
また、ワークステーションがSambaサーバに接続を要求するとき、Windowsマシンにログオンしている 名前を使うという事実を見落とさないこと。Sambaサーバ上で存在しているアカウントと正確に 同じ名前とパスワードにする必要がある。
もしも“specified computer is not receiving requests”
か、同等のエラーが表示されたならば、おそらくTCP経由でホストに接続できないことを
意味する。TCPラッパーがホスト上で動いているかを調べ、そうであれば、クライアント
(かサブネット等)のエントリをhosts.allowに追加する。
net use x: \\BIGSERVER\TMPを実行する。パスワード要求が来るはずである。
次に、command completed successfullyメッセージが表示
されるはずである。そうでない場合、PC上のソフトウェアが正しくインストールされていないか、
smb.confが間違っている。smb.conf中のhosts allowと他の
設定行が正しいかを確認する。
サーバが、どのユーザ名で接続するかを見いだせないという事もあり得る。この問題かどうかを
見るためには、smb.conf中の[tmp]セクションに
user = username行を追加する。ここで、
usernameは、入力するパスワードに対応するものである。
もしもこれで修正されるならば、ユーザ名マッピングオプションが必要となるかもしれない。
クライアントが暗号化パスワードのみを送り、smb.conf中で
encrypt passwords = noが設定されているという
場合もあるかもしれない。これを修正するためには、設定を`yes'に変更する。
ワークグループの名前がtestgroupである、SambaサーバとWindows PCが
属している所でnmblookup -M を
実行する。そのワークグループにおけるマスタブラウザのIPアドレスが表示されるはずである。
testgroup
そうでない場合、選択プロセスが失敗している。ただ単に遅れているのかもしれないので
しばらく待ち、再度試してみる。それでも失敗した場合、smb.conf中にある
ブラウジングオプションを調べてみる。起動時に選択(election)が行われるように、
preferred master = yesを書いておくこと。
ファイルマネージャから、サーバをブラウジングしてみる。ローカルワークグループ
(かsmb.conf中で指定したもの)のブラウズリスト中にSambaサーバが現れるはずである。
サーバの名前をダブルクリックし、共有の一覧が得られるべきである。もしも、
“invalid password”というエラーが表示されたならば、おそらくWindows NTが
動作していて、それがユーザレベルのセキュリティモードで動作していて暗号化パスワードを
扱えない状態になっていてサーバのブラウジングを拒否している。この場合、
security = serverと
password server = Windows_NT_Machineのどちらかを
smb.confファイル中に設定するか、encrypt passwordsを
“yes”に設定するようにする。