ファイルシステム内のファイルにアクセスする際、ファイル操作エラー、応答しないマウントポイント、またはアクセス遅延が発生する場合があります。本トピックでは、ファイル操作、所有権、データ同期、アクセス遅延に関する一般的な問題に対する解決策を提供します。
-
クロスプロトコルマウントの互換性に関する問題
-
Linux クライアントで SMB ファイルシステムをマウントする際の一般的な互換性の問題
-
Windows クライアントで NFS を使用して汎用 NAS ファイルシステムをマウントする際の互換性に関する問題
-
-
その他の読み取りおよび書き込みに関する問題
-
NAS ファイルシステム内の同じファイルを 2 つの異なる ECS インスタンスからクエリすると、所有者が異なるように表示されるのはなぜですか?
-
Linux オペレーティングシステム上の NFS ファイルシステムで ls コマンドを実行すると 523 エラーが返されるのはなぜですか?
-
Administrator ユーザーはマウントされた SMB ディレクトリを確認できますが、他のユーザーは確認できないのはなぜですか?
-
Linux クライアントで SMB ファイルシステムをマウントした際のパフォーマンスが低下した場合はどうすればよいですか?
-
Linux クライアントから SMB ファイルシステムにアクセスする際に「Permission denied」エラーが発生した場合はどうすればよいですか?
-
NAS ファイルシステムディレクトリ内のファイルにアクセスする際に「bind conn to session failed on NFSv4 server」エラーが発生した場合はどうすればよいですか?
-
複数の ECS インスタンスが同じ NFS ファイルシステムをマウントしている際にデータが同期されない場合はどうすればよいですか?
-
NAS ファイルシステムをアンマウントして新しいものをマウントした後も、コンテナ Pod が古い NAS ファイルシステムにデータを書き込み続けるのはなぜですか?
-
Linux クライアントで SMB ファイルシステムをマウントしている際にファイル移行およびコピー操作が遅くなるのはなぜですか?
-
ファイルシステムにデータを書き込む際に「Disk quota exceeded」エラーメッセージが返されるのはなぜですか?
-
NFS ファイルシステムにアクセスする際に permission denied エラーが発生した場合はどうすればよいですか?
同時ファイルアクセス中のサーバーの応答停止
原因:Linux の SMB カーネルドライバーのバグにより、この問題が発生します。SMB 2.1 または 3.0 を使用してファイルシステムをマウントする際、一部の同時アクセスシナリオでクライアントが期待される SMB BreakAck パケットを送信できず、サーバーが 35 秒間応答しなくなることがあります。
ソリューション 1:SMB 2.0 を使用してファイルシステムをマウントします。
ソリューション 2:以下の手順に従います。
-
CIFS モジュールをロードする際に oplocks を無効にするには、次のコマンドを実行します。
# modprobe cifs enable_oplocks=0 -
CIFS モジュールのロード後に oplocks を無効にするには、次のコマンドを実行します。
# echo 0 > /sys/module/cifs/parameters/enable_oplocks -
oplocks のステータスを確認するには、次のコマンドを実行します。
# cat /sys/module/cifs/parameters/enable_oplocks出力において、Y は有効、N は無効を示します。
説明-
変更を適用するには、SMB ファイルシステムをアンマウントしてから再度マウントしてください。
-
変更を永続的にするには、
/etc/modprobe.d/cifs.confファイルを作成し、options cifs enable_oplocks=0行を追加してください。
-
シンボリックリンクの作成不可
原因
SMB ファイルシステムが Linux 上で mfsymlinks オプションなし、またはプロトコルバージョン 2.0 を使用してマウントされています。
ソリューション
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 を実行している ECS インスタンスのオペレーティングシステムをアップグレードします。
大容量ファイルのコピー時の「Bad file descriptor」エラー
原因
この問題は、一時的なネットワークまたはバックエンドの障害によって発生します。SUSE などの一部の Linux ディストリビューション上の SMB クライアントは、このようなフェールオーバーに対するサポートが限定的です。
ソリューション
以下の表は、NAS SMB で推奨される Linux オペレーティングシステムのバージョンを示しています。
オペレーティングシステム | バージョン |
CentOS | CentOS 7.6 64 ビット:3.10.0-957.21.3.el7.x86_64 以降 |
Alibaba Cloud Linux |
|
Debian | Debian 9.10 64 ビット:4.9.0-9-amd64 以降 |
Ubuntu | Ubuntu 18.04 64 ビット:4.15.0-52-generic 以降 |
openSUSE | openSUSE 42.3 64 ビット:4.4.90-28-default 以降 |
SUSE Linux | SUSE Linux Enterprise Server 12 SP2 64 ビット:4.4.74-92.35-default 以降 |
CoreOS | CoreOS 2079.4.0 64 ビット:4.19.43-coreos 以降 |
クライアントでの中国語文字の文字化け
症状
Linux クライアントから NAS ファイルシステムに中国語文字(ファイル名やファイル内容など)を書き込むと、Windows クライアントで文字化けして表示される場合があります。逆の場合も同様です。
原因
デフォルトでは、Windows クライアントは中国語のエンコーディングおよびデコーディングに GBK 文字セットを使用し、Linux クライアントは UTF-8 文字セットを使用します。各プラットフォームは独自の文字セットを使用してデータをエンコードします。一方のプラットフォームで書き込まれたデータをもう一方のプラットフォームで読み取ると、互換性のない文字セットによりデコーディングに失敗し、内容が文字化けして表示されます。
ソリューション
プラットフォーム間の互換性の問題を回避するため、Windows クライアントでは SMB を使用して、Linux クライアントでは NFS を使用して NAS ファイルシステムをマウントすることを推奨します。
Windows での NFS 使用時のファイル操作の遅延
原因
Windows では、NFS に大文字小文字を区別するセマンティクスと区別しないセマンティクスの間で互換性の問題があります。ディレクトリ内のファイル作成パフォーマンスは、ディレクトリサイズが増加するにつれて著しく低下します。これは、ファイルを作成するたびにディレクトリをトラバースする必要があるためです。ディレクトリに約 10 万件のエントリが含まれている場合、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 のネイティブセマンティクスと競合します。このオプションを使用する場合は、a.txt と A.TXT のような大文字小文字の違いによる名前の競合が NFS ディレクトリに存在しないことを確認してください。マウントパラメーターの変更は予測不可能な影響を及ぼす可能性があります。NAS は SMB 経由での使用を推奨します。
Windows クライアントから NFS ファイルシステム内のファイルの名前を変更する際に invalid device エラーを解消する方法
NFS ファイルシステムのサブディレクトリをマウントしている場合、ファイルの名前変更時に invalid device エラーが返されます。これを解決するには、ファイルシステムのルートディレクトリをマウントしてください。詳細については、「ステップ 2:NFS を使用する汎用 NAS ファイルシステムのマウント」をご参照ください。
NFS でのファイル作成遅延
-
症状:
ECS-1 がファイル abc を作成しましたが、ECS-2 がファイル abc を認識するまでに遅延が発生します。遅延時間は 1 秒程度の場合もあれば、最大で 1 分程度になることもあります。これはなぜですか?
-
原因:
これは Lookup Cache によって引き起こされ、期間 T については予想される動作です。たとえば、ECS-1 がファイル abc を作成する前に ECS-2 がファイルパスにアクセスした場合、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 コマンドを実行してファイルを表示すると、次の図のようになります。
ECS インスタンス 2 で ll コマンドを実行すると、次の図のようになります。
2 つの ECS インスタンスからのクエリ結果は、同じファイルが異なる所有者ユーザー名を持っていることを示しています。
次に、各インスタンスで id コマンドを実行して admin ユーザー情報をクエリします。ECS インスタンス 1 では、admin ユーザーの UID は 505 です(次の図を参照)。
ECS インスタンス 2 では、admin ユーザーの UID は 2915 です(次の図を参照)。
stat admin_on_machine1 admin_on_machine2 コマンドを実行すると、出力結果から 2 つのファイルが異なる UID に属していることがわかります(次の図を参照)。
ログファイルへの同時書き込みによる例外
症状
Apsara File Storage NAS は、複数のクライアントに対して統一された名前空間による共有ファイルアクセスを提供します。ただし、複数のプロセスまたはクライアントが同じファイル(たとえばログファイル)に同時に書き込む場合、各プロセスは独自のファイルディスクリプタと書き込みオフセットコンテキストを維持します。NFS プロトコルにはアトミックな追加セマンティクスがなく、上書きやインターリーブなどのデータ破損の問題が発生する可能性があります。
ソリューション
-
(推奨)異なるプロセスまたはクライアントが同じファイルシステム内の異なるファイルに書き込み、後で分析のためにファイルをマージします。このアプローチにより同時実行の問題を回避でき、ファイルロックも不要なためパフォーマンスに影響しません。
-
同じファイル(たとえばログファイル)への同時追加が必要なシナリオでは、ファイルロックとシーク機構を使用して書き込みの原子性と一貫性を確保できます。ただし、この方法はパフォーマンスを著しく低下させる可能性があります。以下に簡単な概要を示しますので、参考にしてください。
flock および seek の使用方法
NFS プロトコルはアトミックな追加セマンティクスを提供しないため、同じファイル(たとえばログファイル)の末尾への同時書き込みは、簡単に相互に上書きされてしまいます。Linux では、flock および seek 機構を使用して、NFS ファイルシステム上でアトミックな追加をシミュレートし、同時追加書き込みを保護できます。
以下の手順に従います。
-
fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) を呼び出して、追加モードでファイルを開き、O_DIRECT を指定してページキャッシュをバイパスします。これにより、ファイルディスクリプタ fd が返されます。
-
flock(fd, LOCK_EX|LOCK_NB) を呼び出して、ファイルロックの取得を試みます。ロックがすでに保持されているなどの理由で呼び出しが失敗した場合は、エラーが返されます。その後、リトライまたはエラー処理を行います。
-
ロックを取得した後、lseek(fd, 0, SEEK_END) を呼び出して、fd の現在の書き込みオフセットをファイルの末尾に移動します。
-
通常の書き込み操作を実行します。データはファイルの末尾に書き込まれ、ファイルロックにより同時書き込みによる相互上書きが防止されます。
-
書き込み操作が完了したら、flock(fd, LOCK_UN) を呼び出してファイルロックを解放します。
Linux オペレーティングシステム上の NFS ファイルシステムで ls コマンドを実行すると 523 エラーが返されるのはなぜですか?
症状
Linux クライアントから NFS ファイルシステムで ls コマンドを実行すると、次のエラーメッセージが返されます。
原因
ファイルシステムディレクトリで rename 操作が同時に行われている最中に ls コマンドを実行すると、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 での SMB 使用時のファイル移行およびコピーの遅延
ファイルシステムのパフォーマンスの問題を除外した場合、遅延の原因は移行またはコピー処理における同時実行数の不足にある可能性があります。並列移行またはコピーには、以下のオープンソースツールを使用できます。
-
システムリソースに基づいて適切なスレッド数を選択します。例:
find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &
「Disk quota exceeded」エラー
原因
このエラーは、ユーザーまたはグループが対象ディレクトリで定義された制限付きクォータによるストレージ容量またはファイル数の制限を超えていることを示します。これらの操作には、ファイル長の増加、ファイルまたはディレクトリの作成、ディレクトリへのファイル移動が含まれます。
Disk quota exceededなどのエラーメッセージが返されます。ソリューション
データを削除してスペースを解放するか、ディレクトリの容量制限を増やします。詳細については、「ユーザークォータの編集」をご参照ください。
スペースを解放した後、ディレクトリ内で小さな書き込み操作(
touch testfileなど)を実行します。これにより、クォータ統計のリフレッシュがより速くトリガーされます。書き込み操作が成功したら、アプリケーションを再起動してください。
NFS へのアクセス時の「Permission denied」エラー
以下の手順に従って、システムの AnonymousGid および AnonymousUid を設定できます。
-
ファイルシステムがマウントされている ECS インスタンスにログインします。
-
コマンドプロンプトを開き、
regeditコマンドを実行してレジストリエディターを開きます。 -
に移動します。
-
空白領域を右クリックし、 を選択して、次の 2 つのレジストリエントリを作成します。
-
AnonymousGid:値は 0 です。
-
AnonymousUid:値は 0 です。

-
-
ECS インスタンスを再起動します。
-
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は、実際の値に置き換えてください。 -
mountコマンドを実行して、ファイルシステムが正常にマウントされているかどうかを確認します。マウントが完了すると、出力に mount=hard、locking=no、タイムアウト値が 10 以上が含まれている必要があります。そうでない場合、マウントは失敗しています。

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