翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 論理ディレクトリの実装
<a name="implement-log-dirs"></a>

**重要**  
**ルートディレクトリの要件**
Amazon S3 のパフォーマンス最適化設定を使用していない場合は、起動時にルートディレクトリが存在している必要があります。
Amazon S3 の場合、これはスラッシュ () で終わるゼロバイトのオブジェクトを作成することを意味します`/`。
この要件を回避するには、サーバーを作成または更新するときに Amazon S3 のパフォーマンス最適化を有効にすることを検討してください。
LOGICAL HomeDirectory HomeDirectoryType を指定する場合、値は論理ディレクトリマッピングのいずれかにマッピングする必要があります。サービスは、ユーザーの作成時と更新時の両方でこれを検証し、機能しない設定を防止します。
**論理ホームディレクトリ設定**
HomeDirectoryType として LOGICAL を使用する場合は、次の点に注意してください。  
HomeDirectory 値は、既存の論理ディレクトリマッピングのいずれかに対応する必要があります。
システムは、ユーザーの作成と更新時にこれを自動的に検証します。
この検証により、アクセスの問題を引き起こす設定が防止されます。

## 論理ディレクトリを有効にする
<a name="enable-log-dirs-small"></a>

ユーザーの論理ディレクトリを使用するには、 `HomeDirectoryType`パラメータを に設定します`LOGICAL`。これは、新しいユーザーを作成するとき、または既存のユーザーを更新するときに行います。

```
"HomeDirectoryType": "LOGICAL"
```

## ユーザー`chroot`に対して を有効にする
<a name="chroot"></a>

**chroot** の場合、ユーザーごとに単一の `Entry` と `Target` のペア構成されるディレクトリ構造を作成します。エントリ **/** はルートフォルダを表し、**ターゲット**はバケットまたはファイルシステムの実際の場所を指定します。

------
#### [ Example for Amazon S3 ]

```
[{"Entry": "/", "Target": "/amzn-s3-demo-bucket/jane"}]
```

------
#### [ Example for Amazon EFS ]

```
[{"Entry": "/", "Target": "/fs-faa1a123/jane"}]
```

------

前の例のように絶対パスを使うこともできるし、次の例のようにユーザー名を `${transfer:UserName}` でダイナミックに置換できます。

```
[{"Entry": "/", "Target":
"/amzn-s3-demo-bucket/${transfer:UserName}"}]
```

前の例では、ユーザーはルートディレクトリにロックされ、階層の上位には移動できません。

## 仮想ディレクトリ構造
<a name="virtual-dirs"></a>

仮想ディレクトリ構造の場合、S3 バケットまたは EFS ファイルシステム内の任意の場所にあるターゲットと組み合わせて複数の `Entry` `Target` ペアを作成でき、ユーザーの IAM ロールマッピングがそれらにアクセスする権限を持つ限り、複数のバケットまたはファイルシステムにわたっても可能です。

次の仮想構造の例では、ユーザーが SFTP AWS にログインすると、、`/pics`、、`/doc``/reporting`および のサブディレクトリを持つルートディレクトリにあります`/anotherpath/subpath/financials`。

**注記**  
Amazon S3 ディレクトリのパフォーマンスを最適化することを選択しない限り (サーバーを作成または更新するとき）、ユーザーまたは管理者がディレクトリが存在しない場合は作成する必要があります。この問題を回避することは、Amazon S3 のパフォーマンスの最適化を検討する理由です。  
Amazon EFS の場合、管理者は論理マッピングまたは `/` ディレクトリを作成する必要があります。

```
[
{"Entry": "/pics", "Target": "/amzn-s3-demo-bucket1/pics"}, 
{"Entry": "/doc", "Target": "/amzn-s3-demo-bucket1/anotherpath/docs"},
{"Entry": "/reporting", "Target": "/amzn-s3-demo-bucket2/Q1"},
{"Entry": "/anotherpath/subpath/financials", "Target": "/amzn-s3-demo-bucket2/financials"}]
```



**注記**  
 ファイルは、マップした特定のフォルダにのみアップロードできます。つまり、前の例では、`/anotherpath` または `anotherpath/subpath` ディレクトリにはアップロードできず、`anotherpath/subpath/financials` のみが可能です。また、重複するパスは許可されないため、これらのパスに直接マップすることはできません。  
 たとえば、次のマッピングを作成するとします。  

```
{
   "Entry": "/pics", 
   "Target": "/amzn-s3-demo-bucket/pics"
}, 
{
   "Entry": "/doc", 
   "Target": "/amzn-s3-demo-bucket/mydocs"
}, 
{
   "Entry": "/temp", 
   "Target": "/amzn-s3-demo-bucket2/temporary"
}
```
 ファイルは、それらのバケットのみにアップロードできます。`sftp` を通して初めて接続すると、ルートディレクトリ (`/`) の階層まで落ちます。そのディレクトリにファイルをアップロードしようとすると、アップロードは失敗します。次のコマンドは、シーケンスの例を示しています。  

```
sftp> pwd
Remote working directory: /
sftp> put file
Uploading file to /file
remote open("/file"): No such file or directory
```
任意の `directory/sub-directory` にアップロードするには、パスを `sub-directory` に明示的にマップする必要があります。

ダウンロードして使用できる AWS CloudFormation テンプレートなど、論理ディレクトリと ユーザー**chroot**の設定の詳細については、 AWS ストレージブログの[「Chroot ディレクトリと論理ディレクトリを使用して AWS SFTP 構造を簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-aws-sftp-structure-with-chroot-and-logical-directories/)」を参照してください。