9. Samba のトラブルシューティング

Contents:
道具袋
 Fault Tree
外部のリソース

Samba は非常に堅牢である。一度自分が意図するように設定を行なってしまえば、恐らくSambaが常時稼働していることすら忘れてしまうことだろう。トラブルが発生するのは、通常インストール中か、サーバに何か新しい機能を追加しようとしたときであろう。好運なことに、これらのトラブルを診断する際には、様々なリソースを用いることが可能である。遭遇するかも知れない問題の各々に対して詳細な対応策を記述することは出来ないが、この章の記述を参考にすれば、問題を解決するに際して手がかりを得られる筈である。

章の最初のセクションでは、Samba のトラブルシューティングを行なう際に利用できるツールを集めて紹介する。次のセクションではどのようにしてトラブルシューティングを行なうかの詳細を記述し、最後のセクションでは、特に手におえない問題を解析する際に必要となるかも知れない外部のリソースを紹介する。

9.1 道具袋

時として UNIX は厄介なアプリケーションやツールを生み出して来た。トラブルシューティングを行なうためのツールも存在し、もちろん、その目標を達成する方法は、一つではない。Samba に関係するトラブルを解決しようとする時には、まず以下をチェックすることからはじめるのがよいであろう:

Samba のログ
Fault tree
UNIX ユーティリティ
Samba のテストユーティリティ
ドキュメントとFAQ
Searchable archives
Samba のニューズグループ

これらについては、以下のセクションで一つずつ解説していこう。

9.1.1 Samba のログ

最初にやるべきことは、ログファイルをチェックすることである。Samba のログファイルは Samba の管理者が向き合わなければならない問題のほとんどすべての診断に役立つ。Samba は非常に柔軟なロギングを行なうことができ、自分の好みに応じてサーバのログの量を設定できる。変数置換により、ログをマシン毎、共有毎、それらの組み合わせ毎に出力することも出来る。

デフォルトでログファイルは samba_directory /var/smbd.log と samba_directory /var/nmbd.log に置かれる。ここで samba_directory はSamba がインストールされた場所(通常 /usr/local/samba)を示す。Chapter 4, ディスク共有で述べたように、この場所と名前は log file 設定オプションを smb.conf に記述することで変更できる。このオプションは、Chapter 2, Installing Samba on a Unix Systemで説明した変数置換のすべてを用いることが出来るため、以下のように smb.confの[global] セクションに記述することで、クライアントからの接続毎にログを分離することも簡単にできる:

log file = %m.log

なお、コマンドラインで-l フラグを用いることで、ログディレクトリを指定することもできる。以下に一例を示す:

smbd -l /usr/local/var/samba

もう一つ便利な方法として、各サービス(共有)毎にログを取得するようにする方法を紹介しよう。これは特に特定の共有でトラブルが発生していると推測される際に便利である。設定ファイルの[global]セクションに %S 変数を用いて以下のように設定する:

log file = %S.log

9.1.1.1 ログのレベル

Sambaが出力するログのレベルは smb.conf ファイル中でグローバルな log level か debug level オプションを用いることで設定できる。なおこの両者は同一のオプションである。ログのレベルは0(ログを行なわない)からはじまる整数値であり、log level = 3にすることで、大量のログが出力される。Windowsクライアントを使ってSambaサーバ上のディレクトリを一覧した場合を例にとって説明しよう。小量のログを出力する際には log level = 1を用いることで、Sambaは概要情報だけを出力する。この場合だと接続したという情報のみになる:

05/25/98 22:02:11 server (192.168.236.86) connect to service public as user pcguest (uid=503,gid=100) (pid 3377)

デバッグレベルを上昇させると、より詳細な情報が出力される。通常レベル3より大きいレベルが必要となることはない。ほとんどのSamba管理者にとって、レベル3より大きいレベルは不要である。レベル3以上は開発者が利用する為のもので、大量の暗号のような情報を出力する。

以下の出力例は、前述した操作をレベル2および3にして行なった際のものである。SMB接続の込み入ったところを理解していなくても気にすることはない。目的は単純にロギングレベルを変更することでどのような情報が出力されるかを示すことにある:

 /* Level 2 */
Got SIGHUP
Processing section "[homes]"
Processing section "[public]"
Processing section "[temp]"
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC/


/* Level 3 */
05/25/98 22:15:09 Transaction 63 of length 67
switch message SMBtconX (pid 3377)
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
ACCEPTED: guest account and guest ok
found free connection number 105
Connect path is /tmp
chdir to /tmp
chdir to /
05/25/98 22:15:09 server (192.168.236.86) connect to service IPC$ as user pcguest (uid=503,gid=100) (pid 3377)
05/25/98 22:15:09 tconX service=ipc$ user=pcguest cnum=105
05/25/98 22:15:09 Transaction 64 of length 99
switch message SMBtrans (pid 3377)
chdir to /tmp
trans <\PIPE\LANMAN> data=0 params=19 setup=0
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
Doing RNetShareEnum
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
05/25/98 22:15:11 Transaction 65 of length 99
switch message SMBtrans (pid 3377)
chdir to /
chdir to /tmp
trans <\PIPE\LANMAN> data=0 params=19 setup=0
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
Doing RNetShareEnum
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
05/25/98 22:15:11 Transaction 66 of length 95
switch message SMBtrans2 (pid 3377)
chdir to /
chdir to /pcdisk/public
call_trans2findfirst: dirtype = 0, maxentries = 6, close_after_first=0, close_if_end = 0 requires_resume_key = 0 level = 260, max_data_bytes = 2432
unix_clean_name [./DESKTOP.INI]
unix_clean_name [desktop.ini]
unix_clean_name [./]
creating new dirptr 1 for path ./, expect_close = 1
05/25/98 22:15:11 Transaction 67 of length 53
switch message SMBgetatr (pid 3377)
chdir to /

[...]

最初のパケットに続くパケットの分については、多くのページを必要とするため省略した。なお3を越えるログレベルはSambaの内部的な処理に関するうんざりとする程詳細なログでディスクをメガバイト単位であっという間に消費してしまうので気を付けること。ログレベル3はサーバがどのように動いているかをきちんと追跡する際に非常に有用であり、ほとんどの場合ログファイルを一読することで、どこでエラーが発生しているかが明確になる。

警告: 高いlog level (3 より大きい) は非常 Samba サーバの動作を遅くする。ログメッセージが生成される度にディスクへの書き込みが発生し(従って処理が遅延する)、ログレベル2以上では大量のデータが生成されることを忘れないこと。ことに注意すること。基本的にログレベルを3にするのは、Sambaサーバの問題解析を行なう際だけにすべきである。

9.1.1.2 ログの有効化、無効化

ロギングを開始したり停止したりするには、 smb.confの[global]セクションに適切なレベルを設定してから、Samba を再起動するか、現在のデーモンに設定ファイルを再読み込みさせる必要がある。 smbd のプロセスに SIGUSR1 シグナルを送信することで実行中にログレベルを1ずつ増加させたり、SIGUSR2 シグナルを送信することで1ずつ低下させることも可能である:

# ロギングレベルを1つ増加させる
kill -SIGUSR1 1234

# ロギングレベルを1つ低下させる
kill -SIGUSR2 1234

9.1.1.3 クライアントマシン、ユーザ毎のロギング

他のユーザに迷惑をかけずに問題解決を行なうのに有用な方法として、 smb.confファイルの[global] セクションにマシン毎に異なったログレベルを設定するという方法がある。前述した方式を使ってこれを実現することができる:

[global]
	log level = 0
	log file = /usr/local/samba/lib/log.%m
	include = /usr/local/samba/lib/smb.conf.%m

これらのオプションによりSambaは接続してきたクライアント毎に個別のログファイルと設定を利用するようになる。行なわないといけないことは、特定のクライアントマシン用にlog level = 3のエントリを記述した smb.confファイルを作成し(その他のマシンはデフォルトのログレベルである0に設定される)、問題を解析するためにログファイルを活用することができる。

同様に、特定のユーザだけに問題が発生しており、どのマシンからでも発生するという場合、以下のようなエントリを smb.confファイルに追加することで、特定のユーザに対するログを分離することができる:

[global]
	log level = 0
	log file = /usr/local/samba/lib/log.%u
	include = /usr/local/samba/lib/smb.conf.%u

上記の設定を行なった上でlog level = 3の設定オプションを含む各ユーザ毎の smb.confファイル(例えば /usr/local/samba/lib/smb.conf.tim)を作成することで、特定のユーザについてのみ詳細なログを取得することが可能になる。

9.1.2 Samba のテストユーティリティ

Samba の主要な機能について検証する厳密なテストについては、、Samba の配布パッケージの /docs/textdocs ディレクトリ以下に存在する、 DIAGNOSIS.TXTをはじめとする多数のファイルに記述がある。本章の fault tree ではSamba チームが推奨する基本的なテストのより詳細なものが記載されているが、その範囲は DIAGNOSIS.TXT と同様、インストールと設定変更の診断のみである。 /docs ディレクトリにあるその他のファイルには特定の問題(例えばWindows NT クライアントに関するもの)や、本書に含まれていない事項に付いてどのようにトラブルシューティングを行なうかに関する情報が含まれている。fault tree だけでは不十分だという場合は、 DIAGNOSIS.TXT 等を覗いてみるとよいであろう。

9.1.3 UNIX ユーティリティ

サーバ内部で何が起こっているかを知るためには、時としてSamba スイート外のツールを利用してみるのもよいだろう。UNIX は常に「何でもあり」のOSである。 trace と tcpdump という診断ツールが、Samba に関するトラブルのデバッグに関して、ある部分では助けになる。

9.1.3.1 traceの利用

trace コマンドは利用しているOSによって、幾つかの異なった名称になっている。Linux においては strace であり、Solaris では truss、 SGI では padc と parである。これらは基本的に同じ機能を持っており、発行されたOS の各システムコールを表示する。これにより、Samba サーバのようなプログラムの実行を追跡することが可能であり、かなりの場合に問題を引き起こしている呼び出しを特定することが可能である。

trace が発見できる問題の一つとして、不正なバージョンの動的リンクライブラリの呼び出しが挙げられる。これはSambaのバイナリをダウンロードして利用した場合に発生する。通常、プログラムが終了する直前の traceの終り近くに、問題の呼出しを見付けることができる。

以下に Linux におけるstrace の出力の例を示す。これは Samba サーバ上であるディレクトリをオープンしようとした際に作成された巨大なトレースファイルの一部分である。各行はシステムコールの名称とその引数及び戻り値を示す。エラーが発生すると、エラー値(ENOENTなど)とその説明も表示される。利用しているOS中の適切なtraceのマニュアルページを参照することで、引数や発生しうるエラーを見付けられる。

chdir("/pcdisk/public")                 = 0
stat("mini/desktop.ini", 0xbffff7ec)    = -1 ENOENT (No such file or directory)
stat("mini", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
stat("mini/desktop.ini", 0xbffff7ec)    = -1 ENOENT (No such file or directory)
open("mini", O_RDONLY)                  = 5
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lseek(5, 0, SEEK_CUR)                   = 0
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 196
lseek(5, 0, SEEK_CUR)                   = 1024
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 0
close(5)                                = 0
stat("mini/desktop.ini", 0xbffff86c)    = -1 ENOENT (No such file or directory)
write(3, "\0\0\0#\377SMB\10\1\0\2\0\200\1\0"..., 39) = 39
SYS_142(0xff, 0xbffffc3c, 0, 0, 0xbffffc08) = 1
read(3, "\0\0\0?", 4)                   = 4
read(3, "\377SMBu\0\0\0\0\0\0\0\0\0\0\0\0"..., 63) = 63
time(NULL)                              = 896143871

この例では、存在していないファイルを見付けようとしてstat システムコールが何回か失敗しているのがわかる。熟練者でなくても desktop.ini がディレクトリに存在しないことがわかるだろう。実際traceを使って際厳正のある明示的なエラーを調査することで、多くの難解な問題の原因が特定できる。クラッシュ直前のメッセージ以外を調査する必要がないこともしばしばである。

9.1.3.2 tcpdump の利用

Van Jacobson, Craig Leres, Steven McCanne によって作成され、Andrew Tridgell が機能拡張した tcpdump プログラムは、ネットワークのトラヒックをリアルタイムに監視することを可能とする。様々な表示形式をとることが可能であり、特定のトラヒックだけを参照したいときに出力をフィルタすることも可能である。 tcpdump プログラムにより SMB やNMB のブロードキャストも含め、クライアントとサーバ間でやりとりされる全ての通信を調査することが可能になる。このツールには、主にOSIのネットワーク層のトラブルシューティングを行なう能力があり、クライアントとサーバの間で何がどのように試行され、達成されているかについて考察する際にも用いることが可能である。

tcpdump のログの例を以下に示す。この例において、クライアントはディレクトリの一覧を要求している。またサーバは適切に応答して、homes, public, IPC$, temp といったディレクトリ名を返却している(以下説明を少し付加している):

$ tcpdump -v -s 255 -i eth0 port not telnet
SMB PACKET: SMBtrans (REQUEST)	                        

リクエストパケット
SMB Command   =  0x25                                 

リクエストは ls もしくは dir である.

[000] 01 00 00 10                                     ....


>>> NBT Packet                                                                 

SMB パケットと無関係のパケット
NBT Session Packet
Flags=0x0
Length=226
[lines skipped]
                         
SMB PACKET: SMBtrans (REPLY)	                           

リクエストに対する応答(リプライ)の開始
SMB Command   =  0x25			                                  

コマンドはlsもしくはdirである
Error class   =  0x0			 
Error code    =  0                                                                    

エラーなし
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  105
Proc ID       =  6075
UID           =  100
MID           =  30337
Word Count    =  10
TotParamCnt=8 
TotDataCnt=163 
Res1=0
ParamCnt=8 
ParamOff=55 
Res2=0 
DataCnt=163 
DataOff=63 
Res3=0
Lsetup=0
Param Data: (8 bytes)
[000] 00 00 00 00 05 00 05 00                           ........ 

Data Data: (135 bytes)                                                        

			実際のディレクトリの内容:
[000] 68 6F 6D 65 73 00 00 00  00 00 00 00 00 00 00 00  homes... ........
[010] 64 00 00 00 70 75 62 6C  69 63 00 00 00 00 00 00  d...publ ic......
[020] 00 00 00 00 75 00 00 00  74 65 6D 70 00 00 00 00  ....u... temp....
[030] 00 00 00 00 00 00 00 00  76 00 00 00 49 50 43 24  ........ v...IPC$
[040] 00 00 00 00 00 00 00 00  00 00 03 00 77 00 00 00  ........ ....w...
[050] 64 6F 6E 68 61 6D 00 00  00 00 00 00 00 00 00 00  donham.. ........
[060] 92 00 00 00 48 6F 6D 65  20 44 69 72 65 63 74 6F  ....Home  Directo
[070] 72 69 65 73 00 00 00 49  50 43 20 53 65 72 76 69  ries...I PC Servi
[080] 63 65 20 28 53 61 6D                              ce (Sam

これはtrace コマンドで利用したのと同じ、ディレクトリを一覧するというデバッグのセッションの続きである。利用したオプションは -v (冗長出力), tcpdumpに(イーサネット上の)どのインタフェース上のパケットを取得するかを指示する-i eth0, パケットの先頭の68バイトだけを取得するというデフォルト値ではなく各パケットの先頭255バイトを取得することを指示する -s 255 である。port not telnet オプションは、このサーバにリモートからログインしている為発生する telnet のトラヒックを除外する為のものである。 tcpdump プログラムにはみたいトラヒックだけを抽出するために様々なフィルタのオプションが存在する。もし snoop か etherdump を利用したことがあれば、大体同じものだといってよいだろう。

修正版の tcpdump は Samba FTP サーバ上の ftp://samba.anu.edu.au/pub/samba/tcpdump-smb から入手できる。その他のものには SMB プロトコルのサポートは含まれていない。ここで示したような出力が行なわれない場合は、 SMB を扱える修正版を用いる必要がある。


8.7 smbtar によるバックアップ		9.2 Fault Tree

Using Samba