この章には、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 -vChain 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 anywhere1399K 1380M ACCEPT all -- eth1 any anywhere anywhere \ state RELATED,ESTABLISHEDChain 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 warningChain OUTPUT (policy ACCEPT 2875K packets, 1508M bytes) pkts bytes target prot opt in out source destinationChain 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”に設定するようにする。