どのFile Storage for Classic ボリュームが暗号化されているのかはどうすればわかりますか?

カスタマー・ポータルで File Storage for Classic のリストを参照してください。 ボリューム名の横に、ボリュームが暗号化されていることを示す鍵のアイコンが表示されます。

File Storage for Classicの正しいマウント・ポイントはどうすればわかりますか?

拡張データセンターでプロビジョニングされるすべての暗号化 File Storage for Classic ボリュームは、非暗号化ボリュームとは異なるマウントポイントを持つ。 正しいマウントポイントを使用していることを確認するには、コンソールの Volume Details ページでマウントポイント情報を表示します。 API 呼び出し SoftLayer_Network_Storage::getNetworkMountAddress() を使用して正しいマウント・ポイントを取得することもできます。

ボリュームをいくつプロビジョンできますか?

デフォルトでは、ブロックボリュームと File Storage for Classic ボリュームの合計 700 個をプロビジョニングできます。 制限を増やすには、サポートにお問い合わせください。 詳しくは、ストレージ制限の管理を参照してください。

プロビジョニングされた File Storage for Classic ボリュームを共有できるサーバー・インスタンスはいくつありますか？

ファイル・ボリュームあたりの許可数のデフォルトの制限は 64 です。 この制限には、すべてのサブネット、ホスト、および IP 許可の組み合わせが含まれます。 この制限を増やすには、サポートに連絡してください。 詳しくは、サポート Case の作成を参照してください。

File Storage for Classic1 つのホストにボリュームをいくつ接続できますか?

1つのホストに接続できるボリューム数は、ホストのオペレーティングシステムが処理できる量によって異なります。 IBM Cloud® では、その点について制限を設けていません。 マウントできるファイル共有数に関する制限については、ご使用の OS の資料を参照してください。

特定のファイル・ボリューム・サイズに対して許可されるファイルとディレクトリの数は？ ボリューム・サイズごとに許可される i ノードの最大数はいくつですか?

1 つのボリュームに含めることのできるファイル数は、そのボリュームにある i ノードの数に応じて決まります。 i ノードは、ファイルについての情報を含むデータ構造です。 ボリュームには、プライベート i ノードとパブリック i ノードの両方があります。 パブリック i ノードは顧客に公開するファイルに使用し、プライベート i ノードはストレージ・システムによって内部的に使用されるファイルに使用します。 ボリュームの容量32KBごとに1つのinodeを持つことになる。 ファイル数の最大値の設定は20億です。 ただし、この最大値を設定できるのは、 7.8 TB以上のボリュームに限られる。 9,000GB以上のボリュームは、2,040,109,451inodeで上限に達する。

File Storage for Classic ボリュームを間違ったデータ・センターで注文してしまいました。 このボリュームを別のデータ・センターに移動またはマイグレーションすることはできますか?

正しいデータセンターで新しい File Storage for Classic 共有を注文し、間違った場所で注文した File Storage for Classic デバイスをキャンセルする必要があります。

また、共有の複製を作成し、親共有をキャンセルすることもできます。 詳しくは、 複製ボリュームの作成および管理 を参照してください。

Block Storage for Classic ボリュームを "すぐに "キャンセルしたが、コンソールにはまだ表示されている。 なぜ削除されないのか？

ボリュームがキャンセルされると、そのリクエストの後、24時間の再生待ち時間が発生する。 その 24 時間の間は、コンソールにボリュームが表示されています。 24時間の待機期間は、必要に応じてキャンセルリクエストを無効にするチャンスを与えます。 ボリュームの削除をキャンセルしたい場合は、 サポートケースを作成してください。

ボリュームの請求は即時に停止します。 レクラメーション期間が満了すると、データは破棄され、ボリュームもコンソールから除去されます。

IOPS の測定

IOPSは、16KBブロックの負荷プロファイルに基づき、ランダム50%リード、50%ライトで測定されています。 このプロファイルと異なるワークロードでは、パフォーマンスが低下する場合があります。 パフォーマンスを改善するには、ホスト設定を調整するか、 ジャンボフレームを有効にしてみて ください。

パフォーマンス測定に小さいIOサイズを使うとどうなりますか？

より小さいIOサイズを使用しても、最大IOPSを得ることができる。 しかし、スループットはこの場合より低くなります。 たとえば、6000 IOPSのボリュームは、さまざまなIOサイズで次のようなスループットを持つ：

• 16 KB * 6000 IOPS == ~93.75 MB/秒
• 8 KB * 6000 IOPS == ~46.88 MB/秒
• 4 KB * 6000 IOPS == ~23.44 MB/秒

割り振られた IOPS はインスタンス単位で適用されるのですか、ボリューム単位で適用されるのですか?

IOPS は、ボリューム・レベルで適用されます。 すなわち、6000 IOPS を使用できるボリュームに接続されるホストが 2 台あれば、それらのホストは 6000 IOPS を共有します。

期待される処理能力を達成するために、容積を予熱する必要がありますか？

プリウォーミングは必要ありません。 ボリュームをプロビジョニングすると、ただちに指定したスループットになります。

より高速なイーサネット接続を使用すると、より多くのスループットを実現できますか?

スループットの制限はボリュームレベルで設定される。 より高速なイーサネット接続を使用しても、この限度は増えません。 ただし、低速イーサネット接続では、帯域幅がボトルネックとなる可能性があります。

ファイアウォールおよびセキュリティー・グループはパフォーマンスに影響しますか?

ファイアウォールをバイパスするように VLAN 上でストレージ・トラフィックを実行することをお勧めします。 ソフトウェア・ファイアウォールを介してストレージ・トラフィックを実行すると、待ち時間が増加し、ストレージ・パフォーマンスに悪影響を与えます。

File Storage for Classic トラフィックを独自の VLAN インターフェースにルーティングし、ファイアウォールをバイパスするにはどうすればよいですか?

この適切な方法を実行するには、次の手順を実行します。

1. ホストおよび File Storage for Classic と同じデータ・センターに VLAN をプロビジョンします。

2. 2 次プライベート・サブネットを新しい VLAN にプロビジョンします。

3. 新しい VLAN をホストのプライベート・インターフェースにトランクします。 このアクションは、VLAN がホストにトランクされている間、短時間ホスト上のネットワーク・トラフィックを中断します。

4. ネットワーク・インターフェースを作成します。

   • Linux® ホストで、 802.11q インターフェースを作成します。 新しくトランクされた VLAN から未使用の 2 次 IP アドレスの 1 つを選択し、その IP アドレス、サブネット・マスク、ゲートウェイを新しい 802.11q インターフェースに割り当てます。
   • VMware® で、新しい VMkernel ネットワーク・インターフェイス（vmk）を作成し、新しくトランク化された VLAN の未使用のセカンダリ IP アドレス、サブネット・マスク、ゲートウェイ IP を新しい vmk インターフェイスに割り当てる。

5. ターゲット NFS サブネットへの新しい永続的な静的ルートをホストに追加します。

6. 新規 IP がストレージにアクセスすることを許可します。

7. マウント指示については、ホストのホスト・オペレーティング・システムに応じて、次のうち該当するリンクを使用します。

   • Linux® での File Storage for Classic へのアクセス
   • CentOS へのFile Storage for Classicのマウント
   • ESXi ホストでの File Storage for Classic ボリュームのマウント

File Storage for Classic にどれくらいのパフォーマンス待ち時間を見込めばよいでしょうか?

ストレージ内の目標待ち時間は 1 ミリ秒未満です。ストレージは共有回線網上のコンピューティング・インスタンスに接続するため、正確なパフォーマンス待ち時間は、操作時のネットワーク・トラフィックに依存します。

File Storage for Classic シェアが削除された場合、データはどうなりますか？

IBM Cloud® File Storage for Classic では、お客様に対して物理ストレージ上のファイル共有が提供されます。この物理ストレージは再使用前にワイプされます。

File Storage for Classic ボリュームを削除すると、そのデータは即時にアクセス不能になります。 その物理ディスク上のデータを指すポインターはすべて削除されます。 後に同じアカウントまたは別のアカウントで新しいボリュームを作成する場合には、新しいポインターのセットが割り当てられます。 物理ボリューム上に過去に存在していたデータにそのアカウントでアクセスしようとしても、それらのポインターは削除されているため、アクセスできません。 新しいデータがディスクに書き込まれると、削除済みのボリュームのアクセス不能なデータは上書きされます。

IBM は、削除されたデータがアクセス不能になることと、削除されたデータが最終的に上書きされて消去されることを保証します。 さらに、お客様がストレージ・ボリュームを削除した場合、ストレージがお客様または別のお客様によって再使用可能になる前に、共有が上書きされる必要があります。

IBM が物理ドライブの使用を廃止する場合は、それらのドライブは破壊されたうえで処分されます。 廃止されたドライブは使用できなくなり、それらのドライブ上のデータはアクセス不能となります。

メディアのサニタイズに関する NIST 800-88 ガイドラインなどのコンプライアンスに関する特別な要件をお持ちのお客様は、ストレージを削除する前にデータのサニタイズ手順を実行できます。

「キャンセル」アクションがコンソールで使用できないのはなぜですか?

このストレージ・デバイスに関する取り消しプロセスが進行中なので、取り消しアクションを使用できなくなっています。 その量は、再生されるまで少なくとも24時間は目に見える形で残る。 UI に非アクティブであることが示され、ステータス「キャンセル保留中」が表示されます。 最低24時間の待機期間があるため、必要に応じてキャンセルリクエストを無効にすることができます。

ボリュームを誤って削除してしまいました

答えは、ストレージボリュームを削除したのが何年前か、すぐに削除するか記念日に削除するかによって異なります。 削除が過去24時間以内に行われた場合、または記念日がまだ来ていない場合、ボリュームはまだ取り戻されるのを待っているかもしれない。 ボリュームのステータスが「キャンセル待ち」になっている場合は、サポートに連絡してキャンセルリクエストを無効にすることができます。 再生期間が過ぎると、データは自動的に削除され、もはや復元することは不可能になるため、迅速に対応することが重要です。

サポートされている NFS バージョン

IBM Cloud® 環境では NFSv3 と NFSv4.1 の両方がサポートされます。 NFSv4.2 はサポートされていない。

可能な場合は、 NFSv3 プロトコルを使用してください。 NFSv3 は、安全な非同期書き込みをサポートし、以前の NFSv2よりもエラー処理でより堅固です。 64 ビットのファイル・サイズとオフセットをサポートするため、クライアントは 2 GB を超えるファイル・データにアクセスできます。

NFSv3 rootクライアントが 共有上のrootパーミッションを保持できるようにする をネイティブにサポートする。 NFS no_root_squash この機能は、ドメイン情報を編集し、 rpcidmapd または同様のサービスを実行することで、 NFSv4.1 で有効にすることができる。 詳しくは、NFS 用の no_root_squash の実装を参照してください。

VMware® デプロイメントで File Storage for Classic を使用する場合は、実装に NFSv4.1 を選択することをお勧めします。 詳細については 、「 NFS を VMware vSphere で実行するためのベストプラクティス 」を参照してください。

VMware 展開における複数のホストで、異なる NFS プロトコルを使用している場合、同じファイル共有にアクセスできますか？

いいえ 異なる NFS バージョンを使用して、同じデータストアを複数のホストにマウントすることはできません。 NFS 3と NFS 4.1 のクライアントは同じロックプロトコルを使用していないためです。 互換性のない2つのクライアントから同じ仮想ディスクにアクセスすると、予期せぬ動作やデータの破損につながる可能性があります。 詳しくは、 NFS ファイル・ロックを参照。

VMware デプロイメントで VAAI および HW アクセラレーションを有効にできますか?

いいえ 現時点では、vStorage for API Array Integration および ハードウェア・アクセラレーションはサポートされていません。

クラウド・データ・センターから使用禁止にされたドライブはどうなりますか?

ドライブが使用禁止になると、IBM は、それらのドライブが処分される前に、破棄します。 ドライブは使用できなくなります。 ドライブに書き込まれたすべてのデータにアクセスできなくなります。

制御されたフェイルオーバーと即時のフェイルオーバーの違いは何ですか?

制御されたフェイルオーバーでは、ミラーリングのプロセスが中断される前に最後の 1 回の同期が行われます。 即時のフェイルオーバーでは、ミラーリングが即時に中断して、レプリカ・ボリュームがアクティブになります。

ストレージがオフラインまたは読み取り専用になっているように見えます。 これが起こる理由と、修正する方法について教えてください。

いくつかのシナリオでは、ホスト（ベアメタルまたはVM）がストレージへの接続を一時的に失うことがあり、その結果、ホストはデータの破損を避けるためにそのストレージを読み取り専用と見なす。 ほとんどの場合、接続の切断はネットワークに関連したものですが、ネットワーク接続が復元された場合でも、ホストの観点からするとストレージの状況は読み取り専用のままになります。

この問題は、ネットワークに接続された VMware® データストア（ NFS プロトコル）上のVMの仮想ドライブで発生します。 解決するには、ストレージとホスト間のネットワークパスが明確であること、メンテナンスまたは停電が進行中でないことを確認します。 その後、ストレージ・ボリュームをアンマウントしてからマウントします。 ボリュームが引き続き読み取り専用になっている場合は、ホストを再始動します。

マウントの指示について詳しくは、以下のトピックを参照してください。

• CentOS へのFile Storage for Classicのマウント
• ESXi ホストでの File Storage for Classic のマウント
• Red Hat Linux® への File Storage for Classic のマウント
• Ubuntu へのFile Storage for Classic のマウント

このような事態の再発を防ぐために、顧客は次のような対応を検討するとよいだろう：

• ゲスト OS チューニングの追加。 詳細については、 VMware® vSphere 展開におけるゲスト OS のチューニングに関する NetApp's 推奨事項を参照してください。
• NFSv3 に NFSv4.1 を使用するホスト・システムの再構成。これにより、保守操作中の回復力を高めます。
• VMware® ESXiを実行するホストシステムでのセッショントランキングの停止。 セッション・トランキングはサポートされておらず、中断を引き起こす可能性があることが知られています。

Cloud コンソールを使用して File Storage for Classic のボリューム・サイズを拡張しましたが、サーバーのサイズが同じままです。 これを解決するにはどうしたらよいですか?

拡張されたボリューム・サイズを確認するには、既存のFile Storage for Classic のディスクをサーバーにマウントしてから再マウントします。 VMware® 実装では、ストレージを再スキャンして VMware® データストアをリフレッシュし、新しいボリューム・サイズを表示します。

シャーシ交換後にどのようにストレージを再接続できますか?

スワップ後にストレージを接続するには、次のタスクを実行します。

1. ストレージ・デバイスから認証を削除し（アクセスを取り消し）、ホストに再度認証を行う。
2. 再認証で得た新しい認証情報を使って、ストレージ・デバイスを再度検出する。

詳しくは、File Storage for Classic の管理を参照してください。

ホストから自分のストレージ・デバイスを切断するにはどうすればよいですか?

ホストからボリュームを切断するには、以下のステップを実行します。

1. デバイスをアンマウントします。
2. Cloud コンソールのストレージ・デバイスからホストのアクセス権を取り消します。
3. NFS 接続から自動マウントを削除します。

エンデュランス・ストレージとパフォーマンス・ストレージにはどのような違いがありますか?

エンデュランスとパフォーマンスは、ストレージ・デバイスに関して選択できるプロビジョニング・オプションです。 つまり、エンデュランス IOPS 層は事前定義されたレベルのパフォーマンスを提供し、パフォーマンス層ではこれらのレベルを細かく調整できます。 ストレージには同じデバイスが使用されるが、異なるオプションが提供される。 詳しくは、 File Storage 機能を参照。

File Storage for Classic 共有を Windows に接続できますか?

いいえ Microsoft Windows に IBM Cloud® File Storage for Classic 共有をマウントすることはできません。 Windows 環境の NFS は、 IBM Cloud®ではサポートされていません。

File Storage for Classic 共有は、 Linux オペレーティング・システムにマウントすることも、ESXi ホスト上の VMware® データ・ストアとしてマウントすることもできます。 File Storage for Classic ボリュームのマウントについて詳しくは、以下のトピックを参照してください。

• Red Hat Linux® への File Storage for Classic のマウント
• CentOS へのFile Storage for Classicのマウント
• Ubuntu へのFile Storage for Classic のマウント
• File Storage for Classic を ESXi ホスト上の VMware® データストアとしてマウントする

IBM Cloud 内の複数のホストに単一のストレージ・デバイスをマウントできますか?

はい、NFS はファイル対応プロトコルであるため、この設定を使用できます。

NFS ボリュームの i ノードを増やすことはできますか?

通常、ボリュームをプロビジョンすると、注文したサイズの最大 i ノード数がボリュームに割り当てられます。 最大inode数は、ボリュームの成長とともに自動的に増加する。 ボリュームを拡張してもinode数が増えない場合は、 サポート・ケースを提出してください。

ストレージをアップグレードできません。 ストレージのアップグレードまたは拡張を行うにはどの機能が関係していますか?

以下の状況は、ストレージをアップグレードまたは拡張する機能に影響を与える可能性があります。

• Cloud コンソールで持っている権限が要因になる場合があります。 詳細については、「 ユーザの役割と権限 」のトピックを参照してください。

ストレージのアップグレードは、ボリューム上のデータに影響しますか？

いいえ ストレージボリュームの拡張やIOPS値の調整を選択しても、その変更はデータに影響を与えません。 これらの操作中、上書きやワイプは一切行われない。 この調整によって、ストレージにアクセスできなくなったり、停止したりすることはない。

File Storage for Classic ボリュームは、シン・プロビジョンまたはシック・プロビジョンのどちらですか?

すべてのブロックおよび File Storage for Classic サービスは、シン・プロビジョンされています。 この方式を変更することはできません。

請求 ID が変更されました。これはどういう意味ですか?

ご使用のストレージ・ボリュームが、「エンタープライズ・ストレージ」ではなく「エンデュランス・ストレージ・サービス」または「パフォーマンス・ストレージ・サービス」として請求されるようになったことに気付く場合があります。 コンソールには、IOPS を調整したり容量を増やしたりする機能などの新しいオプションもあります。 IBM Cloud® は、ストレージ機能の継続的な改善に努めています。 データセンターでハードウェアがアップグレードされると、そのデータセンターにあるストレージ・ボリュームもアップグレードされ、強化されたすべての機能が使えるようになる。 ストレージ・ボリュームの料金は、このアップグレードでは変更されません。

File Storage for Classicの耐久性はどの程度ですか?

File Storage for Classicに保管したデータは、暗号化され、耐久性、可用性にも優れます。 単一の可用性ゾーンの耐久性目標は 99.999999999% (11ナイン) です。 詳しくは、File Storage for Classic の可用性と耐久性を参照してください。

File Storage for Classic の平均アップタイムはどのくらいですか?　

File Storage for Classicに保管したデータは、暗号化され、耐久性、可用性にも優れます。 File Storage は、クラス最高の実績あるエンタープライズグレードのハードウェアとソフトウェアに基づいて構築されており、高い可用性とアップタイムを提供します。 99.999 %（9が5つ）という可用性目標を確実に達成するため、データはHAペアノード上の複数の物理ディスクに冗長化して保存される。 各ストレージ・ノードには、独自のソリッド・ステート・ドライブおよびそのパートナー・ノードの SSD への複数のパスがあります。 このセットアップにより、パスの障害だけでなく、コントローラーの障害からも保護される。 詳しくは、File Storage for Classic の可用性と耐久性を参照してください。

サポートチームからストレージのパフォーマンス指標（IOPSやレイテンシー）を入手できますか？

IBM Cloud® は、ストレージ・パフォーマンス IOPS および待ち時間のメトリックを提供しません。 お客様は、ご自分で選択したサード・パーティー・モニター・ツールを使用して、ご自身の File Storage for Classic デバイスをモニターする必要があります。

以下の例は、パフォーマンス統計をチェックするために使用するとよいユーティリティです。

• sysstat- Linux® オペレーティング・システム用のシステム・パフォーマンス・ツール。
• typeperf-パフォーマンス・データをコマンド・ウィンドウまたはログ・ファイルに書き込む Windows コマンド。
• esxtop- VMware® vSphere 環境でのリソース使用量に関するリアルタイム情報を管理者に提供するコマンド・ライン・ツール。 すべてのシステム・リソース (CPU、メモリー、ディスク、およびネットワーク) のデータのモニターおよび収集ができます。

レプリカ・ボリューム、従属ボリューム、および独立した複製ボリュームの違いは何ですか?

ボリュームのスナップショットを使用して、レプリカまたは複製ボリュームを作成できます。 複製とクローン作成では、スナップショットの 1 つを使用してデータを宛先ボリュームにコピーします。 しかし、それは類似点が終わるところです。

レプリケーションによって、データは 2 つの異なる場所で同期されます。 一度にアクティブにできるのは、ペアの 1 つのボリューム (1 次ボリュームまたはレプリカ・ボリューム) のみです。 複製プロセスでは、複製スケジュールに基づいて、アクティブ・ボリュームから非アクティブ・ボリュームに情報が自動的にコピーされます。 レプリカ・ボリュームについて詳しくは、 データの複製 を参照してください。

複写により、親ボリュームと同じアベイラビリティー・ゾーン内のスナップショットに基づいてボリュームのコピーが作成されます。 複製ボリュームは元のボリュームの容量とパフォーマンスのオプションをデフォルトで継承し、スナップショットの特定時点までのデータの複製を保管します。 複製ボリュームは、元のボリュームに従属したり、元のボリュームから独立したりすることができます。また、親ボリュームからのデータを使用して手動で更新することができます。 親ボリュームに影響を与えることなく、IOPS を調整したり、重複のボリューム・サイズを増やしたりすることができます。

• 従属複製ボリュームは、独立した状態に変換されることはなく、作成後はいつでもリフレッシュできます。 元のスナップショットをロックして、従属する重複が存在している間はスナップショットを削除できないようにします。 従属する重複ボリュームが存在する間は、親ボリュームを取り消すことはできません。 親ボリュームを取り消したい場合は、最初に従属複製を取り消すか、独立複製に変換する必要があります。

• 独立した複製は、ほとんどの場合、従属する複製より優れていますが、作成直後に更新することはできません。これは、変換処理に時間がかかるためです。 ボリュームのサイズによっては、最大で数時間かかることがあります。 例えば、12 TB ボリュームの場合、最大 1 日かかることがあります。 ただし、分離プロセスの完了後に、元の親ボリュームの別のスナップショットを使用して、データを手動でリフレッシュすることができます。

重複について詳しくは、 重複ボリュームの作成と管理 を参照してください。

異なるタイプのボリュームコピー間の機能比較。
この表には行および列の見出しがあります。 行ヘッダーは機能を示します。 列見出しは、ボリューム・コピーのタイプを識別します。

特長	レプリカ	従属の重複	独立した重複
スナップショットから作成
コピーされたボリュームのロケーション	リモート・アベイラビリティー・ゾーン	同じアベイラビリティー・ゾーン	同じアベイラビリティー・ゾーン
フェイルオーバーをサポート
サイズと IOPS が異なる
親ボリュームと自動同期されました
親ボリュームからのオンデマンド・リフレッシュ		[1]	[2]
親ボリュームから分離

従属複製を独立ボリュームに変換するのにどのくらいの時間がかかりますか?

変換処理には時間がかかることがあります。 ボリュームが大きいほど、変換にかかる時間が長くなります。 12-TB ボリュームでは、24 時間かかる場合があります。 進行状況はコンソールまたは CLI から確認できます。

• コンソールで Classic Infrastructureに進む。 「ストレージ」 > File Storage for Classic をクリックして、リストからボリュームを見つけます。 変換状況は「概要」ページに表示されます。

• CLIから以下のコマンドを使用する。

  slcli file duplicate-convert-status <dependent-vol-id>
  

  出力は、次の例と同様になります。

  slcli file duplicate-convert-status 370597202
  Username            Active Conversion Start Timestamp   Completed Percentage
  SL02SEVC307608_74   2022-06-13 14:59:17                 90
  

ユーザーの権限とアクセスを管理するにはどうすればよいですか？

アカウント所有者、または「ユーザークラシックインフラストラクチャの管理」権限を持つユーザーは、 IBM Cloud アカウント内の他のユーザーの権限を調整することができます。 アカウントの所有者でない場合は、すでに割り当てられている権限のレベルまたは権限の一部のみを割り当てることができます。 IBM Cloud コンソールで、「 管理」>「アクセス（IAM）」>「ユーザー 」と進む。 次に、リストからアクセスを管理できるユーザー名を選択し、 Classic infrastructureをクリックします。 ユーザーにストレージの追加とアップグレードを許可するアカウント権限を選択します。 詳しくは、『クラシック・インフラストラクチャー・アクセス権限の管理』を参照してください。

ファイルストレージが準備されたら、ホストサーバーがファイル共有をマウントできるように権限を与える必要があります。 認証は、コンソール、CLI、API、またはTerraformで設定できます。 詳細は、 File Storage for Classicの 「ホストの認証」セクションをご覧ください。

ホストが認証された後、ファイル共有をマウントし、新しいフォルダ構造とファイルの所有者を割り当てることができます。 Linux では、 chown と chmod コマンドを使用して、個々のユーザーやグループに読み取り、書き込み、実行の権限を割り当てることで、アクセス制御をさらに厳密にすることができます。 詳細については、 Red Hat Linux® での File Storage for Classic のマウント」 および 「 Ubuntu での File Storage for Classic のマウント」を 参照してください。