ファイルシステム内のファイルにアクセスする際、ファイルには一定の制限が適用されます。これらの制限により、ファイル操作エラー、マウントポイントの応答なし、およびアクセス応答なしといった現象が発生する可能性があります。本トピックでは、一般的なファイル操作エラー、ファイル所有者に関する問題、データの非同期化、およびアクセス応答なしのトラブルシューティング方法について説明します。
クロスマウント互換性の問題
Linux による SMB ファイルシステムのマウント時の一般的な互換性の問題
Windows による NFS プロトコルを使用した汎用型 NAS ファイルシステムのマウント時の互換性の問題
その他の読み取り/書き込みファイル関連の問題
NAS ファイルシステム内で同一ファイルを照会した際に、2 台の ECS インスタンスで異なるファイル所有者が表示されるのはなぜですか？
Linux オペレーティングシステム上で NFS ファイルシステム内にて「ls」コマンドを実行した際に、523 エラーが返されるのはなぜですか？
Administrator はマウントされた SMB ディレクトリを確認できますが、他のユーザーは確認できないのはなぜですか？
Linux による SMB ファイルシステムのマウント時にパフォーマンスが低下する場合のトラブルシューティング方法を教えてください。
Linux による SMB ファイルシステムへのアクセス時に「Permission denied」エラーが発生するのはなぜですか？
複数の ECS インスタンスが同一 NFS ファイルシステムをマウントした場合のデータの非同期化のトラブルシューティング方法を教えてください。
古い NAS をアンマウントして新しい NAS を再マウントした後も、コンテナ Pod が引き続き古い NAS にデータを書き込むのはなぜですか？
同一ファイルを同時アクセスした際に、サーバーが 35 秒間応答しなくなる場合の対処方法を教えてください。
原因：現在の Linux SMB カーネルドライバーには欠陥があります。この欠陥により、`vers=2.1` または `3.0` を指定してマウントした場合、特定の同時アクセスシナリオにおいて、サーバーが期待される SMB BreakAck プロトコルパケットを送信できなくなります。その結果、サーバーが 35 秒間応答しなくなります。
解決策 1 ：ファイルシステムを `vers=2.0` プロトコルでマウントします。
解決策 2 ：以下の操作を行います。
CIFS モジュールの読み込み時に oplock を無効化できます。次のコマンドを実行します。
# modprobe cifs enable_oplocks=0CIFS モジュールの読み込み後に oplock を無効化できます。次のコマンドを実行します。
# echo 0 > /sys/module/cifs/parameters/enable_oplocksoplock の状態を確認できます。次のコマンドを実行します。
# cat /sys/module/cifs/parameters/enable_oplocks出力結果で「Y」は有効、「N」は無効を意味します。
説明これらの変更を適用するには、SMB ファイルシステムをアンマウントしてから再マウントする必要があります。
これらの変更を永続化するには、
/etc/modprobe.d/cifs.confファイルを作成し、そこにoptions cifs enable_oplocks=0コマンドラインを追加します。
シンボリックリンクファイルを作成できないのはなぜですか？
原因
Linux で SMB プロトコルのファイルシステムをマウントする際に、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=1048576SMB ファイルシステムのマウントポイントが応答しないのはなぜですか？
原因
カーネルバージョンが 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` を指定して再マウントします（パフォーマンスに影響があります）。
ECS インスタンス（Linux）のオペレーティングシステムをアップグレードします。
大規模ファイルのコピー時に「cp: error writing '</path/to/file>': Bad file descriptor」というエラーが発生した場合の対処方法を教えてください。
原因
一時的な軽微なネットワーク障害またはバックエンド障害が発生しました。SUSE のような一部の Linux ディストリビューションでは、SMB クライアント機能が弱く、このフェールオーバーを十分にサポートしていません。
解決策
NAS SMB が推奨する Linux バージョンをご利用ください。以下の表に、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 または Windows クライアントから NAS ファイルシステムに書き込まれた中国語文字（ファイル名や内容など）が、別のプラットフォームのクライアントで文字化けとして表示されます。
原因
Windows クライアントでは、中国語のエンコーディングおよびデコードにデフォルトで GBK 文字セットが使用されます。一方、Linux クライアントでは、中国語のエンコーディングおよびデコードにデフォルトで UTF-8 文字セットが使用されます。NAS ファイルシステムに書き込まれるデータは、各プラットフォームに対応する文字セットでエンコードされます。別のプラットフォームで読み取る際にはデコードが必要ですが、両プラットフォームの文字セットは互換性がないため、デコードに失敗し、文字化けが発生します。
解決策
Windows クライアントでは SMB ファイルシステムをマウントし、Linux クライアントでは NFS ファイルシステムをマウントすることで、プラットフォーム間の互換性の問題を回避できます。
Windows による NFS ファイルシステムのマウント時に、ファイルの作成および開く処理が遅いのはなぜですか？
原因
Windows で NFS インスタンスを使用する場合、大文字・小文字を区別する／区別しないという互換性の問題が存在します。ディレクトリサイズが大きくなると、ディレクトリ内のファイル作成のパフォーマンスが大幅に低下します。これは、各ファイル作成時にディレクトリの走査が必要となるためです。ディレクトリサイズが 100,000 ファイルに達すると、単一のディレクトリ走査に 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 ディレクトリ内で大文字・小文字の違いによる名前衝突（例：`a.txt` と `A.TXT` が同時に存在する）が発生しないようご注意ください。マウントパラメーターの変更は予期せぬ影響を及ぼす可能性があります。SMB NAS のご利用を推奨します。
Windows クライアントから NFS ファイルシステム上のファイルの名前を変更すると invalid device エラーが返される場合の解決策
NFS ファイルシステムがファイルシステムのサブディレクトリにマウントされている場合、ファイルの名前変更を行うと invalid device エラーが返されます。ファイルシステムをルートディレクトリにマウントできます。詳細については、「手順 2: NFS プロトコルを使用した汎用型 NAS のマウント」をご参照ください。
NFS ファイルシステムにおけるファイル作成遅延のトラブルシューティング方法を教えてください。
現象：
ECS-1 がファイル abc を作成しますが、ECS-2 ではそのファイル abc を確認できるまで遅延が発生します。この遅延は 1 秒から 1 分程度になります。これはなぜですか？
原因：
これは Lookup キャッシュによるものであり、一定時間 T の範囲内では想定される動作です。たとえば、ECS-1 がファイル abc を作成する前に ECS-2 が同ファイルを参照していた場合、ECS-2 は当該ファイルが存在しないと記録します。これにより、ファイル abc が存在しないというキャッシュレコードが作成されます。時間 T の間に FileAttr が期限切れになっていないため、ECS-2 が再度ファイルを参照した際にも、依然としてファイル abc が存在しないという初期のキャッシュレコードを参照します。
解決策：
ECS-2 が ECS-1 のファイル作成直後にファイルを即座に確認できるようにするには、以下の解決策をご利用ください：
解決策 1：ECS-2 で Negative Lookup キャッシュを無効化し、存在しないファイルのキャッシュを防止します。この解決策はオーバーヘッドが最小限です。
マウント時に 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 への書き込み後に即座にフラッシュしません。代わりに PageCache を実行し、アプリケーション層が `fsync` または `close` を呼び出すことを前提としています。
次に、ECS-2 にはファイルキャッシュがあり、最新の内容をサーバーから即座に取得しない場合があります。たとえば、ECS-1 がファイル abc を更新した際に ECS-2 がデータをキャッシュしていた場合、ECS-2 が再度読み取る際にも、依然としてキャッシュされた内容を使用します。
解決策：
ECS-2 が ECS-1 のファイル作成直後にファイルを即座に確認できるようにするには、以下の解決策をご利用ください：
解決策 1：CTO 一貫性。ECS-1 または ECS-2 の読み取り／書き込み操作を CTO モデルに準拠させることで、ECS-2 が常に最新のデータを読み取れるようにします。具体的には、ECS-1 がファイルを更新した後には必ず `close` または `fsync` を実行する必要があります。また、ECS-2 が読み取る前に必ず `open` を実行してから読み取る必要があります。
解決策 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に sync（すべての書き込みを同期書き込みにする）を追加したものと同等です。
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
NAS ファイルシステム内で同一ファイルを照会した際に、2 台の ECS インスタンスで異なるファイル所有者が表示されるのはなぜですか？
ファイルシステムでは、ユーザーはユーザー名ではなく UID または GID で識別されます。ECS インスタンスで照会したファイル所有者のユーザー名は、UID 情報から変換されたものです。同じ UID が異なる ECS インスタンスで異なるユーザー名に変換される場合、それは異なる所有者と見なされます。
たとえば、ECS インスタンス 1 は admin ユーザーを使用してファイル admin_on_machine1 を作成します。 ECS インスタンス 2 は admin ユーザーを使用してファイル admin_on_machine2 を作成します。 ECS インスタンス 1 で ll コマンドを実行すると、次の図に示すように、作成されたファイルが表示されます。
ECS インスタンス 2 で ll コマンドを実行すると、次の図に示すように、作成されたファイルが表示されます。
両方の ECS インスタンスからクエリを実行すると、同じファイルのファイル所有者のユーザー名に一貫性がないことがわかります。
その後、各インスタンスで id コマンドを実行して admin ユーザー情報を照会できます。以下図に示すとおり、ECS インスタンス 1 の admin ユーザーの UID は 505 です：
以下図に示すとおり、ECS インスタンス 2 の admin ユーザーの UID は 2915 です：
以下図に示すとおり、stat admin_on_machine1 admin_on_machine2 コマンドを実行すると、2 つのファイルが異なる UID に属していることがわかります：
複数のプロセスまたはクライアントが同一ログファイルに同時に書き込む場合に発生する例外を防止する方法を教えてください。
現象
File Storage NAS は、複数のクライアントに対して統一された名前空間を提供するファイル共有の読み取り／書き込み機能を備えています。ただし、複数のプロセスまたはクライアントが同一ファイル（通常はログファイル）に同時に書き込む場合、各プロセスは独立したファイル記述子および書き込み位置のコンテキスト情報を維持します。NFS プロトコル自体は Atomic Append セマンティクスをサポートしていないため、上書き、インタリーブ、またはシリアル化などの例外が発生する可能性があります。
解決策
（推奨）異なるプロセスまたはクライアントが同一ファイルシステム内の異なるファイルに書き込むようにし、後続の分析時にそれらをマージします。この解決策は、同時書き込みによって引き起こされる問題を効果的に解決し、ファイルロックを必要としないため、パフォーマンスへの影響を回避できます。
同一ファイル（ログファイルなど）への同時追加書き込みを伴うシナリオでは、ファイルロック＋シーク機構を使用して書き込みの原子性および一貫性を確保できます。ただし、ファイルロック＋シークは時間のかかる操作であり、パフォーマンスに大きな影響を与える可能性があります。この手法の簡単な紹介を以下に示します（参考用）。
`flock` ＋ `seek` の使用方法
NFS プロトコル自体は Atomic Append セマンティクスをサポートしていないため、同一ファイル（ログファイルなど）の末尾への同時書き込みは上書きを引き起こす可能性があります。Linux では、`flock` ＋ `seek` を使用することで、NFS ファイルシステム上で Atomic Append を模倣し、同一ファイルへの同時追加書き込みに対する保護およびサポートを提供できます。
使用方法は以下のとおりです：
`fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT)` を呼び出して、追加書き込み用にファイルを開き、`O_DIRECT`（Page Cache をバイパスする直接書き込み）を指定してファイル記述子 `fd` を取得できます。
`flock(fd, LOCK_EX|LOCK_NB)` を呼び出して、ファイルロックの取得を試みることができます。取得に失敗した場合（既にロックが取得済みなど）、エラーが返されます。リトライまたはエラー処理を行ってください。
ファイルロックの取得に成功した後、`lseek(fd, 0, SEEK_END)` を呼び出して、`fd` の現在の書き込みオフセットをファイルの末尾に設定できます。
通常の `write` 操作を実行できます。書き込み位置はファイルの末尾にある必要があります。ファイルロックによる保護により、同時書き込みによる上書きは発生しません。
書き込み操作が完了したら、`flock(fd, LOCK_UN)` を呼び出してファイルロックを解放できます。
Linux オペレーティングシステム上の NFS ファイルシステムで ls コマンドを実行すると、なぜ 523 エラーが発生するのですか?
現象
Linux クライアントが NFS ファイルシステムで ls コマンドを実行すると、以下のエラーメッセージが返されます。
原因分析
ls コマンドを、同時実行中の rename 操作が実行されているファイルシステムのディレクトリで実行すると、システムはエラー 523 を返します。
解決策
しばらく待ってから再試行してください。エラーが継続する場合は、チケットを送信 してサポートを受けてください。
SMB ファイルシステムのマウント時に、接続に失敗することがあるのはなぜですか？
現象
NFS および SMB ファイルシステムを混在して使用する場合、最初に net use コマンドを使用して NFS ファイルシステムをマウントしようとした際に失敗すると、正しい SMB ファイルシステムのマウントにも問題が発生することがあります。
解決策
正しいファイルシステムがマウントされていることを確認してください。一時的にマウントを停止し、5 分後に再試行してください。それでも失敗する場合は、チケットを送信 してサポートを受けてください。
Administrator はマウントされた SMB ディレクトリを確認できますが、他のユーザーは確認できないのはなぜですか？
この現象は、Windows のユーザー隔離メカニズムによって引き起こされます。1 人のログインユーザーに対してマウントされたディレクトリは、他のユーザーのログインインターフェイスには表示されません。
マルチユーザー共有を実現するには、ディレクトリリンクを作成できます。たとえば、以下のコマンドを使用して C ドライブ下に `myshare` を作成できます：
mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\Linux による SMB ファイルシステムのマウント時にパフォーマンスが低下する場合のトラブルシューティング方法を教えてください。
SMB ファイルシステムのパフォーマンスが低下している場合、以下の観点から調査できます。
原因 1：単一 SMB ファイルシステムのスループット容量は、そのストレージ容量に関連しています。単一ファイルシステムのスループット（読み取り＋書き込み）の上限は、現在のストレージ容量に比例します。
解決策：`fio` ツールを使用して SMB ファイルシステムのパフォーマンスをテストできます。詳細については、「NAS Performance Testing」をご参照ください。
原因 2：単一 ECS インスタンス（Linux）のネットワーク帯域幅が小さすぎます。
解決策：複数の ECS インスタンス（Linux）を使用して、ファイルシステム全体の期待パフォーマンスを達成できます。
原因 3：SMB ファイルシステムのクライアントキャッシュが無効になっています。
解決策：SMB ファイルシステムをマウントする際、`cache=none` はキャッシュを無効化し、`default` または `cache=strict` はキャッシュを有効化します。`
sudo mount | grep cifs` コマンドを使用して、オプションが正しく設定されているか確認できます。原因 4：SMB クライアントの I/O サイズが適切に設定されていません。
解決策：必要に応じて `rsize` および `wsize` を調整できます。デフォルト値は 1048576 です。
原因 5：ECS インスタンス（Linux）の CPU またはメモリ仕様が低すぎたり、他のサービスが過剰なリソースを消費したりしています。
解決策：適切な ECS インスタンス（Linux）仕様を選択できます。システム上の他のアプリケーションリソースを確認し、CPU およびメモリ要件を満たしていることを確認してください。`
top` コマンドを使用して、システムの CPU およびメモリ使用量を確認できます。原因 6：マウント時に `atime` オプションが使用されています。
解決策：ファイルアクセス時刻（`atime`）に対してビジネス要件が厳しくない場合は、マウント時に `atime` オプションを使用しないでください。
原因 7：多数の小規模ファイルの頻繁な読み取り、少数の書き込み、および書き込み通知を必要とする WebServer シナリオに遭遇しています。
解決策：クライアント側で WebServer 製品（Apache など）の特定のキャッシュ機構を構成するか、Alibaba Cloud NAS チーム に連絡して、WebServer シナリオ向けの高速化機能を有効化してください。
Linux で SMB プロトコル ファイルシステムにアクセスする際の Permission denied エラーの解決方法
原因：Linux 管理者がマウント時に誤った 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」というエラーが返される場合のトラブルシューティング方法を教えてください。
原因
File Storage NAS は NFSv4.1 プロトコルをサポートしていません。このエラーは、NFSv4.1 プロトコルを使用してファイルシステムをマウントした際に発生します。
解決策
ビジネスシナリオに応じて、NFSv3 または NFSv4.0 プロトコルを使用してファイルシステムを再マウントできます。詳細については、「ファイルシステムのマウントシナリオ」をご参照ください。
複数の ECS インスタンスが同一 NFS ファイルシステムをマウントした場合のデータの非同期化のトラブルシューティング方法を教えてください。
現象
NAS に複数のマウントポイントがある場合、異なるクライアント間でのリアルタイム同期に長い遅延が発生します。
原因
オペレーティングシステムのカーネルは、デフォルトでファイルおよびディレクトリ属性のメタデータキャッシュを維持します。これにより、NFSPROC_GETATTR リモートプロシージャコールの必要性が減少します。
解決策
以下のマウントコマンドを実行して、ファイルおよびディレクトリ属性のキャッシュを無効化できます。
mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mntfile-system-id.region.nas.aliyuncs.com を実際のマウント先アドレスに置き換え、/mnt を現在のサーバー上のマウント先ローカルパスに必要に応じて置き換えてください。
古い NAS をアンマウントして新しい NAS を再マウントした後も、コンテナ Pod が引き続き古い NAS にデータを書き込むのはなぜですか？
原因
NAS を ECS インスタンスにマウントし、NAS のマウントディレクトリをローカル記憶域（HostPath）を使用してコンテナーにマップした場合、コンテナーのマウント情報は ECS インスタンスとは独立しています。ECS インスタンスがその後 NAS のマウントディレクトリをアンマウントしたり、新しい NAS をマウントしたりしても、すでに実行中のコンテナーは起動時にマウントされた古い NAS を引き続き使用します。
解決策
ECS インスタンスで新しい NAS を再マウントした後、コンテナ Pod を再起動する必要があります。
サーバーの再起動またはシャットダウン後に NAS 内のファイルが表示されないのはなぜですか？
ファイルシステムが依然として存在する場合、これは通常、サーバーが 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 ファイルシステムへのアクセス時に「アクセス拒否」が発生した場合のトラブルシューティング方法を教えてください。
システムに対して 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`、および `timeout` パラメーター（>= 10）が含まれている必要があります。含まれていない場合は、マウントに問題があります。
chown コマンドを実行して NAS ルートディレクトリの権限を変更できますか？
現在、NAS ルートディレクトリの権限を変更することはできません。
ローカルにマウントされた NAS ディレクトリの権限を制御するには、サブディレクトリのマウントを検討できます。たとえば、NAS ルートディレクトリをローカルの /data ディレクトリにマウントした場合、chown コマンドを使用して /data ディレクトリの所有者およびグループを変更することはできません。一方、事前に作成した NAS のサブディレクトリをローカルの /data ディレクトリにマウントした場合、chown コマンドを使用して /data ディレクトリの所有者およびグループを変更できます。ただし、NAS にサブディレクトリを作成する際には、まず NAS ルートディレクトリをマウントしてからサブディレクトリを作成する必要があります。サブディレクトリの作成およびマウント方法については、「Linux における NAS サブディレクトリの作成およびマウント方法」をご参照ください。