File Storage NAS:ファイル読み書きアクセスの問題のトラブルシューティング

同時ファイルアクセス中のサーバー無応答

原因：この問題は、Linux SMB カーネルドライバーのバグが原因で発生します。SMB 2.1 または 3.0 を使用してファイルシステムをマウントすると、一部の同時アクセスシナリオでクライアントが期待される SMB BreakAck パケットを送信できず、サーバーが 35 秒間応答しなくなることがあります。

ソリューション 1：SMB 2.0 を使用してファイルシステムをマウントします。

ソリューション 2：次のステップに従います。

1. 次のコマンドを実行して、CIFS モジュールをロードする際に便宜的ロック (oplocks) を無効にします。

   # modprobe cifs enable_oplocks=0

2. 次のコマンドを実行して、CIFS モジュールがロードされた後に便宜的ロック (oplocks) を無効にします。

   # echo 0 > /sys/module/cifs/parameters/enable_oplocks

3. 次のコマンドを実行して、便宜的ロック (oplocks) の状態を確認します。

   # cat /sys/module/cifs/parameters/enable_oplocks

   出力では、Y は有効、N は無効を示します。

   説明

   • 変更を適用するには、SMB ファイルシステムをアンマウントしてから再マウントします。

   • 変更を永続的にするには、/etc/modprobe.d/cifs.conf ファイルを作成し、options cifs enable_oplocks=0 の行を追加します。

シンボリックリンクの作成不可

原因

SMB ファイルシステムが、mfsymlinks オプションなしで、またはプロトコルバージョン 2.0 を使用して Linux にマウントされたためです。

ソリューション

Linux に SMB ファイルシステムをマウントする際は、プロトコルバージョン 2.1 または 3.0 を使用し、mfsymlinks オプションを追加します。マウントコマンドの例は次のとおりです。例のパラメーターの説明については、「SMB (Linux) マウントコマンドのパラメーターの説明」をご参照ください。

sudo mount -t cifs //file-system-id.region.nas.aliyuncs.com/myshare /mnt -o vers=2.1,guest,uid=0,gid=0,dir_mode=0755,file_mode=0755,mfsymlinks,cache=strict,rsize=1048576,wsize=1048576

SMB マウントポイントの無応答

原因

3.10.0-514 より前のカーネルを持つ Linux ディストリビューションでは、SMB カーネルドライバーが同時アクセスシナリオでクラッシュし、マウントポイントにアクセスできなくなることがあります。カーネルログには、次のようなメッセージが含まれます。

...
[<ffffffffc03c9bc1>] cifs_oplock_break+0x1f1/0x270 [cifs]
[<ffffffff810a881a>] process_one_work+0x17a/0x440
[<ffffffff810a8d74>] rescuer_thread+0x294/0x3c0
...

ソリューション

• cache=none オプションを使用してファイルシステムを再マウントします。これはパフォーマンスに影響を与える可能性があります。

• Linux を実行している Elastic Compute Service (ECS) インスタンスのオペレーティングシステムをアップグレードします。

大きなファイルのコピー時の "Bad file descriptor" エラー

原因

この問題は、一時的なネットワークまたはバックエンドの障害により発生します。SUSE などの一部の Linux ディストリビューションの SMB クライアントは、この種のフェイルオーバーに対するサポートが限られています。

ソリューション

次の表に、NAS SMB に推奨される Linux オペレーティングシステムのバージョンを示します。

クライアントでの中国語文字の文字化け

現象

Linux クライアントから NAS ファイルシステムに中国語文字 (ファイル名やファイル内容など) を書き込むと、Windows クライアントで文字化けして表示されることがあり、その逆も同様です。

原因

デフォルトでは、Windows クライアントは中国語のエンコーディングとデコーディングに GBK 文字セットを使用し、Linux クライアントは UTF-8 文字セットを使用します。各プラットフォームは独自の文字セットを使用してデータをエンコードします。一方のプラットフォームで書き込まれたデータをもう一方のプラットフォームで読み取ると、互換性のない文字セットがデコーディングの失敗を引き起こし、内容が文字化けして表示されます。

ソリューション

プラットフォームの互換性の問題を避けるために、Windows クライアントには SMB 経由で、Linux クライアントには NFS 経由で NAS ファイルシステムをマウントすることを推奨します。

NFS を使用する Windows でのファイル操作の低速化

原因

Windows では、NFS は大文字/小文字を区別するセマンティクスと区別しないセマンティクスの間で互換性の問題があります。ディレクトリサイズが大きくなるにつれて、ディレクトリ内のファイルを作成するパフォーマンスが大幅に低下します。これは、ファイルを作成するたびにディレクトリをトラバースする必要があるためです。ディレクトリに約 100,000 エントリが含まれている場合、1 回のディレクトリトラバーサルに 10 秒以上かかることがあります。

ソリューション

マウントパラメーターを変更し、-o casesensitive=yes オプションを追加してディレクトリトラバーサルを回避します。次のコマンドは例です。

mount -o nolock -o mtype=hard -o timeout=60 -o casesensitive=yes \\file-system-id.region.nas.aliyuncs.com\! Z:

ご利用の環境に基づいて、ドライブ文字 Z: とマウントポイントアドレス file-system-id.region.nas.aliyuncs.com を置き換えてください。

Windows クライアントから NFS ファイルシステム上のファイルの名前を変更する際の invalid device エラーの解決方法

NFS ファイルシステムのサブディレクトリをマウントした場合、ファイルの名前を変更すると invalid device エラーが返されます。これを解決するには、ファイルシステムのルートディレクトリをマウントします。詳細については、「ステップ 2：NFS を使用する汎用 NAS ファイルシステムのマウント」をご参照ください。

NFS でのファイル作成の遅延

• 現象：

  ECS-1 がファイル abc を作成しましたが、ECS-2 がファイル abc を認識するまでに遅延があります。遅延は時々 1 秒であり、最大で 1 分になることもあります。なぜこうなるのでしょうか？

• 原因：

  これはルックアップキャッシュによって引き起こされ、期間 T の間は期待される動作です。たとえば、ECS-2 は ECS-1 がファイル abc を作成する前にファイルパスにアクセスします。これにより、ECS-2 は「ファイルが見つかりません」という応答を受け取り、ファイル abc が存在しないことを示すレコードがキャッシュされます。期間 T 内では、FileAttr がまだ期限切れになっていないため、ECS-2 が再びファイルパスにアクセスすると、ファイル abc が存在しないことを示すキャッシュされたレコードをまだ取得します。

• ソリューション：

  ECS-1 がファイルを作成した直後に ECS-2 がファイルを認識できるようにするには、次のいずれかのソリューションを使用します。

  • ソリューション 1：ECS-2 でネガティブルックアップキャッシュを無効にして、存在しないファイルのキャッシュを防ぎます。このソリューションはオーバーヘッドが最も低いです。

    ファイルシステムをマウントする際に、lookupcache=positive オプションを追加します。デフォルト値は lookupcache=all です。次のコマンドは例です。

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,lookupcache=positive file-system-id.region.nas.aliyuncs.com:/ /mnt

  • ソリューション 2：ECS-2 ですべてのキャッシュを無効にします。このソリューションはパフォーマンスを著しく低下させる可能性があります。ワークロードで必要な場合にのみ、このソリューションを選択してください。

    ファイルシステムをマウントする際に、actimeo=0 オプションを追加します。次のコマンドは例です。

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

NFS でのデータ書き込みの遅延

• 現象：

  ECS-1 が abc という名前のファイルを更新します。しかし、ECS-2 がすぐにファイルを読み取ると、まだ古い内容を読み取ります。なぜこうなるのでしょうか？

• 原因：

  この問題には次の 2 つの原因があります。

  • ECS-1 がファイル abc にデータを書き込んだ後、データはすぐにサーバーにフラッシュされません。代わりに、クライアントはまずデータをページキャッシュにキャッシュします。データは、アプリケーションが fsync または close を呼び出したときにのみフラッシュされます。

  • ECS-2 にはファイルキャッシュがあり、サーバーから最新のコンテンツをすぐに取得しない場合があります。たとえば、ECS-1 がファイル abc を更新したときに ECS-2 がデータをキャッシュしている場合、ECS-2 は再びファイルを読み取るときにキャッシュされたコンテンツを使用します。

• ソリューション：

  ECS-1 がファイルを更新した直後に ECS-2 が最新のデータを読み取れるようにするには、次のいずれかのソリューションを使用します。

  • ソリューション 1：close-to-open (CTO) 整合性を使用します。CTO を確保するには、ECS-1 がファイルを更新した後、close または fsync を呼び出す必要があります。ECS-2 がファイルを読み取る前に、ファイルを再オープンしてから読み取る必要があります。

  • ソリューション 2：ECS-1 と ECS-2 の両方ですべてのキャッシュを無効にします。このソリューションはパフォーマンスを著しく低下させる可能性があります。ワークロードで必要な場合にのみ、このソリューションを選択してください。

    • ECS-1 でキャッシュを無効にします。ファイルシステムをマウントする際に、noac オプションを追加して、書き込まれたすべてのデータがすぐに永続化されるようにします。次のコマンドは例です。

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,noac file-system-id.region.nas.aliyuncs.com:/ /mnt

      説明

      • ECS-1 での書き込み操作が完了した後に fsync 呼び出しが行われる場合、または同期書き込みを使用する場合は、noac を actimeo=0 に置き換えることで、パフォーマンスがわずかに向上します。

      • noac オプションは、actimeo=0 を指定し、すべての書き込みを同期的に強制することと同じです。

    • ECS-2 でキャッシュを無効にします。ファイルシステムをマウントする際に、actimeo=0 オプションを追加して、すべてのキャッシュを無視します。次のコマンドは例です。

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

異なる ECS インスタンスでの異なるファイル所有者

ファイルシステムでは、ユーザー ID はユーザー名ではなく UID または GID で識別されます。ECS インスタンスで所有者として表示されるユーザー名は、この UID から派生します。

たとえば、ECS インスタンス 1 では、admin ユーザーが admin_on_machine1 という名前のファイルを作成します。ECS インスタンス 2 では、admin ユーザーが admin_on_machine2 という名前のファイルを作成します。

ECS インスタンス 1 で ll コマンドを実行してファイルを表示すると、出力は次のようになります。

$ ll
total 0
-rw-rw-r-- 1 admin    admin 0 Apr  6 17:10 admin_on_machine1
-rw-rw-r-- 1 terminal 19062 0 Apr  6 17:12 admin_on_machine2

ECS インスタンス 2 で ll コマンドを実行すると、出力は次のようになります。

$ ll
total 0
-rw-rw-r-- 1    505    505 0 Apr  6 17:10 admin_on_machine1
-rw-rw-r-- 1 admin  admin 0 Apr  6 17:12 admin_on_machine2

2 つの ECS インスタンスからのクエリ結果は、同じファイルが異なる所有者ユーザー名を持っていることを示しています。

次に、各インスタンスで id コマンドを実行して、admin ユーザー情報をクエリします。

ECS インスタンス 1 では、admin ユーザーの UID は 505 で、次の出力に示されています。

$ id
uid=505(admin) gid=505(admin) groups=505(admin)

ECS インスタンス 2 では、admin ユーザーの UID は 2915 で、次の出力に示されています。

$ id
uid=2915(admin) gid=19062(admin) groups=19062(admin)

stat admin_on_machine1 admin_on_machine2 コマンドを実行して、両方のファイルの詳細を確認します。出力は、admin_on_machine1 の UID が 505/UNKNOWN、GID が 505/UNKNOWN であるのに対し、admin_on_machine2 の UID が 2915/admin、GID が 19062/admin であることを示しています。これは、admin ユーザーが 2 つの ECS インスタンスで異なる UID と GID を持っていることを確認します。

$ stat admin_on_machine1 admin_on_machine2
  File: 'admin_on_machine1'
  Size: 0          Blocks: 0          IO Block: 1048576 regular empty file
Device: 25h/37d Inode: 6447105    links: 1
Access: (0664/-rw-rw-r--)  Uid: (  505/ UNKNOWN)   Gid: (  505/ UNKNOWN)
Access: 2021-04-06 17:10:56.423782205 +0800
Modify: 2021-04-06 17:10:56.423782290 +0800
Change: 2021-04-06 17:10:56.423874225 +0800
 Birth: -
  File: 'admin_on_machine2'
  Size: 0          Blocks: 0          IO Block: 1048576 regular empty file
Device: 25h/37d Inode: 6447106    links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 2915/   admin)   Gid: (19062/   admin)
Access: 2021-04-06 17:12:42.267027897 +0800
Modify: 2021-04-06 17:12:42.267027984 +0800
Change: 2021-04-06 17:12:42.267106855 +0800
 Birth: -

ログファイルへの同時書き込みによる例外

現象

Apsara File Storage NAS は、複数のクライアントに対して統一された名前空間で共有ファイルアクセスを提供します。しかし、複数のプロセスやクライアントが同じファイル (ログファイルなど) に同時に書き込む場合、各プロセスは独自のファイルディスクリプタと書き込みオフセットのコンテキストを維持します。NFS プロトコルにはアトミックな追加セマンティクスがないため、上書きやインターリーブなどのデータ破損の問題が発生する可能性があります。

ソリューション

• (推奨) 異なるプロセスまたはクライアントが同じファイルシステム内の異なるファイルに書き込み、後で分析のためにファイルをマージします。このアプローチは同時実行の問題を回避し、ファイルロックを必要としないため、パフォーマンスに影響を与えません。

• ログファイルなど、同じファイルへの同時追加を伴うシナリオでは、ファイルロックとシークメカニズムを使用して、書き込みの原子性と一貫性を確保できます。ただし、この方法はパフォーマンスを大幅に低下させる可能性があります。次のセクションでは、参考のために簡単な概要を説明します。

flock と seek の使用方法

NFS プロトコルはアトミックな追加セマンティクスを提供しないため、ログファイルなど、同じファイルの末尾への同時書き込みは、互いに上書きされやすいです。Linux では、flock とシークメカニズムを使用して、NFS ファイルシステム上でアトミックな追加をシミュレートし、同時追加書き込みを保護できます。

次のステップに従います。

1. fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) を呼び出して、ファイルを追加モードで開き、O_DIRECT を指定してページキャッシュをバイパスします。これにより、ファイルディスクリプタ fd が返されます。

2. flock(fd, LOCK_EX|LOCK_NB) を呼び出して、ファイルロックの取得を試みます。呼び出しが失敗した場合 (たとえば、ロックがすでに保持されているため)、エラーが返されます。その後、リトライするか、エラーを処理できます。

3. ロックを取得した後、lseek(fd, 0, SEEK_END) を呼び出して、fd の現在の書き込みオフセットをファイルの末尾に移動します。

4. 通常の書き込み操作を実行します。データはファイルの末尾に書き込まれ、ファイルロックにより同時書き込みが互いに上書きされるのを防ぎます。

5. 書き込み操作が完了した後、flock(fd, LOCK_UN) を呼び出してファイルロックを解放します。

Linux オペレーティングシステムの NFS ファイルシステムで ls コマンドを実行すると 523 エラーが返される理由

現象

Linux クライアントから NFS ファイルシステムで ls コマンドを実行すると、次のエラーメッセージが返されます。

ls: reading directory '.': Unknown error 523

原因

ファイルシステムディレクトリで ls コマンドを実行中に、同時に rename 操作が実行されている場合、523 エラーが返されます。

ソリューション

しばらく待ってから操作をリトライしてください。エラーが続く場合は、チケットを送信してください。

SMB ファイルシステムのマウント失敗

現象

NFS と SMB の両方のファイルシステムを使用し、net use コマンドを使用して NFS ファイルシステムのマウントに失敗した場合、正しい SMB ファイルシステムをマウントしようとするときにも問題が発生する可能性があります。

ソリューション

正しいファイルシステムをマウントしていることを確認し、マウント操作を一時的に停止し、5 分後にもう一度試してください。操作がまだ失敗する場合は、チケットを送信してください。

マウントされたディレクトリが Administrator にしか表示されない問題

この問題は、Windows のユーザー分離メカニズムが原因です。あるユーザーによってマウントされたディレクトリは、別のユーザーのセッションでは表示されません。

複数のユーザー間で共有を有効にするには、ディレクトリリンクを作成します。たとえば、次のコマンドを実行して、C ドライブに myshare という名前のディレクトリを作成します。

mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\

Linux クライアントでの SMB のパフォーマンス低下

SMB ファイルシステムのパフォーマンスが低い場合は、次の潜在的な原因に基づいて問題をトラブルシューティングできます。

• 原因 1：SMB ファイルシステムの最大スループットは、そのストレージ容量に線形に比例します。

  ソリューション：fio ツールを使用して SMB ファイルシステムのパフォーマンスをテストします。詳細については、「NAS ファイルシステムのパフォーマンステスト」をご参照ください。

• 原因 2：Linux を実行する単一の ECS インスタンスのネットワーク帯域幅が低い。

  ソリューション：Linux を実行する複数の ECS インスタンスを使用して、ファイルシステムの望ましい全体的なパフォーマンスを達成します。

• 原因 3：SMB ファイルシステムのクライアント側のキャッシュが無効になっている。

  ソリューション：SMB ファイルシステムをマウントする際、cache=none はキャッシュが無効であることを示します。デフォルトのオプションまたは cache=strict はキャッシュが有効であることを示します。sudo mount | grep cifs コマンドを実行して、正しいオプションが使用されているか確認できます。

• 原因 4：SMB クライアントの I/O サイズが適切に設定されていない。

  ソリューション：ビジネス要件に基づいて rsize と wsize の値を調整します。デフォルト値は 1048576 です。

• 原因 5：Linux を実行する ECS インスタンスの CPU またはメモリの仕様が低すぎるか、他のサービスによってリソースが過剰に占有されている。

  ソリューション：Linux を実行する ECS インスタンスに適切な仕様を選択し、システム上の他のアプリケーションが使用するリソースをチェックして、CPU とメモリの要件が満たされていることを確認します。top コマンドを実行して、CPU とメモリの使用量を確認できます。

• 原因 6：マウントに atime オプションが使用されている。

  ソリューション：ビジネスがファイルアクセス時間 (atime) にあまり敏感でない場合は、ファイルシステムをマウントする際に atime オプションを使用しないでください。

• 原因 7：Web サーバーのシナリオでは、多数の小さなファイルの頻繁な読み取り、まれな書き込み、および書き込み通知が含まれます。

  ソリューション：クライアント上の Apache などの Web サーバーに特定のキャッシュ機構を設定するか、Alibaba Cloud NAS チームに連絡して、Web サーバーシナリオの高速化を有効にすることができます。

Linux から SMB ファイルシステムにアクセスする際の Permission denied エラーの解決方法

原因：このエラーは、マウントコマンドで UID、GID、file_mode、または dir_mode に誤った値が使用されている場合に発生する可能性があります。

ソリューション：UID、GID、file_mode、dir_mode などのマウントオプションが正しく設定されているか確認してください。詳細については、「SMB ファイルシステムのマウント」をご参照ください。

SMB でのファイル名の大文字/小文字の変更

SMB ファイルシステムは、Windows システムと一致して、大文字/小文字を区別しません。ただし、大文字/小文字を変更するだけでファイルの名前を変更することはできません。

回避策として、まずファイル名を別の名前に変更し、次に正しい大文字/小文字で目的の名前に変更することができます。

ファイル所有者とモードの変更不可

ファイルやディレクトリの所有者やモードを動的に変更することはできません。これらの属性は、ファイルシステムをマウントするときにのみ指定できます。詳細については、「SMB ファイルシステムのマウント」をご参照ください。

.nfs 拡張子を持つファイルが生成される仕組みと削除方法

アプリケーションで開いているファイルを削除すると、システムは .nfs 拡張子を持つ一時ファイルを作成します。アプリケーションプロセスが閉じると、システムはこのファイルを自動的に削除します。

NAS ファイルシステムディレクトリ内のファイルにアクセスする際の bind conn to session failed on NFSv4 server エラーの解決方法

• 原因

  このエラーは、Apsara File Storage NAS が NFSv4.1 をサポートしていないために発生します。NFSv4.1 を使用してファイルシステムをマウントしようとすると、システムはこのエラーを報告します。

• ソリューション

  ビジネスシナリオに基づいて、NFSv3 または NFSv4.0 を使用してファイルシステムを再マウントします。詳細については、「ファイルシステムのマウントに関する注意事項」をご参照ください。

NFS のデータ同期の問題

現象

複数のクライアントが同じ NAS ファイルシステムをマウントしている場合、あるクライアントで行われたデータの変更が、他のクライアントですぐに表示されないことがあります。

原因

デフォルトでは、オペレーティングシステムのカーネルはファイルとディレクトリの属性を維持し、NFSPROC_GETATTR リモートプロシージャコールの必要性を減らすためにメタデータキャッシュを作成します。

ソリューション

次のマウントコマンドを実行して、ファイルとディレクトリの属性のキャッシュを無効にします。

mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mnt

file-system-id.region.nas.aliyuncs.com をファイルシステムのマウントポイントアドレスに、/mnt をファイルシステムをマウントしたいサーバー上のローカルパスに置き換えてください。

再マウント後もコンテナが古い NAS に書き込む問題

原因

NAS ファイルシステムを ECS インスタンスにマウントし、そのマウントディレクトリをローカルボリューム (HostPath) を使用してコンテナにマッピングすると、コンテナのマウント情報はホストの ECS インスタンスから独立します。その結果、ホスト上の元の NAS ディレクトリをアンマウントしたり、新しいものをマウントしたりしても、実行中のコンテナは古い NAS ファイルシステムを使い続けます。

ソリューション

ECS インスタンスに新しい NAS ファイルシステムをマウントした後、コンテナ Pod を再起動します。

サーバー再起動後にファイルが表示されない問題

ファイルシステムがまだ存在する場合、この問題は通常、サーバーが再起動時に NAS ファイルシステムを自動マウントするように設定されていないために発生します。

NAS ファイルシステムを再度手動でマウントするには、「ファイルシステムのマウントに関する注意事項」をご参照ください。

再起動後に NAS ファイルシステムを自動マウントするように設定するには、次のトピックをご参照ください。

• Linux システムで NFS ファイルシステムを自動マウントする

• Windows システムで SMB ファイルシステムを自動マウントする

Linux での SMB を使用したファイル移行とコピーの低速化

ファイルシステムのパフォーマンスの問題を除外した場合、低速化は移行またはコピープロセスの同時実行数が不足していることが原因である可能性があります。並列での移行またはコピーには、次のオープンソースツールを使用できます。

• GNU Parallel

  システムリソースに基づいて適切なスレッド数を選択します。例：find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &

• Fpart

• Fpsync

• multi

"Disk quota exceeded" エラー

• 原因

  ターゲットディレクトリのストレージ使用量またはファイル数が制限クォータの上限を超えました。その結果、書き込み操作が失敗し、Disk quota exceeded などのエラーメッセージが返されます。これらの操作には、ファイル長の増加、ファイルまたはディレクトリの作成、ディレクトリへのファイルの移動が含まれます。

• ソリューション

  1. これを解決するには、データを削除してスペースを解放するか、ディレクトリの容量制限を増やします。詳細については、「ユーザーのクォータの編集」をご参照ください。

  2. スペースを解放した後、影響を受けるディレクトリでテスト書き込み操作 (テストファイルの作成とデータ書き込みなど) を実行します。これにより、クォータキャッシュの非同期リフレッシュがトリガーされます。テスト書き込み操作が成功したことを確認した後、ご利用のサービスを再起動できます。

NFS アクセス時の "Permission denied" エラー

次のステップに従って、システムに AnonymousGid と AnonymousUid を設定できます。

1. ファイルシステムがマウントされている ECS インスタンスにログインします。

2. コマンドプロンプトを開き、regedit コマンドを実行してレジストリエディターを開きます。

3. に移動します。

4. 空白の領域を右クリックし、 を選択して、次の 2 つのレジストリエントリを作成します。

   • AnonymousGid、値は 0。

   • AnonymousUid、値は 0。

     レジストリエディターで、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default パスに AnonymousGid と AnonymousUid の両方が含まれ、それぞれが 0 に設定されていることを確認します。

5. ECS インスタンスを再起動します。

6. NFS を使用する汎用 NAS ファイルシステムを再マウントします。

   mount -o nolock -o mtype=hard -o timeout=60 \\file-system-id.region.nas.aliyuncs.com\! Z:

   ドライブ文字 Z: とマウントポイントのドメイン名 file-system-id.region.nas.aliyuncs.com を実際の値に置き換えてください。

7. mount コマンドを実行して、ファイルシステムが正常にマウントされたかどうかを確認します。

   マウントが完了すると、出力には mount=hard、locking=no、および 10 以上のタイムアウト値が含まれている必要があります。そうでない場合、マウントは失敗しています。期待される出力の例は次のとおりです。

   C:\Users\Administrator>mount
   Local    Remote                              Properties
   Z:       \\29xxx.nas~          UID=-2, GID=-2
                             rsize=1048576, vsize=1048576
                             mount=hard, timeout=10.0
                             retry=1, locking=no
                             fileaccess=755, lang=GB2312-80
                             casesensitive=no
                             sec=sys

chown を使用したルートディレクトリの権限変更

NAS ルートディレクトリの権限を変更することはできません。

ローカルにマウントされた NAS ディレクトリの権限を制御するには、サブディレクトリをマウントします。たとえば、NAS ルートディレクトリを /data にマウントした場合、chown を使用して /data ディレクトリの所有者とグループを変更することはできません。事前に作成する必要がある NAS サブディレクトリをローカルの /data ディレクトリにマウントした場合、chown を使用して /data ディレクトリの所有者とグループを変更できます。NAS にサブディレクトリを作成するには、まず NAS ルートディレクトリをマウントしてからサブディレクトリを作成する必要があることに注意してください。サブディレクトリの作成とマウント方法については、「Linux システムで NAS サブディレクトリを作成してマウントする方法」をご参照ください。