この項では、エラーメッセージを伴うとはかぎらないさまざまな問題を解決する方法について説明します。
サービスパック 3 (SP3) をインストールした Windows NT 4.0、または Windows 98 では、TAS 認証エラーが発生します。ユーザーが TAS サーバーの共有ボリュームを表示したり、TAS ボリュームに接続しようとすると、次の TAS エラーが表示されます。
Incorrect password or unknown username for ¥¥serverName. |
このエラーは、ユーザーが適切な UNIX ユーザー名とパスワードを使用している場合にも発生します。
Windows NT 4.0 + SP3 および Windows 98 のクライアントは、デフォルトでセキュリティ認証を使用します。PC と TAS サーバーは、「チャレンジ・応答」交換を行うことにより、パスワードそのものをネットワーク上に送信しなくても、パスワードの有効性を確認できます。
クライアントは、パスワードを使用して、サーバーから提供された無意味な文字列をコード化し、その結果をサーバーに返します。サーバー側でもこれと同じコード化を行い、そこで無意味な文字列が一致すれば、クライアントは認証されます。
このような認証スキームをサポートするために、TAS は UNIX のパスワードファイルとは別のプライベートパスワードファイルを必要とします。セキュリティ認証を可能にするには、TAS のプライベートパスワードファイルに UNIX のユーザー名とパスワードを登録しておかなければなりません。
TAS のセキュリティ認証を可能にし、上記のエラーが発生しないようにするための手順を次に示します。
「TNAS TAS Administration and Configuration」 スフィアアイコンをクリックして、「TAS administration and configuration」 オプションを表示します。
「LM-NT-OS/2 Realm」 をクリックします。
「LM-NT-OS/2 Realm」 パネルで、「Manage File Services->」 をクリックします。
目的のファイルサービスを選択して、「Administer」 をクリックします。
次に表示される画面で、「Authentication and Service Mode Options」 をクリックします。
「Local authentication」 を有効にして、「Submit」 をクリックします。
「Password encryption」 を有効にして、「Submit」 をクリックします。
「OK」をクリックします。
TAS のプライベートパスワードファイルにエントリを設定するには、TAS フレームの次のリンクをたどります。
「Passwords」 -> UNIX ユーザー名を入力 -> 「Create」
TAS のプライベートパスワードファイルにユーザー名を入力するには、有効な UNIX アカウントを持っていなければなりません。
フォームが表示されるので、このユーザーのパスワードを入力し、確認のために再入力してから「Submit」 をクリックします。これで、このユーザーが正しく認証されるようになります。
TAS のセキュリティ認証を必要とする UNIX ユーザーごとに手順 7 〜 9 を繰り返します。
TAS クライアントには、Solaris プリンタが使用可能であるように表示されます。Solaris プリンタがマウントでき、印刷ジョブも Solaris プリンタにスプールされたように見えますが、実際にはジョブが印刷されません。
TAS の PC クライアントが Solaris プリンタで印刷できるようにするには、次の手順に従って TAS の構成を変更しなければなりません。
TNAS のメインメニュー (左フレーム) で、「System」 をクリックします。
「System Configuration and Administration」 メニュー (右フレーム) で、「Printers」 をクリックします。
変更する Solaris プリンタを選択して、「Modify」 をクリックします。
「Spooler Options」 ボックスに -c と入力して、「Submit」 をクリックします。
これで、印刷ジョブが Solaris プリンタで印刷できるようになります。
次のいずれかの理由で、ユーザーが TAS ホスト上のアプリケーションを実行できません。
アプリケーションファイルのアクセス許可により、ユーザーのアクセスが拒否されています。アプリケーションが入っているディレクトリの所有者または root でログインして、各レルム ->「Manage File Services」-> [サービスを選択] ->「Administer」->「Configuration」->「Umask」というリンクをたどるか、tnservice コマンドを使用して、アプリケーションファイルのアクセス許可を変更します。DOS プログラムには UNIX の読み取り許可が必要なことに注意してください。
アプリケーションの属性で DOS に指定しているドライブ名と、リダイレクトされたドライブが使用するドライブ名が一致していません。
ネットワークドライブ上のプログラムを Windows の DOS プロンプトウィンドウでコンパイルすると、データが壊れたり接続が切れたりします。Windows for Workgroups と Windows 3.1 を稼動する PC では、Windows の system.ini ファイルの [386Enh] セクションに次の行を追加してください。
InDOSPolling=True
ネットワークボードによっては、複数のケーブル接続を持つものと、トランシーバを持つものがあります。物理的なハードウェアジャンパ設定がソフトウェア設定と同じ接続方法を使用できることを確認してください。
ユーザーがクライアント PC の電源を切ったりリブートしたりすると、ネットワーク接続が切れます。これがデータ転送中に起こった場合、TAS はただちにその状態を検出して関連プロセスを終了します。ところが、クライアントとサーバー間にトラフィックが存在しないときは、TAS がセッションの切断を検出するのに数分かかります。タイムアウト値はホストシステムによって異なりますが、通常は 5 分程度です。TAS はタイムアウトが発生してから関連プロセスを終了します。
デフォルトでは、TAS はホストのトランスポート層のキープアライブ機能を使用して、セッションがアクティブかどうかを調べます。telnet などの別のアプリケーションでアクティブでないセッションが終了しない場合は、トランスポートのベンダーがキープアライブ機能を提供していないことが考えられます。その場合は、各レルム ->「Manage File Services」-> [サービスを選択] ->「Administer」->「Configuration」というリンクをたどるか、tnservice を実行して、NetBIOS のキープアライブを使用するように TAS を構成しておきます。
PC クライアントがセッションを終了する (つまり、リダイレクトしたドライブを切断する) と、関連プロセスは通常の手順でセッションを終了しようとします。このとき、name.number というファイルを $TNHOME/TAS/tn/tndb ディレクトリから削除しようとします。ここで、name はクライアント PC のマシン名、number は関連プロセスの UNIX ID 番号です。
クライアントがこのファイルを削除できなければ、ファイルは存在したままとなり、エラーメッセージが表示されることはありません。この状態で接続状態を調べるか、tnwho や tninfo コマンドを実行すると、終了したはずのクライアントが接続中と表示されます。この問題が起こったときは、回線ディレクトリからエントリを削除する srm プログラムの所有者が totalnet であること、srm のモードが 4511 であること、totalnet が回線ディレクトリを所有していること、さらに回線ディレクトリのモードが 755 であることを確認してください。
ある種の DOS コマンドの動作が正常でない場合は、次の原因が考えられます。
ユーザーがルートディレクトリに対して書き込み権限を持っていないネットワークドライブは、DOS のパイプ機能 (| が含まれるコマンド) をサポートできません。これは、DOS のパイプ機能が、カレントドライブのルートに一時ファイルを作成しようとするためです。
edlin のような DOS アプリケーションは、ファイルを更新するときに一旦削除して書き直します。そのファイルが UNIX ファイルにリンクしている場合は、リンクが削除され、独立した新規ファイルに変わってしまいます。
DOS コマンドの中には、そのコマンドからのエラーメッセージとは思えないメッセージを返すものがあります。たとえば、DOS の type コマンドは、サーバーから Access denied というメッセージを受け取ると、Invalid path or filename: というメッセージを表示します。これは、DOS からはアクセスできないファイルに対して type コマンドを実行した場合のメッセージです。サーバー上のデバイス名、パス名、ファイル名が正しいかどうか、またユーザーがそのファイルにアクセスするための権限を持っているかどうかを確認してください。
クライアント PC がリブートするとファイルロックが解除されないために、ファイルのロックとアンロックが適切に実行されないことがあります。ロックを解除するには、tnck を実行します。
クライアント側のディスクの空き容量の計算には限界があります。DOS は、ディスクデバイスがネットワークドライブを割り当てたものかローカルなものかに関係なく、64 キロバイト以上のクラスタサイズを持つドライブには対応していません。大規模な UNIX システムや、何台もの CD-ROM ドライブがマウントされたマシンでは、4 ギガバイトを超えるドライブが使用されています。DOS は、そのような大きさのドライブを扱うことはできません。
NetBIOS を起動できないときは、すべての NetBIOS プロセスが完全にシャットダウンしているか確認してください。TAS サービスをシャットダウンした後も実行されている NBname プロセスや NBdaemon プロセスを見つけるには、ps コマンドを実行します。この問題は、プロセスが正常に終了しなかった場合にだけ起こります。UNIX の kill コマンドを使用して問題のプロセスを終了してから、「4.1.1 TAS サービスの開始」に示す手順に従うか tnstart コマンドを使用して、TAS サービスを再起動してください。
ネットワークで割り当てたドライブ間のファイルのコピー、ネットワークを使用した印刷ジョブ、リモートコマンドの実行があまりにも遅い場合は、次の原因が考えられます。
ネットワークセグメントの負荷が過剰です。ネットワークを設計し直して負荷を軽減してください。
ネットワークで生成されるブロードキャストが多すぎます。LAN をいくつかの小さいセグメントに分割することを考慮してください。
NFS が非常に多くのネットワークトラフィックを生成しています。リモートファイルシステムが NFS マウントに大きく依存している場合は、リモートホストのいくつかに TAS をインストールしてください。クライアントが TAS ホストに接続し、そのファイルサービス要求が NFS 接続を通して別のコンピュータにルーティングされると、クライアントが目的のコンピュータに直接接続する場合の倍のネットワークトラフィックが発生します。
TCP パケットバッファまたはウィンドウサイズを変更する必要があります。クライアント側での変更方法は、インストールされている TCP/IP 製品によって異なるため、クライアント側の TCP/IP マニュアルを参照してください。TAS では、tntransport コマンドを実行して、recvbuf と sendbuf の属性値を調整します。
次の原因が考えられます。
構成ファイルで行っているソフトウェア設定と、物理的なハードウェア設定に矛盾があります。どちらかを変更して両方の設定を一致させてください。
ifconfig コマンドで設定したアドレスが間違っています。ネットワークマスクと、送信および受信用の IP アドレスを確認してください。
ターゲットの IP アドレスが無効であるか、TCP スタックが実行されていません。ターゲットのコンピュータが正しく機能しているか確認してください。
ネットワークコネクタを 2 つ持つネットワークカードで、ソフトウェアと異なるタイプのネットワークコネクタが使用されています。ハードウェアまたはソフトウェアの設定を変更して、正しいコネクタを使用してください。
ネットワーク上でターミネータが不足しています。ネットワークの末端にターミネータを装着してください。
次の原因が考えられます。
ネットワークドライバがロードされていません。クライアント側で Windows 設定プログラムを実行して「Network」オプションをチェックし、正しいネットワークドライバがロードされていることを確認してください。
UNIX スプーラは、Windows for Workgroups と Windows 3.1 クライアントから送られた PostScript ファイルを正しく解釈できません。PostScript ファイルを印刷する場合、クライアントは "CTRL-D" を先頭の文字として送信します。UNIX スプーラはこのコードを処理できないので、印刷処理を終了してスプールファイルを削除してしまいます。この問題を解決するには、クライアント側で Windows の win.ini ファイルの [PostScript Printer LPT1:] セクションに次の 1 行を追加します。
CTRL-D = 0:
DOS アプリケーションによっては、プログラムを終了しないと印刷ジョブが送信されないことがあります。これは、PC が印刷ジョブをバッファリングして、アプリケーションが終了するまでスプールしないためです。