smbfsは、UNIXからWindowsマシンの提供する共有フォルダをマウントしてファイルシステムとして使用できるようにするLinuxカーネルの機能ですが、smbfsの機能を使うためのユーティリティもsmbfsという名称で配布されていますので、それらの総称として使われることもあります。
ちょっと話がそれますが、Linuxはローカルディスクに関しても、Windows 95のVFATへの対応はもちろん、最近はNTFSにも（リードオンリーですが）対応しています。その努力には本当に敬服します。
最近のLinuxディストリビューションでは、smbfsの機能を有効にした状態のカーネルが提供されていると思います。この場合は、ディストリビューションからsmbfsのパッケージをインストールするだけで、smbfsが使用可能になります。
たとえばRed Hat Linux 5.2の場合は、「smbfs-2.0.1-4.i386.rpm」をインストールすることになります。
自力でインストールする場合は、カーネルのコンパイルとsmbfsプロダクトの入手が必要です。カーネルをコンパイルする際には、[Filesystems]‐[SMB filesystem support]が“y”か“m”になっていることを確認してコンパイルを行なってください。
smbfsに関しては、「smbfs-2.0.2.tar.gz」という名称のsmbfsの最新版がftpサイトなどにありますので、これを入手してコンパイルすることになります。しかし、ファイルの日付を見ていただければわかりますが、最近はメンテナンスされていません。
筆者もRed Hat Linux 5.2でコンパイルしてみましたが、あちこちでソースを修正する必要がありました。修正箇所はカーネルバージョンによっても異なると思いますし、自力でインストールしようとする方であれば、自力で修正できると思いますので、ここでは修正方法にはふれません。
カーネルバージョン2.1.70以降では、Sambaに付属するツールを使うことが可能です。
この場合は、Sambaのconfigure時に“--with-smbmount”オプションをつけて、コンパイルおよびインストールを行なってください。smbmntおよびsmbumountという２つのユーティリティがインストールされます。筆者の方でカーネルバージョン2.2系でも動作することは確認しました。
以下Windows NTの共有フォルダ「\\ntws\share」に、ユーザ「smbuser」で接続して、「/smb」にマウント後、dfコマンドを実行した場合の例を図１に示します。
現在はカーネルバージョン2.0系から2.2系への移行期のため、本当はsmbfsとあわせて両方とも解説したかったのですが、出版時点では、まだ2.0系が主流だと思われますので、誌面の関係上こちらは紹介するにとどめておきます。
# smbmount "╲╲ntws╲share" -W NTWS -U smbuser -c 'mount /smb'
Added interface ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx nmask=xxx.xxx.xxx.xxx
Server time is Thu May 13 01:45:53 1999
Timezone is UTC+9.0
Password: ← smbuserのパスワードを入力
Domain=[HOME] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
security=user
# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda3 425447 381321 22152 95% /
//NTWS/SHARE 1052224 378624 673600 36% /smb
#
それではsmbfsを使ってみましょう。
Windows側の共有フォルダをマウントするコマンドはsmbmountになります。
UNIXマシン「unix1」からWindows NTの共有フォルダ「\\ntws\share」に、ユーザ「smbuser」として接続して、「/smb」にマウントする場合の例を図２に示します。
# smbmount //ntws/share /smb -U smbuser -c unix1
Password: ← ユーザ「smbuser」のパスワードを入力
接続後、dfコマンドで接続を確認してみると図３のようになっています。また図４は“ls -l”コマンドの出力結果です。なお、アンマウントは普通のumountコマンドで行なえます。
# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda1 1527189 1260257 188006 87% /
/dev/scd0 499012 499012 0 100% /cdrom
//ntws/share 1052224 378624 673600 36% /smb
#
$ ls -l
total 4
drwxr-xr-x 1 root root 512 Apr 26 05:11 ForYou
drwxr-xr-x 1 root root 512 Apr 20 05:30 SYM18.tmp
drwxr-xr-x 1 root root 512 Apr 19 11:36 _ISTMP0.DIR
drwxr-xr-x 1 root root 512 Apr 19 11:34 work
$
接続できたあとは、いろいろ使ってみたくなるところですが、smbfsにはかなり制限事項があります。
一番の問題は、『アクセス権』です。
smbfs経由でWindowsの共有フォルダに接続した場合Windows上ではsmbmountのオプションで指定したユーザ名でファイルアクセスが行なわれます。図２の例では、「smbuser」になります。つまりUNIX側からどのユーザアカウントでアクセスしても、「smbuser」でファイルアクセスが行なわれてしまうわけです。
また、図４ではファイルの所有者がrootになっています。ファイルの所有者には、接続時に“-u”オプションを使うことで、任意のuid（ユーザID）を指定することができますが、結局共有フォルダ内のすべてのファイルは、UNIX側から見るとある特定のアカウントが所有しているように見えてしまいます。アクセス権も同様に接続時に一律（デフォルトは755）に設定することしかできません。
したがって、読み込み専用として使用するならよいのですが、書き込みを許可させたい場合、アクセスの制御は、smbmount実行時に指定するファイルのuid、gid（グループID）およびアクセス権の設定でしかできませんので、ファイルの一時受渡し領域として誰でも書き込み可能にするような用途に限られると思います。
またNTFSでサポートしているハードリンクを張ろうとしても図５のように怒られます。当然シンボリックリンクもできません。
日本語のファイルはシフトJISのまま表示されますので、UNIX側はシフトJISで表示を行なわないと日本語が表示されません。
# ln tako2 tako1
ln: cannot create hard link `tako1' to `tako2': Operation not permitted
# ln -s tako2 tako1
ln: cannot create symbolic link `tako1' to `tako2': Operation not permitted
#
smbmountおよびsmbumountを図６のようにsetuidすることで、一般ユーザでもWindowsの共有フォルダをマウントすることが可能になります。図７は一般ユーザでWindows 95の共有フォルダのマウントを行なった所です。
# chmod u+s /usr/sbin/smbmount
# chmod u+s /usr/sbin/smbumount
% /usr/sbin/smbmount //akari/temp /home/monyo/smb -c mosel
Password:
% df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda1 1527189 1260670 187593 87% /
//akari/temp 1705248 863328 841920 51% /home/monyo/smb
%
smbmountでは“-f”オプションを使うことでマウント先のファイルのアクセス権を自由に設定できるのですが、試した限り、「setuid」「setgid」「sticky」などのビットは落してくれるようです。しかし念のために、もし一般ユーザでの使用を許可する場合は、これらのビットが設定されないことを確認してから使ってください。
今まで見てきたように、smbfsは、アクセス権やシンボリックリンクなどの機能が不足しているため、定常的にマウントして使うには、ちょっとものたりないという気がしますが、読み込み専用であれば、ある程度実用になると思います。
ともあれ、UNIX側からWindows上のファイルシステムを直接使う術を提供してくれる点では貴重なツールといえましょう。
| NEXTSTEP 3.x、4.x（i386 & m68k） | Linux |
| FreeBSD | NetBSD |
| BSDI | Solaris 2.x |
| HP-UX | IRIX（ただし6.4以降では動作しません） |
「Sharity-Light」は、smbfsのコードを流用することで、一般的なUNIXマシンからもWindowsマシンの提供する共有フォルダをマウントし、ファイルシステムとして使用する機能を提供するツールです(図８)。
もともと「Rumba」と呼ばれていたプロダクトですが、「Rumba」という名称がすでに商標登録されていたため、「Sharity-Light」という名称に改名されて提供されています。個人的に「Rumba」というネーミングセンスは気に入っていたので残念です。
ソースコードはGPLに基づいて公開されており、
●Sharity-Light - SMBFS for UNIX：
http://www.obdev.at/products/sharity-light/
から無償で入手しての使用が可能が可能です。
現在動作が確認されているOSは表１のようになっております。
「Sharity-Light」とは別に「Sharity」という同様の機能を持ったソフトウェアが以下で公開されています。
●Sharity - Access Windows Servers from and Unix：
http://www.obdev.at/products/sharity/
まったくのスクラッチから開発を始め、「Sharity-Light」の不具合も改善されているようですが、残念なことに商用となっておりますのでここではこれ以上紹介しません。上記のURLから試用版のソースがダウンロードできますし、学生は無償のアカデミックライセンスがあるとのことですので、興味のある方はぜひ試してみてください。
「Sharity-Light」はsmbfsの機能だけを切り出し、ユーザプロセスで動作するプログラムとして実現したものです。カーネルとはNFSのインタフェースを使って通信を行ないます。
Linuxカーネルに実装されているsmbfsと比較して以下のような特徴があります。
FreeBSDの場合は、ports-currentにportsがありました。FreeBSDやLinuxなどでportsやパッケージがあれば、そこからインストールしても良いでしょう。
以下は自力でコンパイルする方法を説明します。
まずは，アーカイブを入手します。
●Sharity-Light - SMBFS for UNIX：
http://www.obdev.at/products/sharity-light/
より「Sharity-Light-1.2.tar.gz」という名称で入手可能ですので、入手して展開してください。
ただし、autoconfには対応していないので、手動でMakefileを編集する必要があります。とはいえ以下の図９のように、デフォルトで有効になっているNeXTSTEPの設定をコメントアウトして、コンパイルしたいOSの設定を有効にするだけですので、特に問題ではないでしょう。
#-----
## For NEXTSTEP/OPENSTEP:
#CFLAGS = -Wall -O2 -traditional-cpp -g ← この５行をコメントアウト
# put your architecture here:
#ARCH = -arch i386
#THE_CC = cc
# RPC_WARNFLAGS = -Wno-unused -Wno-switch -Wno-uninitialized
# For Linux: (use static linking because of libc5/libc6 troubles)
CFLAGS = -Wall -O2 -g ← この３行のコメントを外す
LDFLAGS = -static
RPC_WARNFLAGS = -Wno-unused -Wno-switch -Wno-uninitialized
#-----
図９ではLinuxの場合の例を載せましたが、他のUNIXでも同様です。ちなみに筆者が動作を確認した環境は以下の通りです。
・Red Hat Linux 5.2J
・FreeBSD-2.2.7(R)
・Solaris 7 for Intel Platform（英語版）
Makefileの修正後makeを行なうと、shlightという実行ファイルが生成されています。この他に、アンマウントを行なうためのプログラムとして“unshlight.sh”および“unshlight.c”というシェルスクリプトおよびCのソースが提供されています。
しかし、両方とも汎用的なものではないため、ほとんどのOSではそのままインストールするのが困難です。とくになくても実用上は困らないため、ここではこれ以上触れません。
インストールが完了したところで、さっそく使ってみましょう。
以下の作業はrootで行なう必要があります。なおここではWindows側で共有フォルダを作成する方法については特に解説しません。市販の書籍などを参考にしてください。
smbfsの場合と同様に、Windows側の共有フォルダ「\\ntws\share」に、ユーザ「smbuser」で接続して、「/smb」にマウントする場合の例を図10に示します。
smbmountに相当するコマンドはshlightになります。
# shlight //ntws/SHARE /smb -U smbuser
Password: ← smbuserのパスワードを入力
Using port 1889 for NFS.
shlightのオプションは、smbfsと基本的には同じになっており、パッケージ中にもsmbmountのマニュアルページがそのまま入っております。一応筆者が翻訳した主なオプションの説明を表２に載せましたので参考にして下さい。
また図11のように“-h”オプションをつけてshlightを実行することで、すべてのオプションを確認することができます。
なお、Windows 95系のOSに接続するときは注意が必要です。
shlightコマンドでは“//”に続いて「サーバのIPアドレス」か「有効なホスト名」を記述する必要がありますが、これが接続先のコンピュータ名と異なっていると接続できません。
この場合、“-s”オプションを使って、明示的に接続先のコンピュータ名を指定する必要があります。
ここでdfコマンドを実行してみると図12のように表示され、確かにマウントできていることが確認できます。なお「shlight-8691」の“8691”という数字はshlightプロセスのPIDを表します。
# df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda1 1527189 962004 486259 66% /
shlight-8691 4072448 1029504 3042944 25% /smb
最後に使い終ったらアンマウントしておきましょう。
普通は通常のファイルシステムと同じくumountコマンドでマウント解除できるはずです。ところがSolarisの場合は、図13のようにいわれてマウントが解除できませんでした。
# umount /smb
nfs umount: /smb is not hostname:path format
このように、何らかの理由でアンマウントができなくなった場合は、shlightプロセスを“kill”することでマウントを解除する必要があります。
なお、「Sharity-Light」はsmbfsから派生したものですので、smbfsの項で記述した注意点はそのまま当てはまりますが、smbmountと違い、マウント時に“-f”オプションを使うことでsetuidビットを指定できてしまいます。
したがって、『家庭内で使う場合などを除き、絶対にshlightを一般ユーザで実行可能にしてはいけません』。
| コマンドオプション一覧 | 内 容 説 明 |
|---|---|
| -s サーバ名※1 | サーバのNetBIOS名を指定します。 |
| -c クライアント名※1 | クライアントのNetBIOS名を指定します。 |
| -U ユーザ名 | デフォルトでは、USERまたはLOGNAME環境変数から読み込みます。 これらが設定されていない場合や、別のユーザとしてサーバにログオンしたい場合にこのオプションを設定します。 |
| -W ワークグループ | サーバに送るドメイン／ワークグループ名です。 |
| -u uid（数字もしくはユーザ名）※2 | マウントしたファイルの所有者（UID）を設定します。 |
| -g gid（数字もしくはグループ名）※2 | マウントしたファイルの所有グループ（GID）を設定します。 |
| -f mode（8bit表記） | ファイルに設定されるUNIXパーミッションを設定します（デフォルト644）。 |
| -d mode（8bit表記） | ディレクトリに設定されるUNIXパーミッションを設定します（デフォルト755）。 |
| -C | パスワードを大文字に変換しない。 |
| -P パスワード | パスワードを指定します。 なお、ここで入力したパスワードは、psコマンドでコマンドラインを見た時には“ * ”で表示されます。 |
| -i | パスワードを標準入力から読み込む |
| -n | パスワードを使用しない。 “-P”も“-n”も指定されていないと、パスワードプロンプトが表示されます。 |
| -S | 一回のOPENでRead/Writeを行なっても安全であるとみなします。 詳細はREADMEを参照して下さい。 明らかに安全である時以外はこのオプションは指定しないのが良いでしょう。 |
| -w | 読み込み専用でマウントします。 |
| -e | SMBコマンドのgetattrEとsetattrEを使用します。 これについての解説はREADMEを参照して下さい。通常は設定の必要はありません。 |
| -F .※3 | ルートディレクトリの“.”を偽造しません。 |
| -F ..※3 | ルートディレクトリの“..”を偽造しません。 |
| -h | ヘルプを表示します。 |
| -v | バージョン番号を表示します。 |
| -p ポート番号 | 接続するポートを指定します（テスト用のオプションです）。 |
| -m 最大転送量 | 最大転送量を指定します（テスト用オプションです）。 |
| -D デバッグレベル（数字） | デバッグレベルを指定します。 このオプションを指定すると、「Sharity-Light」はフォアグラウンドで起動します。 |
今まで見てきたように、とりあえず使うには重宝する「Sharity-Light」ですが、それ以上に使うのはちょっと無理だと感じています。
READMEにもいくつか問題点の記述がありますが、それ以外にも、以下のような問題点があります。
# ls
./setup.exe: Value too large for defined data type
./SETUP.LST: Value too large for defined data type
ForYou.CAB* Project/ tes.txt*
とにかく不安定だと言う印象です。
あくまでどうしても必要なときにちょっと使ってみる程度にとどめておいた方が良いと考えています。
「Sharity-Light」のドキュメントを見ると、今後の開発はバグフィックスとポーティングのみで、新たな機能拡充は行なわないとアナウンスされています。商用として「Sharity」を開発しているため、今後はこちらを機能強化していくようです。
でも、「Sharity-Light」のほうも、ソースが公開されている以上、まだまだ捨てたものではないと思います。使ってみて不満があれば、自分で直すという手段が残されているわけですから。
●Sharity-Light - SMBFS for UNIX：
http://www.obdev.at/products/sharity-light/
●Sharity - Access Windows Servers from and Unix：
http://www.obdev.at/products/sharity/