背景
「ローカルシステムアカウント」で実行されているWindowsのサービスは、システムによってネットワークアクセスが制限されています（下にあるサービスのプロパティ画面を参照してください）。
ここで問題となるのは、アカウント、パスワード、あるいはサービスを開始するタイミングではなく、「ローカルシステムアカウント」で実行されているサービスはネットワークドライブが見られないようにシステムによって制限されていることです。これは、Windowsの仕組みです。
安全性を保ちながらネットワークドライブの読み取り、書き込みを行うには、異なるユーザアカウントで実行しなければなりません。その上、Windowsのセッションからローカルドライブとして何をマッピングできるかは、そのサービスが検出できる内容とは関係ありません。その理由は、サービスが全く異なるユーザ環境で実行されているためです（例えば、自分がログインする前に複数のアカウントが同時にログインしていて、そのサービスが「ローカルシステムアカウント」で実行されている状態を考えてみてください）。
この問題を回避する方法はいくつかありますが、複雑なものが多く、信頼性が低いかいろいろな点で扱いにくいかのどちらかです。FirstClassを実際にご利用のお客様は、さまざま方法でこの問題に対処しており、FirstClassサーバをWindowsサービスとして実行しないようにしているお客様もいます。
8.3での直接マッピングへの対応
このサービスの問題を解決する最善の方法は、管理者から与えられた証明書を利用して、ネットワークドライブを直接マッピングすることです。
FirstClass8.3では、Windows版FirstClassサーバが、volumes.cfgファイルをFCServerフォルダ内に（FCS.exeとともに）保存するという方法でこのマッピング方法を直接サポートします。
これは、現時点ではサーバボリュームにとって必須要件となっている（ドライブ文字などの）物理的制約をサーバが受けないようにするための長期的な取り組みの第１歩です。volumes.cfgの書式例は、下の項を参照してください。
この方法は、Windowsのサービスが抱えるやっかいな問題を一気に解決するだけでなく、他のプラットフォームでも有効です。したがって、Mac OS X版サーバとLinux版サーバでも同じようにボリュームをマウントできる機能を搭載する予定ですが、今のところ8.3では対応していません。Mac OS Xにはいくつかの解決策があり、Linuxでも同様にスクリプトを使った簡単な解決策を取ることができます。
volumes.cfgの利用
この設定ファイルは、キーワード＝値という書式で記述された簡単なテキストファイルです（Windows INIファイルや、inetsvcs.cfファイル、サーバのNETINFOファイルと同じような書式です）。
FirstClassサーバで利用できるようにボリュームを自動的にマウントするには、初めに［Config］セクションを作成しなければなりません。現在、２種類のキーワードをこのセクションで使用できます。
・最初の［Config］キーワードは、Mountsです。これは、マウントするボリュームの数を表します。例：Mounts=2
マウントするドライブごとに、［MountN］セクションを記述してください。「N」はマウント番号を表し、１から開始します。上記の例では、［Mount1］および［Mount2］となります。各セクションに、マウントするボリュームのリモートのUNCパス、ローカルマウントポイント（ドライブ文字）、およびリモートサーバのユーザIDとパスワードを記述してください。
・２番目の［Config］キーワードは、Primaryです。これにより、ネットワークストア用のプライマリボリュームが、実行ファイルのあるフォルダとは異なるボリュームであることをFirstClassサーバに認識させることができます。この設定によって、FirstClassサーバをローカルボリューム上でWindowsサービスなどから起動し、起動後に任意のボリュームをマウントして、ネットワークストア用プライマリボリュームとして利用できるようになります。
［Volumes］セクションはオプションで、ほとんどの場合必要ありません。これによって、FirstClassの名前を上書き（指定）して、マウント対象のボリュームで使用できるようにします。この名前は、管理者デスクトップの［Volumes］フォルダのリストに表示されます。プライマリボリュームは、「Master」（Mac OS X）または「master」（Linux）という名にしなければなりません。この名前は、Windows用のファイル例にある［Volumes］セクションでも使用されています。
書式は、ボリューム名＝マウント名です。
「=」の前には、使用するボリューム名を記述します。「=」の後のドライブパスには、その後に続く［Mount］セクションにある対応マウント名（またはローカルドライブのパス）を記述します。［Volume］セクションはPrimary=オプションを指定しない限り必要ありませんが、その場合は、指定したボリューム名がマウント後に利用できる状態でなければなりません。
volumes.cfgファイルの例
[Config]
Mounts=2
Primary=Master
[Volumes]
Master=F:\
[Mount1]
Mount=\\server\firstclass
MountAs=F:
User=server\me
Password=secret
[Mount2]
Mount=\\server\mirror
MountAs=M:
User=server\me
Password=secret
このファイル例では、色分けをして記述内容どうしの相互関係がわかりやすくなるようにしています。例えば、
・Mounts=2は、サーバに対してMount1とMount2の２つのMountセクションを探すよう命令していることを表しま
す。
・Primary=の行に指定されているボリューム名は、［Volumes］セクションに記述されていて、そこで指定されている名前（Master）と一致していなければなりません。
・Windowsでは、ボリュームのパス（F:\）をMaster=の行に続けて記述し、マウント名に対応させます。
この例では、サーバファイルサーバから２つのネットワークボリューム（firstclassとmirror）を、それぞれFドライブ、およびMドライブとしてマウントしています。
また、Primaryによって、サーバに対して（Fドライブとしてマウントされている）\\server\firstclass下にあるプライマリのFCNSフォルダを探すよう命令を出しています。これにより、プライマリのネットワークストアに含まれるボリュームとは異なるディスクボリュームからコアサーバを起動できます。これは、Windowsのサービスにとって最も効果的な設定です。その
理由は、FirstClassサーバをWindowsのボリュームにインストールする一方で、マウントしたネットワークボリュームをネットワークストア用のプライマリボリュームとして利用できるためです。
 注意Windowsでは、任意のサーバから任意のマシンにマッピングするすべてのドライブで同じ資格証明書を使用しなければならないという制限があります。
User部分で認証ドメイン（通常はファイルサーバ名）を指定して\を付け、その後にユーザIDを指定してください（上の例を参照）。
| 
