Mac OS X Server 10.2を
ファイルサーバとして使う

BSDベースのサーバOSであるMac OS X Serverを、オフィスで使うファイル共有のサーバとして効果的に使うという視点で、セットアップからアクセス権についての情報までをまとめてみました。

Mac OS X Serverについて

　Appleから販売されているMac OS X Server 10.2は、デスクトップで使われているMac OS Xとまったく同じOSコアを持ったサーバOSです。もちろん、サーバなので、ファイルサーバはWebサーバといったサービスが提供できるようになっています。大きな特徴は、Mac OS Xで稼働する使い勝手の良い管理ツールが用意されており、GUIのツールで基本的な設定や日常的なメンテナンスをこなせることができる点です。いわば、UNIXを知らなくてもBSDベースのサーバOSをかなり使いこなせるということになるので、専任の管理者をおかなくても、誰かが片手間で管理するということもできるということが期待されます。

　その意味では、たとえば、デザインオフィスや小規模なオフィスで、ネットワークやUNIXの知識は弱くても、Macは使い慣れているといったようなユーザに対して、ファイルサーバを使いたいというニーズには沿うものです。長年使っているAppleShare IPをそろそろ移行したいが、Linuxサーバの管理は大変そうだしと思うと、Mac OS X Serverに目を向くでしょう。この記事では、そういう方々に向けて、ファイルサーバのセットアップと管理のポイントになるところをお届けします。本誌の他の記事よりも技術的には浅いかもしれませんが、ガイドになればと思います。

　Mac OS X Serverは、執筆時点では、Ver.10.2.6がリリースされています。もちろん、コアはMach 3.0、FreeBSD 4.4、そしてPosix準拠といった、UNIX OSと言えるものです。その上に、グラフィックス処理などのOS機能を積み上げていますが、サーバ機能で言えばBSDのレイヤを使うことになり、FreeBSDとの違いは非常に少ないものです。一方の管理ツールは、Mac OS XないしはMac OS X Serverでしか稼働しないネイティブなアプリケーションですが、ある意味で気楽に使えます。システムの設定もMac OS X同様、GUIで行えます。一方、シェルを使っての管理も行えますから、コマンドで処理することも可能です。ただ、コマンドが使える人でも、管理ツールでやれる範囲はそちらで行い、それだと面倒だとかどうしてもできないときに「ターミナル」を起動するというのが一般的な使い方です。

現状での現実的なインストール

Mac OS X Serverのインストールは決して難しいものではありませんが、後からの運用に関する重大な決定をそこでします。もちろん後から設定変更は不可能ではないというものの、ここでの決定であとから大変な思いをすることになったユーザも、筆者を含めてたくさんいらっしゃるかもしれません。

　この重大な決定とは、「ディレクトリサービスを使うかどうか」ということです。Mac OS X Serverのディレクトリサービスには、ディレクトリサーバとパスワードサーバが中で稼働し、さらにディレクトリサーバ自体は、ネットワークに公開されるNetInfoサーバとそれをゲートウエイしてLDAPv3でアクセスできるようにするOpenLDAPベースのサーバが稼働します。

　結論から言えば、Apple Filing Protocol（AFP〜従来の用語では「AppleShare」）、つまりMac OSやMac OS X向けのファイル共有機能を使うだけなら、ディレクトリサービスはなくても運用できます。しかしながら、Windowsクライアントからファイル共有機能を使いたい場合には、ディレクトリサービスは必須となっています。後から使おうということでもいいのですが、ディレクトリサービスを使うようにシステムを切り替えた時、パスワードは全部リセットされるということもありますので、今後Windowsからも使うのであれば、ディレクトリサービスは使うようにしておくのがいいかと思います。以下は、ディレクトリサービスを使うことを前提に話を進めます。

インストールの手順

　Mac OS X Serverは、サーバ専用機のXserveには最初から付属しています。現在のXserveにはMac OS X Server 10.2.4が付属している模様です。一方、パッケージとして販売されているMac OS X Serverは10.2.3です。いずれにしても「アップデートする」という必要はありますが、いくつかの問題点などを回避するために、パッケージとして購入された場合は、次のような手順でのインストールを行ってください。セットアップ時の注意としては、必ずEthernetを接続してポートをアクティブにしてください。固定IPを振ってもハブとつながないとポートは死んだ状態になり、一部のセットアップに支障を来します。必ずネットワークにつないで行います。

1. CD-ROMから起動してMac OS X Serverを普通にインストールします。

2. 再起動後、「Mac OS X Serverアシスタント」が動きます。ここでは、IPアドレスなどきちんと設定を行います。

3. 「オープンディレクトリアシスタント」の2ページ目「場所」のダイアログボックスで、「一時的なIPアドレスとサブネットを使用しています。」を選択します。すると、他に設定はできず、ディレクトリサービスは機能しない状態で、再起動をかけます。

図　インストール直後のオープンディレクトリアシスタントで、ディレクトリサービスを起動しないようにするために、「一時的なIPアドレス…」を選択する

4. 再起動後、「Mac OS X Serverアシスタント」で指定した管理者のアカウントでログインをします。

5. ソフトウエア・アップデートなどで、OSを最新のバージョンにします。必要なアップデートをかけると同時に、Ethernetカードのドライバなどをインストールします。この段階で、ネットワーク設定もきちんと最終的なものにしておくのが望ましいでしょう。

6. ユーティリティフォルダにある「オープンディレクトリアシスタント」を起動して、ディレクトリサービスを使用するという設定にします。起動時にログインのパネルが出てきますが、ここで指定するアドレスには、Ethernetポートの外向きにアクティブなアドレスを必ず手で指定します。その他の設定ポイントは図を参照してください。

図　オープンディレクトリアシスタントのログインでは、アドレスに、実際に使っているEthernetポートのIPアドレスを指定し、管理者としてログインする

図　「ディレクトリの使用方法」のページでは、この選択肢を選ぶことで、ディレクトリサーバとして稼働する

図　「セキュリティ」のページでは、この選択肢を選ぶことで、パスワードサーバとして稼働する

　以上の手順を経れば、いろいろな問題は回避されます。ひとつの問題である、管理者のパスワードを9バイト以上にするとログインできなくなるというのは、10.2.4で解消されています。それ以前だと、管理者のパスワードをディレクトリサービスの管理者としてパスワードサーバに移行する部分（「オープンディレクトリアシスタント」内部）でエラーが出ていましたが、10.2.4では直っています。上記の手順だと、10.2.3のCD-ROMで作業をしても、その問題は回避できます。

　ディレクトリサービスを動かす場合、IPアドレスは固定にするのが原則です。ところが、固定にするだけではなく、「あとから変えるとえらいことになる」ということになっていました。えらいことというのは、登録したユーザ情報を忘れる、あるいは最悪はどんなユーザでもログインできなくなるというような大きな問題が発生します。しかしながら、IPアドレスを変更するスクリプトがやっと、8月にAppleからリリースされましたので、これを使ってください（TIL #107637）。しかしながら、現状のバージョンでも、システム環境設定でIPアドレスは絶対に変えないでください。上記のスクリプトを必ず使ってください。また、ディレクトリサービスを使わない場合でも、IPアドレスの変更は上記のスクリプトを使います。

（脚注）TIL、Tech Info Libraryはアップルが提供する日本語での技術情報です。番号だけでなくキーワード検索なども行えます。アップルのトップページから→サポート→Tech Info Libraryとナビゲートしてください。

ファイルサーバの設定

　ここからはMac OS X Serverの管理ツールを使っての作業になります。もちろん、Mac OS X Server内にはインストールされますが、パッケージを購入されると別途管理ツールのCD-ROMが含まれているはずです。それを使って、普段使っているMac OS Xにインストールすれば、そのMacからリモートで管理ができます。ただし、これもバージョンの問題があり、管理ツールのアップデータはなぜか存在しません。10.2.3以降の変更は非常に少ないみたいですが、やはり、できれば最新版のユーティリティを、普段使うMacにも入れておきたいものです。サーバのユーティリティフォルダにある、「ワークグループマネージャ」「サーバ設定」「サーバステータス」「オープンディレクトリアシスタント」は必須のツールでしょう。Xserveの人は「サーバモニタ」も必要です。必要なら、「サーバアシスタント」「Macintosh Manager」「ネットワークイメージユーティリティ」もコピーしておきます。なお、これらのユーティリティの多くは、起動後サーバにログインして利用する形式になっています。もちろん、最初に設定した管理者のアカウントでログインしますが、キーチェンにパスワードを記憶させるなどすることで、以後のログイン作業は楽になりますが、セキュリティ的には注意をしてくだしあ。

　Mac向けのファイル共有機能であるAFPは、「サーバ設定」のAppleのアイコンから行います。設定を行うメニューを選んで設定をしますが、AFPについて注意するのはAppleTalkの設定くらいでしょう。AppleTalkで利用する場合は、そのネットワークポートは、AppleTalkがアクティブになっていなければなりません。システム環境設定でのチェックボックスを入れればいいのですが、できれば、セットアップ時からAppleTalkをアクティブに設定しておくのがいいようです。

図　「サーバ設定」のAppleファイルサービスの設定。必要ならAppleTalkの設定をチェックする

図　「サーバ設定」のAppleファイルサービスの設定。ゲストアクセスは既定値ではオフになっている

　一方、Windows向けサーバは、いくつか設定ポイントがありますが、ワークグループ名の設定は多くの場合は変更したいでしょう。そして、コードページは日本語にしておきます。さらに、ドメインマスターブラウザにしないと、Windows側での「マイネットワーク」などからのサーバをブラウズできなくなります。

図　「サーバ設定」のWindowsサービスの設定。ワークグループ名やコンピュータ名の変更に加えて、コードページが日本語になっていることを確認

図　「サーバ設定」のWindowsサービスの設定。ドメインマスタブラウザのチェックを入れておかないと、Windows側でブラウズできない場合もある（サーバがMac OS X Serverしかないとき）

ワークグループマネージャでのユーザ管理

　ユーザ登録は、「ワークグループマネージャ」で行います。もちろん、リモート接続してユーザを登録してもかまいません。ユーザ登録には「ワークグループマネージャ」の画面で、上の方にある「アカウント」のアイコンをクリックしますが、起動時には常にその状態でウインドウが開きます。左側に3つのタブが見えるリストがありますが、順に、ユーザ、グループ、コンピュータグループのリストを表示します。ファイルサーバとして利用する場合は、ユーザやグループの設定だけでかまいません。

図　ワークグループマネージャでユーザを新規に登録する

　ここで、左下にある「場所」のポップアップメニューは常に必ず確認してください。もし、ディレクトリサービスを使っていれば、ここは「/NetInfo/root」というのが選択されています。これが、ディレクトリサービスによって管理される“場所”を示しており、ファイルサーバを使うユーザはこの場所に登録をしないといけません。一方、ディレクトリサービスを使っていない場合は、「ローカル」に登録をします。

　いずれにしても「ローカル」は存在しますが、ディレクトリサービスを使ってれば、ローカルはそのサーバマシンに直接利用するという意味でのログインユーザなどの管理領域になります。言い換えれば、ディレクトリサービスを使っている時は、「ローカル」「/NetInfo/root」という2つのディレクトリが存在しますが、ファイルサーバのユーザは後者に登録します。

ユーザの登録とグループ

　ユーザやグループは、単に「新規レコード」ボタンをクリックして、作成をします。ファイルサーバのユーザは、「基本」に見えている、名前、ユーザ名、パスワードの2回の入力だけでかまいません。ユーザは管理者にしない方がいいでしょう。AFPサーバにログインするとき、管理者でログインすると、Macのボリュームが全部見えてしまいます。もちろん、管理のためには必要ですが、一般の利用者はかえって不便だし問題があります。管理者の方も、管理用アカウント以外に、一般のアカウントを作っておくのがいいでしょう。

　そして、「詳細」のタブを見てください。ディレクトリサービスを起動してパスワードサーバを使うようになっていれば、パスワードのタイプは「パスワードサーバ」になります。一方、ディレクトリサービスを使用していないと「基本」となります。後からパスワードのタイプを変更する時は、パスワードは再設定されることになりますので、運用を円滑にするにはそういうことがないようにしたいところです。「パスワードサーバ」を選ぶと、パスワードの文字数制限や、パスワードの有効期限の設定など、いくつかの設定ができるようになります。

図　ユーザの「詳細」のタブで、パスワードのタイプを指定する。パスワードサーバを使用していれば、既定値は「パスワードサーバ」となる

図　パスワードサーバを使うユーザは、アカウントについてのオプションを指定できる

　グループについては、名前を設定するだけになります（パネルにある「ユーザ名」は「グループ名」の間違いかと思います）。グループを作ってユーザを登録することも、ユーザの情報として所属するグループを指定することも可能です。どちらでもかまいませんが、いずれの場合も、ボタンをクリックすると、ウインドウの右側にドローワ形式のパネルが出てきて、そこから、ユーザ名あるいはグループ名をドラッグ&ドロップして登録をすることになります。

図　グループの追加とグループへのユーザの登録

　なお、テキストファイルから一括してユーザを登録する場合のポイントもいろいろあるのですが、Passengerというユーティリティを使うのがいちばん楽なやり方かと思います。シェアウエアですが、十分に元が取れるユーティリティと思われます。

http://www.macinmind.com/Passenger/

ファイル共有ポイントの設定

　Mac OS X Serverでは最初からいくつかのフォルダが公開されていますが、おそらく本格的に使う場合には、システムとデータを別々のパーティションにするのが一般的なやり方と思います。公開したいフォルダをあるボリュームにFinderで作ります。そして、そのフォルダを、「ワークグループマネージャ」を使って公開を行います。

　「ワークグループマネージャ」では、「共有」のアイコンをクリックすることで共有ポイントの設定が可能ですが、そのときの左側のタブでは「共有ポイント」の方が選択されていて、すでに共有されているフォルダが一覧されています。ここで「すべて」のタブを選択すると、ログインしているマシンのハードディスク全部が見えるので、ここで、共有したいポイントを選択して、「この項目と内容を共有する」のチェックボックスをオンにします。基本的にこれで共有はOKです。

図　共有ポイントを設定するには、フォルダを選択してチェックボックスを入れる

　しかしながら、通常はほとんどすべての場合で、アクセス権の設定を適切にやらないといけません。所有者、グループ、その他、という区分での設定ができますが、こちらについては、この後に詳しく説明しましょう。

ファイル共有のプロトコルごとの設定

　共有ポイントを設定したら、プロトコルごとの設定も確認します。もし、AFP、Windows、そしてFTPのいずれのサーバ機能も「サーバ設定」でオンにしていたら、共有を開始したすべてのプロトコルで公開されることになります。仮に、あるフォルダはAFPでは公開するけどWindowsとFTPでの公開はしないということであるのなら、ワークグループマネージャで公開したくないプロトコルでの公開をオフにします。

　また、ゲストアクセスについても、やはりチェックは必要でしょう。ゲストアクセスは、「サーバ設定」でのチェックボックスと、「ワークグループマネージャ」での個別の設定ポイントでのチェックボックスの両方がオンになっていないと機能しません。ですから、「サーバ設定」でオフになっているので、既定値はゲストアクセスできません。一方、「サーバ設定」でオンにすると、すべての公開ポイントがゲストアクセスできます。そのため、ゲストアクセスさせたくない共有ポイントの設定をやはり調整しないといけないことになります。

　あと、Windowsには、oplock、strick lockの設定がありますが、これはSambaにある対応した設定と同じです。

図　Appleファイル共有の設定。ゲストや共有名の設定などがある

図　Windowsのファイル共有の設定。Sambaの設定に対応する

　実際のファイルサーバへのアクセス方法、つまりクライアント側の利用方法は、この原稿では割愛させていただきますので、参考書などで調べてください。

アクセス権について

　Mac OS X/Serverでは、従来のMac OSと違って、すべてのファイルにアクセス権が設定されています。Mac OS時代もファイル共有についてはアクセス権が設定されていましたが、Macユーザにとってはあまりなじみがないかもしれません。もちろん、Mac OS Xになっておなじみになりましたが、クライアントのMac OS Xを使う上ではほとんど意識しなくてもいいくらいになりました。しかしながら、ファイルサーバを利用するとなるとどうしても知っておかないといけないことがこのアクセス権です。

　ファイルやフォルダには、「所有者」「グループ」が誰なのかということが必ず記録されます。この情報は、根本的にはID番号（ワークグループマネージャのユーザ登録画面を参照）なのですが、ユーザ名での表示や指定が可能なように必ず動きます。さらに、FinderなどのMac独自のサービスになると、名前とIDとの対応付けを行い、名前の表示や指定も場合によってはできます。

　そして、所有者、グループ、その他に対して、「読み込み」「書き込み」「実行」の3つの操作を許可します。ファイルやフォルダに対して何かをしようとしたユーザが所有者なら所有者に定義された操作範囲、グループに含まれているならグループに定義された範囲、いずれでもないのならその他のユーザに対して定義された範囲の処理ができるという風にチェックが行われます。なお、Finder上では、3つの状態を個別に行うのではなく、実行の設定を省いた選択肢がポップアップメニューで用意されています。

図　マウントした共有フォルダ。htanakaフォルダは読み込みしかできないので、ウインドウの左上にペンを斜め線で消したアイコンが表示される。tkitajimaフォルダは、読み込みの権限もないので、立ち入り禁止の赤いマークがアイコンに見える

図　Finderで見たアクセス権。このサーバへは、todaというアカウントでログインしているため、自分が所有者の項目についてのみ、アクセス権だけが選択できる

　これらのアクセス権の情報については、Finderで参照したり一部の書き換えはできますが、変更できない設定もあります。Mac OS X Serverでアクセス権を設定したり管理する場合は、必ずワークグループマネージャを使うか、シェルからコマンドを入れてください。

図　ワークグループマネージャで、共有ポイントだけでなくフォルダやファイルのアクセス権設定を行う

新しいファイルやフォルダのアクセス権

　ここで新しくファイルやフォルダを作る場合にアクセス権がどうなるのかということが2通りあります。設定はワークグループマネージャの共有ポイントのプロトコルの設定にあって、1つは「標準UNIX特性」、もう1つが上位と同じアクセス権を割り当てるとういものです（図xx）。AppleShare IPまでにおなじみの場合は、どちらかと言えば後者がそのときの動作と思ってください。一方、Mac OS X Serverは標準UNIX特性が既定値となっています。

　UNIXでは、umaskという動作のパラメータが重要です。パラメータ自体はもちろん変更は可能ですが、通常はある設定で固定的に使います。このumaskは、新しいファイルやフォルダを作った時のアクセス権を変更するパラメータであるとも言えます。

　Mac OS X Serverに接続して新しいファイルやフォルダを作った時、次のような規則でアクセス権が設定されます。本来は細かく動作があるのですが、ここではFinderやアプリケーションからの見方として、要約して記載します。

• 所有者は、そのファイルを作ったユーザ。Finderやワープロなどのアプリケーションで作ったファイルなどはそのアプリケーションの実行ユーザなので、通常はログインしたユーザ。
• グループは、そのファイルやフォルダの上位のフォルダに指定しているグループ。
• 所有者は読み書きが可能
• グループ、全員には読み込みが可能

　ファイルやフォルダを作成できるときには、そのときのユーザに対してフォルダへの書き込み権限があるはずです。そして実際にファイルないしはフォルダは作成され、所有者とグループは上記のように決められますが、読み書き権限において、グループの書き込み権限が落とされるというところがいちばんの特徴です。これはumaskパラメータによって落とされるのです。上位の権限を引き継いだらもしかしたらグループも書き込み可となるかもしれませんが、標準UNIX特性ではそうではなく書き込み権限は落ちます。

　なお、「その他」の権限についても同様に書き込みできなくなりますが、ファイルサーバの場合は一般にはその他に対しても書き込み可とすることは、不特定多数に書き込みをさせることでもあり、セキュリティ的にはあまり望ましい状況とは言えませんから、もともと、読み込みしかできないようにしておくでしょう。

図　マウントしたボリュームのグループplannningには読み書きが可能となっている

図　前の図の状態で、planningに所属するwakanaというユーザが新たにフォルダを作った。そのフォルダの所有者はwakanaになるが、グループはplanningが引き継がれているもののグループに対しては読み込みのみとなる

ファイルサーバ利用者から見たアクセス権

　Finderの表示にもあるように、利用者からは「読み込みのみ」「読み／書き」「アクセス不可」のどれかになります。もちろん、実行の有無もあるのですが、そうしたシステムのすべての状況を見せるのではなく、ユーザにとって必要な状況だけを呈示するのがMacのコンセプトです。フォルダに対しては「書き込みのみ」の設定もできますが、やや特殊と思われるので、ここでの検討では省略します。ここで、アクセス権の設定と、なにができるのかを表にまとめました。

　ここで、いちばん気をつけないといけないのは、ファイルの上書き保存などでの▲です。これは、そのファイルが存在するフォルダのアクセス権で書き込み可になっていれば、ファイルが読み込みしかできなくても上書き保存はできてしまうのです。具体的にはグループに対して書き込みが設定された公開ボリュームで、誰か別の人がファイルを作ったとします。そのとき、そのファイルは、別の人にとってはおそらくは読み込みしかできないはずですが、開いて上書き保存ができます。つまり、中身を書き換えることができます。ただし、何の警告もなく保存することはしませんが、いずれにしてもファイルの修正はできてしまいます。そうして書き換えたファイルの所有者は保存をした人になります。

図　あるユーザtodaが作成したファイルは、別のユーザwakanaに対しては「読み込み」しかできないはず。だが、wakanaは開いてこのように「上書き」保存ができる

図　上書きした結果、もともとは所有者はtodaだったが、それが上書きをしたwakanaが所有者になった

　同じように、その項目を含むフォルダに対して書き込みのアクセス権があれば、上書きや移動ができてしまいますが、上書きに関しては、そのフォルダの中にファイルがあると、そのファイルのアクセス権が影響しますので、必ずしも上書きができるとは限りません。しかしながら、読み込みのみ、あるいはアクセス権がないフォルダを上書きして置き換えてしまうことができる場合があるということです。

　また、フォルダやファイルに対して、読み込みの権限しかない場合でも、その項目を含むフォルダに対して書き込みの権限があれば、名前を変更することまでできてしまいます。

　理屈をあえて付けるとしたら、フォルダというもの自体が内部的にはファイルで管理されていると考えるしかないでしょう。つまり、ファイル自体へのアクセス権がなくても、そのファイルを含むフォルダの管理ファイル側にアクセス権があれば、管理情報、つまり名前やその名前が指し示す先のファイルといった情報は書き換える〜つまり上書きができるという風に考えられるわけです。しかしながら、後で説明するように、Mac OS 9までの動作や相互運用とのかねあいでこうした動作になっているのではないかと思われます。

　こうした動作はUNIXでシェルを使った時などには基本的には見られません。UNIX的なやり方としてグループの権限を単に落として何もできなくすると、かえって不便になるというのは確かにあるかもしれません。それを考慮しての、ある種の利便性を考えた機能であることになるのですが、いずれにしてもこうした点を考慮してのアクセス権設定が必要になります。

　よくあるのは、ファイルサーバのすべての利用者を含めたグループを作り、公開フォルダのグループにそのグループ名を設定して、グループの書き込みを許可するという方針です。そうなると、そこにあるファイルは、誰にでも上書き保存されてしまいます。もちろん、それもアリということをよく周知させての運用で、一時的な置き場とかに使うというのであればかまいません。そのとき、みんなに参照はさせてもいいけど、書き直されては困るというファイルは、ともかくその公開ボリュームにフォルダを作り、そこに入れます。フォルダを作った人だけがファイルを追加でき、そのファイルはその人しか修正はできなくなりますが、作ったフォルダのグループの書き込みは不可だからです。それでも名前を変えることはできてしまいます。こうした運用のやり方を、うまくオフィス内で浸透させるということが必要になります。どいうしても他人に書き込まれては困る場合には、グループは読み込みのみにすることになり、結果的には書き込みができる人ごとに公開フォルダを作るということになるでしょう。

ローカルにログインしてサーバに接続した場合

　しかしながら、多くのサイトでは、ローカルのMac OS Xにログインして、別途サーバ側に発行した別のアカウントで、「サーバへ接続」などを行ってサーバに接続し、マウントして利用をします。そのとき、ローカルへログインするアカウントと、サーバに接続するアカウントはまったく別のものです。仮に同一名としても、アカウントのデータベースは、異なるものを使っているので、つまりは異なる認証空間（ドメイン、あるいは場所と言ってもいいでしょう）が混在した利用になります。こうした状況については、TILの107485「権限のマッピングとそれが使用される条件について」で詳しく解説されています。

　文書および実際の動作を見る限りでは、こうした利用の場合は、ローカルのアカウントのユーザ名と、サーバ側のアカウントのユーザ名は異なる名前にしておく方が、結果は予測しやすいということがあります。

　サーバ側で公開した/Volumes/data/FileServerというフォルダですが、次のように、adminが所有者で、plannningがグループです。所有者とグループは読み書き可能、その他は読み込みのみになっているとします。

drwxrwxr-x 6 admin planning 204 Sep 21 09:28 .

　このフォルダの中身をサーバ上で見ると、次のように、tkitajimaやwanaka、todaというplanningグループの中に含まれるメンバーが所有者となっているファイルやフォルダがあります。

drwxr-xr-x 3 tkitajim planning 102 Sep 20 23:39 test
drwxrwxrwx 4 wakana planning 136 Sep 21 09:24 test2
-rw-r--r-- 1 toda planning 16 Sep 21 09:19 List by toda.txt
drwxr-xr-x 4 toda planning 136 Sep 21 09:28 MyFolder

　以上は、サーバ上のアクセス権を、ターミナルで直接見たもので、その意味では、設定されているアクセス権と言えます。

　このサーバに対して、msykという名前でローカルにログインしたMac OS Xから、tkitajimaという名前でサーバに接続します。サーバにはmsykというユーザ名のユーザは存在しません。もちろん、tkitajimaにアクセス権があるのでログインできますが、クライアント側から見た、マウントしたボリュームのアクセス権は、次のようになります。つまり、「ローカルにログインしたユーザ」が所有者になるところがポイントです。

drwxr-xr-x 6 msyk unknown 264 Sep 21 09:28 .

そして、マウントしたポイントの中身ですが、クライアントから見れば、次のようになります。やはり、所有者が「ローカルにログインしたユーザ」であるmsykになっています。

dr-xr-xr-x 3 msyk unknown 264 Sep 20 23:39 test
drwxrwxrwx 4 msyk unknown 264 Sep 21 09:24 test2
-rw-r--r-- 1 msyk unknown 16 Sep 21 09:19 List by toda.txt
drwxr-xr-x 4 msyk unknown 264 Sep 21 09:28 MyFolder

　Mac OS Xの背後ではtkitajimaというアカウントでサーバを利用しているので、実際のアクセス権は、tkitajimaのものと同一ではあります。しかしながら、クライアントで使っているユーザから見れば、そのクライアントにログインしたユーザ名で使っているかに見えるというわけです。そして、所有者は常にクライアントにログインしたユーザになり、グループ設定は意味を持たない状況になります。そして、読み書きなどのアクセス権については、実際のアクセス権から合成をして、実際の状況をクライアント側で表示をします。つまり、元のファイルのグループやその他のアクセス権を考慮して、現在接続しているユーザが可能な処理をクライアント側の所有者のアクセス権に集約させるというわけです。事実上、クライアント側では所有者のアクセス権しか意味を持たないと言えるでしょう。

　なぜこのようなことをしないといけないのか？　1つは、サーバとクライアントでアカウント情報が異なると、グループという概念に意味がないということがまずあります。そして、Mac OS 9などのアカウントという概念のないクライアントからのアクセスを考慮したものとも考えられます。

　「List by toda.txt」というテキストファイルのアクセス権を見てください。サーバに登録したアカウントでログインをした場合、もちろん、todaが作ったファイルとなっていますが、それを含むフォルダのグループに書き込み権限があったので、上書き保存ができることを前に示しました。それでは、サーバとクライアントが異なるアカウント情報でログインした場合は、上記の結果を見れば一目瞭然のように、「List by toda.txt」というファイルは開いて保存ができ、しかも以前の例で示した場合と違って上書きするかどうかの確認ダイアログボックスは出てきません。つまり、クライアント側に示されているように、クライアントにログインしているmsykに対して書き込み権限が与えられています。つまり、サーバ側のアクセス権設定が合成されて所有者に書き込み可が与えられています。

　こうしたアクセス権のマッピングの処理については、賛否はあるかと思いますが、ともかくこうした状態がデフォルトになっているとういことを知った上でのシステム設計が必要になるでしょう。事実を受け入れることが重要かと思います。

　なお、上記のようにコマンドの出力結果を出しましたが、Finderで見ると、実はまた違っています。Finderでは事実上正しく表示されません。たとえば、上記のList by toda.txtというファイルの所有者はグループは、toda/plannningと表示されます。これは正しいのか、正しくないのか、難しいです。サーバから見れば正しいのですが、クライアントにマッピングした結果ではありません。つまり、システム的にはマッピングした置き換えた結果で解釈するにも関わらず、Finder側ではサーバ上の正しいアクセス権を表示しているのです。これも心しておくところでしょう。また、再現性が低いのでどんな場合に出るかは分かりませんが、Finderで所有者名などが文字化けしていることも稀に見られます。

Mac OS 9からのアクセス

　ここまで話が蓄積されて、やっとMac OS 9の話ができます。Mac OS 9はOSにアカウントを設定しませんので、純粋にサーバ側のアカウントでログインします。そのため、置き換えなどは基本的には行われず、サーバ側のアクセス権がそのまま反映されます。しかしながら、サーバ側で標準UNIX特性を選択していても、新しいフォルダを作った時には、上位のフォルダの設定をそのまま引き継ぎます。

　一方、Mac OS 9では、ファイルサーバ内のファイルは、それを含むフォルダのアクセス権をそのまま踏襲しますので、ファイルに対してのアクセス権はフォルダのものがそのままやって来ます。

図　Mac OS 9でログインして作成したフォルダのアクセス権。上位のアクセス権を引き継ぐ

　標準UNIX特性という設定で、UNIXのアクセス権設定を行いながらも、これまでのMac OSでのファイル共有のアクセス権との互換性、あるいは相互運用ということを考慮したものが、前に説明した「上書きはできる」という設定なのです。つまり、Mac OS XですっかりUNIXにするのではなく、Mac OS 9までの使い勝手を残しつつ、よりUNIXライクに移行したアクセス権設定が行われていると言えるでしょう。

ファイル名として使えない文字

　最後にクロスプラットフォームで使う場合にファイル名で気をつけたい文字を紹介しましょう。まず、以下の表の文字ですが、次のような症状になります。いずれにしても、Windows XPとMacとのやりとりではファイル名としては付けない方がいいようです。全角ニョロや全角マイナスあたりは良く使ってしまいそうですから注意しましょう。

Mac OS X/Mac OS 9でファイル名設定→Windows XPでは見えない。見えても開けない、あるいは開いてもなにもない。

Windows XPでファイル名設定→Mac OS Xでも参照でき利用できる。ただし、同じ〜でも、Mac OS XはUnicodeでのコードが301CのWAVE DASH、Windows XPではFF5EのFULLWIDTH TILDEを割り当てるためファイル一覧では別々の項目として扱われる。Mac OS 9では#と数字に置き変わるが、ファイルとして扱えない場合がある。

　また、以下の文字は、Windows XPではファイル名としては使えないキャラクタです。これらの文字を使ってMacでファイルを作成すると、Windows XP側では見えなかったり、フォルダだけが見えたり、あるいは化けたような文字になるなどの支障が出てきます。

　いずれにしても、上記の表は単純な意味で「使ってはいけない文字表」となります。ですが、Windowsはバージョンによって若干異なるので注意をしましょう。上記は、Mac OS X Server 10.2.6、Mac OS X 10.2.6、Mac OS 9.2.2、Windows XP Professionalでの状況です。

　いろいろなソースを調べてみましたが、JISコードの815D（‐）の文字は、上記の環境では問題ないようです。また、「外字はダメ」と思いたいところですが、丸数字の?やカッコ株の?については、ファイル名としては問題なくクロスプラットフォーム対応しています。上記のような環境では、どのプラットフォームでも?のShift_JISのコードは8740で共通だからです。ただ、ファイル名をコピーして、ワープロなどにペーストしたら化ける場合などもありますが、いずれにしても、各OSの最新版については、昔の「98外字」の不一致問題は解決されているようです（それでもWebで文字化けするのはツールやブラウザ、フォントの問題となります）。むしろ、〜や−といったUnicodeのマッピングが違う文字の問題が大きいようです。それから、TIL #25546には、‖などの文字を含んだ場合、Mac OS 9でファイル名が正しく表示されないとされていますが、上記のような環境ではMac OS 9.2.2では問題なく表示されています。

効果的なサーバ運用のために

　やはりサーバの運用としては、どんなフォルダを公開し、その中にどのようにアクセス権を設定したフォルダを作るかといった設計の問題になります。それは、会社やオフィスでの業務に密着した問題です。試行錯誤をしてもいいのですが、こうした動作のポイントをつかんで、安全かつ便利なセキュリティ設定をするというのがとにかくポイントになります。