--- [管理番号 201] (最終更新 1999/02/17 23:58:45) Q. macintoshに対するファイルサーバをFreeBSD箱をつかってやりたいのです が、capとnetatalkの違いをおしえてください。 A. だいたい以下のとおりです。(追加歓迎) 実装方式: cap: カーネル外のdaemon群(bpfでappletalkパケットをつかまえる) netatalk: カーネル内のappletalk socketインタフェース + daemon インストールの手間: cap: /usr/ports/net/capにいって、root権限で # make; make install あとは設定ファイルを書く。 netatalk: カーネルコンフィギュレーションファイルに以下を追加して カーネルをmakeし、カーネルをとりかえる。 options NETATALK リブートする。 さらに、/usr/ports/net/netatalkにいって、root権限で # make; make install あとは設定ファイルを書く。 ファイルシェアリング: resource fork: cap 各ディレクトリ/.resource/nantara に保存 netatalk: 各ディレクトリ/.AppleDouble/nantara に保存 finder関連情報: cap: ディレクトリ/.finderinfo/nantara に保存 netatalk: 各volume/.AppleDesktop/nantara に保存 ゴミ箱: cap: ファイルを捨てると、各volume/Network\ Trash\ Folder/* に入る netatalk: ファイルを捨てると、各volume/Network\ Trash\ Folder/* に 入る。ただし、両者のファイルの扱いかたに互換性はないように見える。 非英字のファイル名: cap: (capをpkg_deleteしちゃったのでわかりません。だれか書いて) netatalk: 日本語はshift jisのまま、非ascii文字だけ :xx (xは16進数、小文字) に変換して格納される。つまり、「おはよう」というファイル名は FreeBSD側からみると :82:a8:82:cd:82:e6:82:a4 に見える。他の言語の場合、知らない。 変換される文字種について正確に知りたい場合ソースを参照のこと。 速度について: netatalkの方が速くて快調、という意見が多数を占めている。 そのほか: 「システムデフォルトで設定したmacintoshのボリュームだけマウントでき、 unix的にはなにもできないユーザを設定したい」場合、capではhome directoryやshellを持たないuidを作って解決することができる。すなわち、 /etc/passwdにこんなエントリを作って、macintoshからのmount専用にするこ とができる。 maconly:*:1024:2000:macintosh only client:/nonexistent:/nonexistent netatalkの場合、セレクタの認証のところでhome directoryを持たないユーザ 名を入力すると拒否される。これは~/.AppleVolumes (ユーザごとのボリュー ム設定ファイル)を読みにいこうとして失敗するためであろう。つまり、home directoryは必ず作らないといけないようだ。 capでは、親ディレクトリに.resourceや.finderという名前のディレクトリが ない場合には、子のディレクトリにもそれらは作られない(そのかわり、 resource forkつきファイルが格納できなかったり、finderの管理情報が保存 されなかったりする)。これはunixファイルシステムとの互換性を重視した設 計と言える。 netatalkでは勝手にどんどん.AppleDoubleが掘られるので、迂闊にmac側から ファイルを書くと、時としてディレクトリを掘られたくないのに勝手に掘られ ちゃって悲しむかもしれない。 capでは、デフォルトの設定ではゲストとしてのボリュームマウントが許可さ れていないが、netatalkの場合デフォルトで許可されているので注意する (afpd -Gとするとゲストのマウントは不許可になる)。 capのボリュームをマウントしたときmacintoshの画面に現れるアイコンは、 BSD悪魔くんなのでかわいい:-) netatalkはネットワークの生えた地球儀であ る。 cap <-> netatalkの乗り換えツールは見たことがないので、最初からどちらか に決めた方がよいだろう。 MacOSのボリュームサイズ制限(7.1*で2GBytes/7.5*で4Gbytes)を越えるような partitionをmacからマウントしたときのふるまいが異なる。capはほんとのディ スクサイズや空きサイズを伝えてしまうので、Mac側で容量が負になったりし て書けないようになる。netatalkでは嘘の値を渡してくれるので、とりあえず 書ける。(From kanai@hallab.co.jp) capで20MBytesを越えるファイルのコピーが失敗していた。netatalkではそう いうことは経験していない。(From kanai@hallab.co.jp) プリンタシェアリング: (やったことないので誰か書いて) --- [管理番号 202] (最終更新 1999/02/17 23:58:45) Q. cap/netatalkの管理に関してなにか注意点はありますか? A. 手でディレクトリのpermissionを変える場合、.AppleDoubleなどのディレ クトリのpermissionも変えるように十分注意しましょう。permissionの変更を 忘れると、Mac側でみていると非常にへんちくりんなエラーメッセージが出て なんのことかわからない場合が多いです。FreeBSD側でls -laとかしてチェッ クしましょう。 --- [管理番号 304] (最終更新 1999/02/17 23:58:45) Q. 拡張DOS領域内の論理ドライブはどうやったらマウントできますか？ A. 拡張 DOS は5番目以降になると思いますので、 # cd /dev # ./MAKEDEV wd0s5 # mount_msdos /dev/wd0s5 /foo (foo はマウントしたいディレクトリ) これでどうでしょうか。 --- [管理番号 421] (最終更新 1999/02/17 23:58:45) Q. Netatalk を使って MAC へディスクを公開する方法 A. --- [管理番号 510] (最終更新 1999/03/01 17:08:20) Q. netatalk-1.4b2 の papd で作った疑似 LaserWriter に Macintosh から印刷 しようとすると、プリントモニタがタイプ4のエラーで強制終了してしまいます。 A. MacOS8 に付属の LaserWriter 8.4.3 は、papd と相性が悪いようです。古 いバージョンの MacOS に付属のLaserWriter 8.2、および本 QandA 執筆時点 で最新の LaserWriter 8.5.1 では、正常に動作することが確認されています。 で、これらのファイルを探してみて下さい。 --- [管理番号 638] (最終更新 1999/02/17 23:58:45) Q. MS-DOS/Windows から，FreeBSD のスライスにあるファイルを参照すること はできますか? A. 一台のマシンに，FreeBSD と MS-DOS/Windows をインストールして，交互 にリブートして利用している環境の場合，FreeBSD のスライス内にある file を MS-DOS/Windows から参照することはできません． # 誰かが MS-DOS/Windows 用に device driver を書けば参照できるでしょう # が，現在(1998/05)，そのような device driver は存在しません． --- [管理番号 723] (最終更新 1999/02/24 04:14:22) Q. Hard Disk 上の DOS 領域を読み書きするにはどうしたらいいですか? A. msdos ファイルシステムとしてマウントすれば読めます。 (以下、デバイス名(sd0s1)、マウントポイント(/dos)は、各自の環境に あわせて読み換えてください) 具体的には、root になって # mkdir /dos (マウントポイント作成。既に/dosが存在する場合は必要なし) # mount -t msdos /dev/sd0s1 /dos (あるいはmount_msdos /dev/sd0s1 /dos) とします。 また、/etc/fstab に /dev/sd0s1 /dos msdos rw,noauto 1 0 と書いておくと、 # mount /dos # umount /dos などと短く書くことができます。また、noautoを外して /dev/sd0s1 /dos msdos rw 1 0 とすると、起動時に自動的にマウントしてくれます。 マウントされた DOS 領域の属性はマウントポイントの属性が引き継がれますので、 全ユーザが読み込み/書き込みできるようにしたい場合は、 # chmod 777 /dos としてください。このとき、既に /dos をマウントしていると chmod できません。 一度 umount してから chmod してください。 詳しくは mount(8) を参照してください。 なお、拡張DOS領域内の論理ドライブのマウントについては、 [管理番号 304] を参照してください。 --- [管理番号 818] (最終更新 1999/02/17 23:58:45) Q. Linux で使用していたハードディスクがあるのですが，このハードディス クの内容を FreeBSD で読み出すことはできますか? A. はい，できます． ただし，Linux と FreeBSD ではファイルシステムが違うので，カーネルを 再構築する必要があります． 手順: 1. カーネルコンフィグレーションファイルに次の行を追加する． (GENERIC カーネルには，このオプションは含まれていません) options "EXT2FS" 2. 通常通りにカーネルを再構築して入れ替える． 3. コンピュータを再起動する． これで準備完了です． Linux で使用していたハードディスクが /dev/wd2s1 ， FreeBSD でのマウント先を /mnt とすると， mount -t ext2fs /dev/wd2s1 /mnt あるいは mount_ext2fs /dev/wd2s1 /mnt とすればマウントできます． --- [管理番号 824] (最終更新 2001/10/14 11:51:14) Q. ネットワーク上にある Windows マシンのディスクをマウントしたい。 A. Sharity と Sharity-Light というのがあります。 Sharity は commercial product、Sharity-Light は free product です。 を参照してください。 Sharity-Light は ports に入っています。 --- [管理番号 1079] (最終更新 1999/07/02 16:24:22) Q. FreeBSD 以外のマシンと talk ができません。 A. talk(1) にも書かれているとおり、FreeBSD で使用している 4.3BSD 由来の talk(1) のプロトコルは、 4.2BSD 由来のものとは互換性が ありません。例えば SunOS などは 4.2BSD から別れているので、古い talk プロトコルを使用しています。なお 4.3BSD 由来の talk は ntalk と呼ばれており、ポート番号も異なるものを使っています (grep talk /etc/services してください)。 ですから、古い talk を使っている OS と FreeBSD や NetBSD などの 間で talk を行なおうとすると、 [Checking for invitation on caller's machine] と出てしまい、実際に talk することができません。 これを解決するには現在のところ 2 つの方法があります。 まず一つ目は古い talk を使っている OS に ntalk をインストールする 方法です。日本だと から取得可能です。これをコンパイルしてインストールします。これ 以降、FreeBSD からは通常に talk を、ntalk をインストールした側 では、talk の代わりに ntalk を使えば互いに talk できるように なります。なお FreeBSD 上で古い talk を動かすようにするプログラムは 今のところ存在しないようです。 二つ目は ytalk を使う方法です。ytalk は接続する時に ntalk が使え れば ntalk プロトコルで、ntalk が使えなければ古い talk プロトコル で接続を試みます。ですから相手の OS がわからず、talk と ntalk どちらを使えばいいのかわからないという場合でも迷わず ytalk を使えば ytalk が判断して適切なプロトコルで繋いでくれます。ただし ytalk には talk daemon はついていないので、相手側にも ytalk をインストールして、 相手も ytalk を使うようにしないとやはりプロトコルの相違の問題が 起きてしまいます (仲立ちをするのは既存の talkd なので、tty 上には respond with:talk user@hostname としか表示されませんが、そのとおりに答えると冒頭で述べた問題が やはり起きてしまいます。ytalk user@hostname としなければならない ことをあらかじめメールなどで確認しあっておく必要があります) なお ytalk は複数人での同時 talk や X の窓を使った talk もできる ように作られています。 そこまで苦労するのなら、いっそのこと phone や IRC を使った方が いいのかもしれませんが、ytalk にはインストールに root 権限が要ら ない、新規 daemon の起動が要らない、という利点があります。 最後に図にまとめてみます。 FreeBSD BSD4.2 x talk X <--- <--- o talk どちらも通信できない o ntalk ---> ---> X x ntalk (1) FreeBSD BSD4.2 x talk X <--- <--- o talk BSD4.2 側で ntalk o ntalk <---> <---> o ntalk を使えば通信できる (2) FreeBSD BSD4.2 x talk +---> ---> o talk ytalk が自動的に o ntalk <--- + <---+ x ntalk 相手のプロトコル ytalk --------+ +------ ytalk を判断して通信する (3) FreeBSD BSD4.2 phone <---> <---> phone phone を入れてしまえば 煩わしさはなくなる [付録] Solaris 2.x で gcc を使って ytalk をコンパイルする、あまり よろしくない方法。 (1) FreeBSD の配布サイトの distfiles ディレクトリから ytalk-v3pl2.tar.gz を入手する (2) 伸長・展開する。 % gunzip ytalk-v3pl2.tar.gz % tar xvf ytalk-v3pl2.tar (GNU tar なら tar zxvf ytalk-v3pl2.tar.gz も可) (3) imake がうまく動かないので X 上で動かすのをあきらめる (4) Makefile を書き換えて、SLIBS = -lnsl -lsocket を有効にし、 CC=gcc の行を加える % vi Makefile -#SLIBS = -lnsl -lsocket +SLIBS = -lnsl -lsocket +CC=gcc (5) 普通に make する % make Undefined first referenced symbol in file sigmask fd.o sigsetmask fd.o sigblock fd.o ld: fatal: Symbol referencing errors. No output written to ytalk と失敗する。 (6) UCB 互換ライブラリを使うようにして fd.o を作り直す。 (UCB 互換ライブラリがインストールされてない場合は、SUNWscpu を追加インストールする) % rm fd.o % setenv LD_LIBRARY_PATH /usr/ucblib % setenv LD_RUN_PATH /usr/ucblib % make CFLAGS=-I/usr/ucbinclude LDFLAGS=-lucb (7) できた ytalk を適当なところへほうりこむ % cp ytalk ~/bin % rehash --- [管理番号 1160] (最終更新 2001/05/07 03:21:08) Q. Sharity-Light で Windows のディスクをマウントしましたが、 すでにあるファイルへの上書きや追加書き込みをしようとすると <ファイル名>: Input/output error. というエラーが出てしまいます。 A. shlight に -e オプションをつけてマウントしてください。 たとえば、Windows 側のマシン名が WIN、共有するフォルダの 共有名が MYDOC で、これを FreeBSD 側の /win にマウントする 場合なら、 # shlight //WIN/MYDOC /win -e としてマウントします。 --- [管理番号 1243] (最終更新 1999/04/07 06:49:20) Q. NAT によって異なるネットワークに分割されている Windows 機の間で、 ファイルやプリンタの共有を行いたいのですが。 A. ファイル共有やプリンタ共有は次の要領で行います。 　・プロトコルを TCP/IP とする。 　・WINS を立ててどのマシンがどこに属しているかを教える。 (もしくは、LMHOSTS で指定する) 　・静的NAT情報を設定する。 以下に設定例を示します。ここでは、Windows におけるコンピュータ名の 解決に LMHOSTS を使い、また NAT として FreeBSD2.2.8 で IP Filter3.2.10 を用いているものとします。また、この例では、 hostA: public なネットワーク上 (123.45.67/24) の Windows 機 hostB: local なネットワーク上 (192.168.1/24) の Windows 機 とし、この2機間で共有を行うとします。 1. Windows 機で LMHOSTS を設定する。 ・hostA の LMHOSTS IPアドレス: IP filter 機 に割り当てられている public なIPアドレス ホスト名: hostB の Windows 上におけるコンピュータ名 ・hostB の LMHOSTS IPアドレス: hostA に割り当てられている public なIPアドレス ホスト名: hostA の Windows 上におけるコンピュータ名 (hostAにおける Window s上のコンピュータ名を、DNS で指定されている ホスト名と同じにしている時は、hostB の LMHOSTS を設定しなくても良い 場合がある。) 2. NAT 機で静的 NAT の設定をする。 IP Filter の場合、/etc/natrulesに、 rdr de0 123.45.67.0/24 port netbios-ssn -> 192.168.1.1 port netbios-ssn rdr de0 123.45.67.0/24 port netbios-dgm -> 192.168.1.1 port netbios-dgm を加える (192.168.1.1は hostB のIPアドレス、de0 は NAT 機の public 側の ネットワークインターフェースのドライバ)。 (投稿者の環境では、hostA、hostBいずれからでも[ネットワークコンピュータ] では相手のマシンが見えません。[スタート]-[検索]-[ほかのコンピュータ] とし、さらに相手のコンピュータ名を明示して検索することで、相手を 見ることが出来ます。) --- [管理番号 1480] (最終更新 2000/04/19 21:32:36) Q. FreeBSD 3.3-RELEASE でインストーラからブートマネージャをインストール したところ、Windows 用 ウイルスチェックプログラム「SYMANTEC Norton AntiVirus(2000.00)」を使用すると、 「コンピュータに次のウイルスが感染しています」 「BloodHound.MBR」 と、警告されました。 A. この件について株式会社シマンテックからは 「このメッセージは、MBRが別のプログラムに更新されたことに対する警告で す。ウイルスに感染した恐れがあるという意味のメッセージであり、感染 したかどうかの判定ではありません」 との回答がありました。 これは FreeBSD のブートマネージャが BootEasy から FreeBSD boot0 ブー トマネージャに変更されたことによるもので、たまたまパターンマッチの都 合上、3.2-R までは警告表示されなかったのでしょう。或は SYMANTEC でも 折込済みだったかです。もしかしたら新版では対応されるかもしれませんが、 気になるようなら FreeBSD 配布 CD-ROM や FTP サイトなどの tools ディ レクトリから、BootEasy (bootinst.exe、boot.bin) や osbs.exe(osbs20b8) など、別のブートマネージャに入れ替えれば警告は出なくなります。なお、 boot0 に関しては 3.4-R でも変更がなかったので、同じように警告される でしょう。 また、この件に関する質問は同社ユーザサポート窓口にて確認することがで きます。 株式会社　シマンテック (英文名称 Symantec Japan, Inc.) ユーザサポート TEL:03(3476)1156 FAX:03(3476)1159 FreeBSD 2.2 系では BootEasy を標準のブートマネージャに採用していまし たが、基本的に FreeBSD 外部のプログラムのためメンテナンスしにくいと いう問題があり、これを解決するために boot0 と呼ばれるブートマネージャ が新たに作られ、3.0-R 以降では標準採用されています。インストーラ (sysinstall) によって MBR にインストールされるなど、表面的には BootEasy とほぼ同じですが、boot0cfg(8) を使って設定を変更することが できます。ソースコードは /usr/src/sys/boot/i386/boot0/ にあり、シス テム構築後バイナリは /boot/boot0 に置かれます。 --- [管理番号 1582] (最終更新 2003/11/17 02:28:48) Q. LAN 経由での FreeBSD から Windows へのデータ転送が、その逆に比べ 圧倒的に遅いです。Windows 同士だとこのような現象は起りません。 A. 一般的な解は、一般的な要因に依存するため、何とも判りませんが、次 のような場合が Winsock2 の場合にあり得ることは判っています。 一部の NIC では、NIC のせいなのか NIC Driver のせいなのかは不明で すが、Windows で使った場合に、時々 packet の取りこぼしが発生します。 これは、NIC が用意している Recieve Buffer の大きさが、Winsock2 の Recieve Buffer よりも小さい場合、Winsock2 が NIC から packet を 吸い出す前に NIC の Recieve Buffer が溢れてしまうために起るのでは ないか、と推測されます。 Winsock2 の挙動を tcpdump などで見ると判るのですが、Windows 同士の 通信において、Winsock は送信において次のようなルールに従っているよ うに見えます(これは、そう「見える」と言っているだけであって、そう 「なっている」という意味で言っているのではありません。Winsock2 の 実装がどうなっているのかは、そのソースコードを見ることができない以 上、全く不明です)。 I) 2つのマシン A,B があって、A->B というデータ転送しかない場合、 A というマシンは Send, Send, Ack 待ち というパターンを忠実に守っているように見える。 II) 2つのマシン A,B があって、双方向に転送すべきデータがある場合、 A というマシンは Send(これには直前の Send に対する Ack を含んでいる), Data 待ち(これには直前の Send に対する Ack が含まれている) を繰り返す、というパターンを忠実に守っているように見える。 III) I と II を切り替える際には 0.1 sec の wait が入る。 もし、Windows 側の NIC のせいでこの現象が起っている場合は、 Windows->FreeBSD 方向の通信には、この障害は出ていないはずです。 (別の障害は出ているかも知れませんが :) さて、問題の解決方法ですが、ようするに上記の動きを FreeBSD 側で真 似てやれば問題は解決します。具体的には TCP/IP の Send Buffer Size をどうにかして「IP Packet 2つ分」まで減らしてやれば、問題は解決す るはずなのです。そうすれば Winsock2 がそれを全て取り込み、Ack を返 してくるまで先には進めません。 「IP Packet ２つ分」が何バイトなのかを知るには、基本的には tcpdump を使うのが手だと思います。tcpdump は root であれば FreeBSD で使う ことができますし、 WinDump を使えば Windows 側で tcpdump を取ることもできます。これらを使って、 mss の値を獲得します。これが「IP Packet 1つ分」の大きさだと思って ください。これを2倍すれば目的の値になります。 あるいは、ethernet を使っている場合は、mss は大抵、536byte か 1460byte のどちらかです。ですので、その丁度2倍 1072byte かあるいは 2920byte が「IP Packet 2つ分だ」という事ができます。ですので、 2920 を使ってみて、駄目だったら 1072 を使ってみる、という手もあり ます。 で、ここから先は FreeBSD の管理戦略にかなり依存します。 1) システム全体を特定の Windows マシンに合わせる、という場合: この場合、 sysctl コマンドを使うと良いでしょう。root になって $ sysctl -w net.inet.tcp.sendspace=xxxx (xxxx は上記の「IP Packet 2つ分」の大きさ) を設定してみましょう。 多分これでパフォーマンスは向上するはずです。 ちなみに、 $ sysctl -w net.inet.tcp.delayed_ack=0 を設定すると Windows -> FreeBSD 方向の通信も改善される場合がある、 という話があるそうです。 2) Windows マシン毎に設定を変える場合: 残念ながらマシン毎に FreeBSD の設定を変える場合、1 の場合のような 汎用的戦略はありません。各アプリケーションが、それぞれ、自分が通信 している相手を認識し、その適切な値をどこかのテーブルから lookup し なくてはいけませんが、そのようなサポートのないソフトもあるからです。 もし、Samba に関して、というのであれば、smb.conf の中の [global] section の最後に include = /usr/local/etc/smb.conf.global.%m のような1行を加えておき、 /usr/local/etc/smb.conf.global.<その問題の Windows マシン名> というファイル中で socket options = SO_SNDBUF=xxxx TCP_NODELAY (xxxx は上記の「IP Packet 2つ分」の大きさ) を設定するとよいでしょう。上記の include 文は失敗しても smbd の 起動に影響はありません。従って、特に特別な設定をする必要がない target に対しては /usr/local/etc/smb.conf.global.<その問題の Windows マシン名> というファイルを作成する必要はありません。このあたりは を参考にして下さい。 この方法は Winsock2 についてしかチェックできていません。従って、 Winsock1.1 の場合、あるいは将来できるであろう、Winsock2.1 (あるいは Winsock3) でうまく行くのかどうかは判りません。 もし、現在すでにある程度パフォーマンスが良い場合、SO_SNDBUF の値を mss の整数倍にすることで、効率が向上する可能性があります。ですので、 パフォーマンスを重視するマシンに対しては、そのマシン専用の /usr/local/etc/smb.conf.global.<その問題の Windows マシン名> ファイルを作った方がいいかも知れません。 smb.conf には %a(Architecture) というオプションがあります。マルチ ブートマシンがある場合は smb.conf を include = /usr/local/etc/smb.conf.global.%m include = /usr/local/etc/smb.conf.global.%a.%M のように変更して、%a と %M で Client OS と Machine Name を指定して やると各 OS ごとの設定も可能になります。 --- [管理番号 1658] (最終更新 2000/11/08 01:35:58) Q. FreeBSD の動作実績のあるマシンに Solaris を導入しました。その後 Solaris を消して FreeBSD を導入した所、FreeBSD が起動中に固まるように なりました。なぜでしょうか。 A. 原因は分かりませんが、状況証拠からすると Solaris が何らかの特殊な設 定を行なっているようです。電源を一度切断することで FreeBSD が再び起動 出来るようになるという報告が 3件あります。([FreeBSD-users-jp 53091] 参 照)。 マシンの電源を切断後、コンセントを抜き、数分置いてから、FreeBSDの再導 入を試みてください。 駄目ならコンセントを抜いた状態で電源ボタンを何回か押してみる。もしくは 長時間 (1日以上) 電源を切断した状態で放置してください。その後 FreeBSD の再導入を試みてください。 これでダメなら、対処法は分かりません。他の OS なら動作する場合もあるよ うです。 以上 Solaris7、Solaris8 での報告です。 --- [管理番号 1861] (最終更新 2004/04/09 05:05:34) Q. MSDOS 用パーティション (FAT) にある日本語ファイル名を扱うことは出来ますか。 A. A1. FreeBSD 5.2-RELEASE から、 マウントする際に -L と -D オプションを指定 することで、マルチバイト文字を使ったファイル名が扱えます。例えば日本語 ファイル名を扱いたい時は、次のようにします。 # mount_msdosfs -L ja_JP.eucJP -D CP932 /dev/ad1s1 /mnt ただし、 libiconv.ko msdosfs_iconv.ko モジュールを起動時に組み込むか、もしくは、 options LIBICONV options MSDOSFS_ICONV を追加してカーネルを再構築する必要があります。またどちらの場合でも、 libiconv (ports/devel/libiconv) のインストールも必要です。 詳細は [FreeBSD-tech-jp 3369] 、リリースノート、及び mount_msdosfs(8) を参照してください。 A2. 以下の ports/packages にあるアプリケーションで、MSDOS 用パーティション (FAT) の日本語ファイル名 (Unicode Long File Name) をサポートして います。 1. ja-msdosfs (ports/japanese/msdosfs) ports/japanese/msdosfs または packages の ja-msdosfs を導入し、 mount_jamsdos を使って FAT パーティションをマウントしてください。 日本語は EUC で表現されていますので、アプリケーションが EUC を扱 うことができれば、cp や tar などのコマンドを普通に使うことができ ます。(4.2-RELEASE 以降) 　補足: 起動時にマウントするには... 　/modules 以下に msdos_ja.ko が存在していていれば、mount_jamsdos を実行した時点でモジュールがロードされます。起動時に間違いなくマウント するためには mount_jamsdos を /sbin に置くべきですが、ports によっ て /sbin, /modules をいじるのはまずいので、自動ではなく手動 (/usr/local/etc/rc.d/ja-msdosfs.sh) でロードするように作られています。 　そこで、ブート時にマウントするのであれば、 　 # cp -p /usr/local/sbin/mount_jamsdos /sbin # cp -p /usr/local/lib/ja-msdosfs/msdos_ja.ko /modules # chmod a-x /usr/local/etc/rc.d/ja-msdosfs.sh 　とした後に、/etc/fstab でマウントエントリを書く時に FStype を jamsdos にしてください。 /dev/da0 /mnt msdos ro,nodev,noexec 0 0 ^^^^^ ここを修正 　再起動を行うと起動時にマウントされているはずです。 2. ja-mtools (ports/japanese/mtools) [管理番号 640] GNU の mtools に Unicode LFN サポートを加えたものです。mtools に 含まれるコマンド (mdir や mcopy など) だけで取り扱うことができます。 3. fd (ports/shells/fd) いわゆる FDclone です。DOS 時代の FD に似た (といっても知らない 人も多いかもしれませんが) CUI ベースのファイル操作ツールです。 --- [管理番号 1870] (最終更新 2001/04/18 02:12:14) Q. NetBSD/i386 と FreeBSD を1台のハードディスクに共存させて、ブート時に 切り替えて使いたいのですが、どうすればいいでしょうか？ A. 結論から言えば、現在では特別な小細工は不要です。 しかし以前は、複数の BSD パーティション (ここでいうパーティションは FreeBSD で言うところのスライス) に各々 FreeBSD をインストールしても、 始めに見つかった BSD パーティションからしかブートできませんでした。 また NetBSD と FreeBSD は、パーティションID が 165(0xa5) と同じだった ので、同様に2番目以降の BSD パーティションからはブートできませんでし た (現在の NetBSD/i386 では 169)。 これには NetBSD, FreeBSD 共に、 1. MBR にインストールされるブートマネージャ (ブートセレクタ) 2. BSD パーティションの先頭に書き込まれるブートブロック 3. カーネル の何れかに制限があったためです。 SYSTEM COMMANDER などのいくつかのブートセレクタは、この2.以降の制限を 出し抜くために、一時的に問題となるパーティションを隠す機能が付いてい ます。[FreeBSD-users-jp 29512] [管理番号 797] --- [管理番号 1926] (最終更新 2001/10/22 01:18:34) Q. LAN 経由での Windows から FreeBSD へのデータ転送が、その逆に比べ 圧倒的に遅いです。Windows 同士だとこのような現象は起りません。 A. 最大の理由は「Winsock2 は 2 packet 送信すると ack を待ってしまうか ら」です。 Windows の TCP/IP 層はデフォルトでは 2 packet 送信する度にAck を待っ てしまいます。unix は TCP Window size にゆとりがある場合は「きっと 向うはまだ送ってくるだろうから」と安心して piggy bag できる packet がないか調べるために、10msec ほど沈黙します。当然一方向の通信 (RPC とか) の場合 piggy bag などできるパケットが存在しませんので、この 10msec の間、全くデータが転送されることがなくなります。 Windows 同士の場合、受け側も「2packet 受け取ったら速攻で ack を返さ ねばならぬ」と思い込んでいるので、この「待ち」がほとんどありません。 FreeBSD でこの問題を解決するには、sysctl で # sysctl -w net.inet.tcp.delayed_ack=0 とすることです。こうすれば piggy bag できるかどうか悩むことなく、 FreeBSD は ack を即座に返すようになります。 ただし、この設定は「特定のコネクション相手」単位では設定できません。 全体に有効になってしまいます。で、他の unix マシンと通信する場合、 これは ack を投げすぎることになるので、逆にパフォーマンスを落す可能 性が高いです。 なお、この現象は [管理番号 1582] に似ていますが、異なる現象です。 しかし、Winsock2 に起因するところは同じです。ただし、Windows 2000 (と多分 Windows Me) の Winsock2 では発生しないようです。 --- [管理番号 2034] (最終更新 2001/10/22 01:18:35) Q. Ports からインストールした smbfs-1.4.1 を使って、Windows の共有フォルダ をマウントしたいのですが、下記のようなエラーで失敗します。smbfs.ko を ロードすることも出来ません。テスト環境は FreeBSD 4.4-RELEASE です。 ># mount_smbfs //hoge@hoge_server/hoge_share /mnt mount_smbfs: vfsload(smbfs): Exec format error ># kldload smbfs kldload: can't load smbfs: Exec format error A. /var/log/messages に次のようなエラーがでていませんか？ Oct 9 22:57:19 xxxxxx /kernel: link_elf: symbol iconv_open undefined その場合、下記のオプションをカーネルに追加する必要があります。 options NETSMB #SMB/CIFS requester options NETSMBCRYPTO #encrypted password support for SMB options LIBICONV #Kernel side iconv library options LIBMCHAIN #mbuf management library KLD モジュール (smbfs.ko) を使いたい場合でも、LIBICONV はカーネルに static link しなければなりません。また、mount_smbfs を実行 (smbfs.ko をロード) する前に、libmcain.ko をロードしておく必要が有ります。 --- [管理番号 2576] (最終更新 2004/04/09 05:05:52) Q. NTFS / CD9660 / UDF で日本語ファイル名を扱うことは出来ますか。 A. FreeBSD 5.2-RELEASE から、日本語を含めた、マルチバイト文字を使った ファイル名を、これらのファイルシステム上で扱うことが出来ます。 ただし、 libiconv.ko ntfs.ko (NTFS) ntfs_iconv.ko (NTFS) cd9660_iconv.ko (CD9660) udf.ko (UDF) udf_iconv.ko (UDF) モジュールを起動時に組み込むか、もしくは、 options LIBICONV options NTFS options NTFS_ICONV options CD9660_ICONV options UDF options UDF_ICONV を追加してカーネルを再構築する必要があります。またどちらの場合でも、 libiconv (ports/devel/libiconv) のインストールも必要です。 詳細は [FreeBSD-tech-jp 3369] 、リリースノート、及び mount_ntfs(8) , mount_cd9660(8) , mount_udf(8) を参照してください。 参考: [FreeBSD-users-jp 76194] からのスレッド。 (当時の 4-stable 向けのパッチもあります。)