AWS Cloud9 は新規顧客には利用できなくなりました。 AWS Cloud9 の既存のお客様は、通常どおりサービスを引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# トラブルシューティング AWS Cloud9
以下の情報を使用して、 の問題を特定して対処します AWS Cloud9。
該当する問題が以下に示されていない場合や、追加のヘルプが必要な場合は、[AWS Cloud9 ディスカッションフォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=268)を参照してください。このフォーラムにアクセスするには、サインインが必要になることがあります。当社に直接[お問い合わせ](https://aws.amazon.com/contact-us/)いただくこともできます。
**Topics**
+ [Installer (インストーラ)](#troubleshooting-installer-group)
+ [AWS Cloud9 環境](#troubleshooting-environment-group)
+ [Amazon EC2](#troubleshooting-ec2-group)
+ [その他の AWS サービス](#troubleshooting-other-services-group)
+ [アプリケーションプレビュー](#troubleshooting-preview-group)
+ [パフォーマンス](#troubleshooting-performance-group)
+ [サードパーティのアプリケーションとサービス](#troubleshooting-third-party-group)
## Installer (インストーラ)
次のセクションでは、 AWS Cloud9 インストーラーに関連する問題のトラブルシューティングについて概説します。
### AWS Cloud9 インストーラがハングまたは失敗する
**問題:** [AWS Cloud9 インストーラをダウンロードして実行する](installer.md#installer-download-run)と、1 つ以上のエラーが発生し、インストーラスクリプトに が表示されません`Done`。
**原因:** AWS Cloud9 インストーラで復旧できないエラーが 1 つ以上発生し、その結果失敗します。
**解決策:** 詳細については、「[AWS Cloud9 インストーラのトラブルシューティング](installer.md#installer-troubleshooting)」を参照してください。一般的な問題、考えられる原因、および推奨される解決策を参照してください。
### AWS Cloud9 「Package Cloud9 IDE 1」と表示してもインストーラが終了しない
**Issue:** AWS Cloud9 SSH 開発環境を作成するプロセスの一環として、既存の Amazon EC2 インスタンスまたは独自のサーバーにインストールされます。［**AWS Cloud9 インストーラ**］ダイアログボックスに「Package Cloud9 IDE 1」というメッセージが表示されて、インストールが停止します。［**キャンセル**］を選択すると、「インストールに失敗しました」というメッセージが表示されます。このエラーは、お客様の SSH ホストに AWS Cloud9 パッケージをインストールできない場合に発生します。
**原因:** SSH ホストでは、Node.js がインストールされている必要があります。ホストのオペレーティングシステムでサポートされている最新の Node.js バージョンをインストールすることをお勧めします。がサポート AWS Cloud9 していないバージョンの がホストNode.jsにある場合、インストールエラーが発生する可能性があります。
**推奨される解決策:** AWS Cloud9 がサポートする **Node.js** のバージョンを SSH ホストにインストールします。
### 依存関係をインストールできませんでした
**問題:** AWS Cloud9 依存関係をダウンロードするにはインターネットアクセスが必要です。
**考えられる原因:**
+ AWS Cloud9 環境がプロキシを使用してインターネットにアクセスしている場合、依存関係をインストールするにはプロキシの詳細 AWS Cloud9 が必要です。プロキシの詳細を に提供しなかった場合 AWS Cloud9は、このエラーが表示されます。
+ 別の原因としては、環境がアウトバウンドトラフィックを許可していないことが考えられます。
**推奨される解決策:**
+ プロキシの詳細を に提供するには AWS Cloud9、環境`~/.bashrc`ファイルに次のコードを追加します。
```
export http_proxy=[proxy url for http]
export https_proxy=[proxy url for https]
#Certificate Authority used by your proxy
export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]
```
例えば、HTTP プロキシ URL が `https://172.31.26.80:3128` で、HTTP プロキシ URL が `https://172.31.26.80:3129` である場合、次の行を `~/.bashrc` ファイルに追加し、`NODE_EXTRA_CA_CERTS` を PEM 形式で認証機関のパスに設定します。この変数の詳細については、「[https://nodejs.org/api/cli.html#node_extra_ca_certsfile](https://nodejs.org/api/cli.html#node_extra_ca_certsfile)」を参照してください。
```
export http_proxy=http://172.31.26.80:3128
export https_proxy=https://172.31.26.80:3129
export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]
```
+ no-ingress Amazon EC2 インスタンスを使用している場合は、Amazon S3 の Amazon VPC エンドポイントが設定されていることを確認する必要があります。詳細については、「[Amazon S3 のダウンロード依存関係に対応する Amazon VPC エンドポイントの設定](https://docs.aws.amazon.com/cloud9/latest/user-guide/ec2-ssm.html#configure-s3-endpoint)」を参照してください。
### SSH 環境エラー: 「pty.js をインストールするには Python バージョン 3 が必要です」
**問題:** SSH AWS Cloud9 開発環境を開くと、IDE AWS Cloud9 のターミナルに「pty.js のインストールには Python バージョン 3 が必要です」で始まるメッセージが表示されます。
**原因:** SSH 環境が意図したとおりに動作するには、Python バージョン 3 がインストールされている必要があります。
**解決策:** 環境に Python バージョン 3 をインストールします。バージョンを確認するには、サーバーのターミナルからコマンド **`python --version`** を実行します。サーバーに Python 3 をインストールする方法については、次のいずれかを参照してください。
+ *Python サンプル*の [ステップ 1: Python をインストールする](sample-python.md#sample-python-install)。
+ Python のウェブサイトから [Python をダウンロード](https://www.python.org/downloads/)します。
## AWS Cloud9 環境
次のセクションでは、 AWS Cloud9 環境に関連する問題のトラブルシューティングについて概説します。
### 環境の作成エラー:「EC2 インスタンスを作成することができません ...」
**問題:** AWS Cloud9 開発環境を作成しようとすると、「アカウントの検証とアクティベーション中にアカウントに EC2 インスタンスを作成できません」というメッセージが表示されます。
**原因:** AWS は現在、 を検証してアクティブ化しています AWS アカウント。アクティベーションが完了するまで (最大 24 時間かかる場合があります)、この環境やその他の環境を作成することはできません。
**解決策:** 後で環境をもう一度作成してみてください。24 時間経ってもこのメッセージが届く場合は、[サポート](https://support.aws.amazon.com/#/contacts/aws-account-verification)にお問い合わせください。さらに、重要な留意事項として、環境を作成する試行が失敗しても、 AWS CloudFormation はアカウントに関連スタックを作成します。これらのスタックは、アカウントのスタック作成クォータにカウントされます。スタック作成クォータの消費を避けるために、これらの失敗したスタックを削除できます。詳細については、「AWS CloudFormation ユーザーガイド」**の「[AWS CloudFormation コンソールのスタックを削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」を参照してください。
### 環境作成エラー: 「sts:AssumeRole を実行する権限がありません」
**問題:** 新しい環境を作成しようとすると、エラー「sts:AssumeRole を実行する権限がありません」が表示され、環境が作成されません。
**考えられる原因:** AWS Cloud9 サービスにリンクされたロールが に存在しません AWS アカウント。
**推奨される解決策:** で AWS Cloud9 サービスにリンクされたロールを作成します AWS アカウント。これを行うには、次のコマンドを AWS Command Line Interface (AWS CLI) または AWS CloudShellで実行できます。
```
aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the AWS CLI.
iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the aws-shell.
```
これができない場合は、 AWS アカウント 管理者に確認してください。
このコマンドを実行した後、もう一度環境の作成を試します。
### フェデレーティッドアイデンティティで環境を作成できない
**問題:** AWS フェデレーティッド ID を使用して AWS Cloud9 開発環境を作成しようとすると、アクセスエラーメッセージが表示され、環境は作成されません。
**原因:** : サービスにリンクされたロール AWS Cloud9 を使用します。サービスにリンクされたロールは、`iam:CreateServiceLinkedRole` コールを使用してアカウントで初めて環境を作成したときに作成されます。ただし、フェデレーティッドユーザーは IAM API を呼び出すことができません。詳細については、*AWS Security Token Service API リファレンス*の「[GetBucketEncryption](https://docs.aws.amazon.com/STS/latest/APIReference/API_API_GetFederationToken.html)tak」を参照してください。
**解決策:** IAM コンソールで AWS Cloud9 、または AWS Command Line Interface (AWS CLI) でこのコマンドを実行して、 のサービスにリンクされたロールを作成するように AWS アカウント 管理者に依頼します。
```
aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com
```
または、 AWSシェルを使用して次のコマンドを実行します。
```
iam create-service-linked-role --aws-service-name cloud9.amazonaws.com
```
詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの使用」を参照してください。[https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)**
### コンソールエラー: 「ユーザーにはリソースでアクションを実行する権限がありません」
**問題:** AWS Cloud9 コンソールを使用して AWS Cloud9 開発環境を作成または管理しようとすると、「User `arn:aws:iam::123456789012:user/MyUser` is not authorized to perform `cloud9:action` on resource `arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1`」のようなフレーズを含むエラーが表示されます。
+ `arn:aws:iam::123456789012:user/MyUser` は、リクエストするユーザーの Amazon リソースネーム (ARN) です。
+ `action` は、ユーザーがリクエストしたオペレーションの名前です。
+ `arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1` は、ユーザーがオペレーションを実行するためにリクエストした環境の ARN です。
**原因:** AWS Cloud9 コンソールにサインインしたユーザーに、アクションを実行するための正しい AWS アクセス許可がありません。
**解決策:** ユーザーが正しい AWS アクセス許可を持っていることを確認して、もう一度アクションを実行してみます。詳細については次を参照してください:
+ *チーム設定*の [ステップ 2: AWS Cloud9 グループにアクセス許可を追加する](setup.md#setup-give-user-access)
+ *エンタープライズセットアップ* の [ステップ 6. 組織内のグループとユーザーが を使用できるようにする AWS Cloud9](setup-enterprise.md#setup-enterprise-groups-users-access)
+ *共有環境を使用する*の [環境メンバーのアクセスロールについて](share-environment.md#share-environment-member-roles)
### 環境に接続できない
**問題:** ユーザーは環境に接続できず、接続段階で行き詰まっています。
**原因:** `~/ .ssh/authorized_keys`ファイルのアクセス許可を変更したり、そのファイルから AWS Cloud9 キーを削除したり、ファイルを完全に削除したりすると、この問題が発生する可能性があります。
**解決策:** このファイルを削除しないでください。削除した場合は、環境を再作成して、既存の環境の [EBS ボリューム](move-environment.md#move-environment.title)を新しい EC2 環境にアタッチする必要があります。これにより、失われたデータが取得されます。アクセス許可が足りない場合は、ファイルに `Read-Write` アクセス許可があることを確認してください。これにより、SSH デーモンがファイルを読み取れるようにします。
### 環境を開くことができない
**問題:** 環境を開こうとすると、IDE が 5 分以上表示されません。
**考えられる原因:**
+ AWS Cloud9 コンソールにサインインしている IAM ユーザーには、環境を開くために必要な AWS アクセス許可がありません。
+ 環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合、次の可能性があります。
+ インスタンスに関連付けられている VPC が正しく設定されていません AWS Cloud9。
+ がインスタンスに接続しようとしているときに、インスタンスが状態間で移行しているか AWS Cloud9 、自動ステータスチェックに失敗しています。
+ 環境が SSH 環境の場合、関連付けられたクラウドコンピューティングインスタンスまたは独自のサーバーが、 AWS Cloud9 がアクセスできるように正しく設定されていません。
**推奨される解決策:**
+ AWS Cloud9 コンソールにサインインしている IAM ユーザーに、環境を開くために必要な AWS アクセス許可があることを確認します。その後、もう一度環境を開いてみてください。詳細については、以下を参照するか、 AWS アカウント 管理者にお問い合わせください。
+ *チームセットアップ*の [ステップ 2: AWS Cloud9 グループにアクセス許可を追加する](setup.md#setup-give-user-access)
+ *認証とアクセスコントロール*の [AWS の マネージドポリシー AWS Cloud9](security-iam.md#auth-and-access-control-managed-policies)
+ *アドバンストチーム設定*の [を使用するチームのカスタマー管理ポリシーの例 AWS Cloud9](setup-teams-policy-examples.md)
+ *認証とアクセスコントロール*の [お客様のマネージドポリシーの例](security-iam.md#auth-and-access-control-customer-policies-examples)
+ 「*IAM ユーザーガイド*」の「[IAM ユーザーのアクセス許可の変更](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html)」を参照してください。
+ 「IAM ユーザーガイド」**の「[IAM ポリシーのトラブルシューティング](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html)」
サインインした IAM ユーザーがまだ環境を開くことができない場合は、サインアウトしてから、アカウントの AWS アカウント ルートユーザーまたは管理者ユーザーとしてサインインし直してみてください。その後、もう一度環境を開いてみてください。この方法で環境を開くことができない場合は、IAM ユーザーのアクセス許可に問題がある可能性が最も大です。
+ 環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合は、次の操作を行います。
+ インスタンスに関連付けられている VPC が正しい設定になっていることを確認し AWS Cloud9、もう一度環境を開いてください。詳細については、「[の Amazon VPC 要件 AWS Cloud9](vpc-settings.md#vpc-settings-requirements)」を参照してください。
AWS クラウドコンピューティングインスタンスに関連付けられている VPC が の正しい設定に設定 AWS Cloud9 されていても環境を開くことができない場合、インスタンスのセキュリティグループが へのアクセスを妨げている可能性があります AWS Cloud9。**トラブルシューティングの手法としてのみ**、セキュリティグループをチェックして、少なくともポート 22 経由のインバウンド SSH トラフィックがすべての IP アドレス (`Anywhere` または `0.0.0.0/0`) について許可されていることを確認してください。指示については、「Amazon EC2 ユーザーガイド」[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#describing-security-group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#describing-security-group)の「[セキュリティグループについて説明する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#updating-security-group-rules)」および「*セキュリティグループルールを更新する*」を参照してください。
追加の VPC トラブルシューティングの手順については、関連する 5 分間の動画「[AWS ナレッジセンターの動画: VPC 内のインスタンスに接続できない場合の確認点とは?](https://www.youtube.com/watch?v=--BoDeCF5Dw)」を YouTube でご覧ください。
**警告**
トラブルシューティングが完了したら、インバウンドルールを適切なアドレス範囲に設定してください。詳細については、「[のインバウンド SSH IP アドレス範囲 AWS Cloud9](ip-ranges.md)」を参照してください。
+ インスタンスを再起動して、インスタンスが動作していること、およびすべてのシステムチェックをパスしていることを確認してから、もう一度環境を開いてみます。詳細については、*Amazon EC2 ユーザーガイド*で「[インスタンスの再起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html)」と「[ステータスチェックの表示](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#viewing_status)」を参照してください。
+ 環境が SSH 環境の場合は、環境に関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが正しく設定され、 AWS Cloud9 が環境にアクセスできることを確認してください。その後、もう一度環境を開いてみてください。詳細については、「[SSH 環境ホスト要件](ssh-settings.md)」を参照してください。
### AWS Cloud9 環境を開くことができません：「この環境には現在共同作業者がアクセスできません。マネージド一時認証情報の削除が完了するまでお待ちください。または、この環境の所有者にお問い合わせしてください。」
**問題:** 環境所有者ではないユーザーが新しい共同作業者を環境に追加すると、 AWS マネージド一時認証情報は無効になります。`~/.aws/credentials` ファイルを削除すると、認証情報は無効になります。`~/.aws/credentials` ファイルの削除中、新しい共同作業者は AWS Cloud9 環境にアクセスできません。
**原因:** AWS マネージド一時認証情報の削除中に環境へのアクセスができないのは、セキュリティ対策です。これにより、環境所有者は、信頼できる共同作業者だけがマネージド認証情報報にアクセスできることを確認できます。共同作業者のリストが有効であることが確認できたら、環境所有者はマネージド認証情報を再度有効にして共有することができます。詳細については、「[AWS マネージド一時認証情報へのアクセスの制御](security-iam.md#temporary-managed-credentials-control)」を参照してください。
**推奨される解決策:** `~/.aws/credentials` ファイルが完全に削除されるまで待ってから、 AWS Cloud9 環境をもう一度開いてください。認証情報待機時間の有効期限は最大 15 分です。または、マネージド一時認証情報を再度有効または無効にするよう、環境所有者に依頼します。認証情報が再び有効または無効になると、共同作業者はすぐに環境にアクセスできます。マネージド認証情報の状態を ENABLED または DISABLED に切り替えることで、環境所有者は、認証情報が中間状態に残らないようにします。中間状態では、共同作業者が環境にアクセスできない可能性があります。
**注記**
環境所有者と共同作業者が同じ AWS アカウントに属しているとします。この場合、共同作業者は、コンソールの **[Your environments]** (自分の環境) ページで環境カードを確認し、連絡先の環境所有者を特定できます。環境所有者も、**環境の詳細**ページにあがっています。
### 環境の削除エラー:「1 つ以上の環境を削除できませんでした」
**問題:** AWS Cloud9 コンソールで 1 つ以上の環境を削除しようとすると、「1 つ以上の環境が削除に失敗した」というメッセージが表示され、少なくとも 1 つの環境は削除されません。
**考えられる原因:** AWS CloudFormation 1 つ以上の環境の削除に問題がある可能性があります。環境の作成と削除 CloudFormation は AWS Cloud9 に依存します。
**推奨される解決策:** CloudFormation を使用して、削除されていない各環境を削除してみてください。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。
1. AWS ナビゲーションバーで、環境 AWS リージョン の を選択します。
1. CloudFormation スタックのリストで、**スタック名**に削除されていない環境名が含まれ、**ステータス**が **DELETE\$1FAILED** であるエントリを選択します。たとえば、環境名が **my-demo-environment** の場合は、**aws-cloud9-my-demo-environment** を含む名前で始まるスタックを選択します。(環境名の横にあるボックスまたはオプションを選択してください。環境名自体は選択しないでください)。
1. **［アクション］、［スタックの削除］**の順に選択します。
1. プロンプトが表示されたら、［**はい、削除します**］を選択します。
スタックの削除処理には数分かかる場合があります。
スタックがリストから消えた場合、環境は削除されています。
数分たってもスタックに［**DELETE\$1FAILED**］と表示される場合、環境はまだ削除されていません。この場合、障害が発生した各スタックのリソースを手動で削除できます。
**注記**
失敗したスタックのリソースを手動で削除しても、スタック自体は から削除されません AWS アカウント。
これらのリソースを手動で削除するには、次の手順に従います。 CloudFormation コンソールで、失敗したスタックを選択し、**リソース**セクションを選択します。このリストの各リソース AWS の のコンソールに移動し、そのコンソールを使用してリソースを削除します。
### IDE AWS Cloud9 での環境のタイムアウト時間の変更
**問題:** ユーザーは Amazon EC2 環境のタイムアウト時間を更新したいと考えています。
**原因:** デフォルトのタイムアウト時間は 30 分です。これは一部のユーザーには短すぎるかもしれません。
**推奨される解決策:**
1. 設定する環境を開きます。
1. **[AWS Cloud9 IDE]** のメニューバーで、**[AWS Cloud9]**、**[設定]** の順に選択します。
1. **[設定]** ウィンドウで、**[Amazon EC2 インスタンス]** セクションまでスクロールします。
1. 使用可能なリストからタイムアウト値を選択し、更新します。
### AWS Cloud9 環境に十分なディスク容量がないため、 AWS Toolkit で SAM アプリケーションをローカルで実行中にエラーが発生しました
**問題:** Toolkit を使用して AWS SAM テンプレートで定義されたアプリケーションの AWS SAM CLI コマンドを実行すると、エラーが発生します。
**考えられる原因:** AWS Toolkit を使用してサーバーレスアプリケーションをローカルで実行およびデバッグすると、 はDockerイメージ AWS SAM を使用します。これらのイメージは、デプロイを計画している Lambda 環境をエミュレートするランタイム環境とビルドツールを構築します。
ただし、環境に十分なディスク容量がない場合、これらの機能を提供する Docker イメージは構築できず、ローカル SAM アプリケーションを実行できません。この問題が発生した場合は、**[Output]** (出力) タブに次のようなエラーが表示されることがあります、
```
Error: Could not find amazon/aws-sam-cli-emulation-image-python3.7:rapid-1.18.1 image locally and failed to pull it from docker.
```
このエラーは、Python ランタイムを使用して構築された SAM アプリケーションに関連します。アプリケーション用に選択したランタイムに応じて、若干異なるメッセージが表示される場合があります。
**推奨される解決策:** Docker イメージを構築できるように、環境内のディスク領域を解放します。IDE の端末で次のコマンドを実行して、未使用の Docker イメージを削除します。
```
docker image prune -a
```
ディスク容量の制限により SAM CLI コマンドで問題が繰り返して発生する場合は、開発環境に切り替えて別の[インスタンスタイプ](create-environment-main.md#create-environment-console)を使用します。
([先頭に戻ります](#troubleshooting))
### 古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードすることはできません
**問題:** Microsoft Edgeウェブブラウザを使用して IDE AWS Cloud9 をロードしようとすると、`HTTP403: FORBIDDEN`エラーが返されます。
**考えられる原因:** IDE AWS Cloud9 は、特定の古いバージョンの をサポートしていませんMicrosoft Edge。
**推奨される解決策:** ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンをクリックします。メニューで、**[Settings]** (設定) を選択して **[About Microsoft Edge]** ( について) を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。
([先頭に戻ります](#troubleshooting))
### IDE File Explorer でサブフォルダ構造 **/home/ec2-user/environment/home/ec2-user/environment** AWS Cloud9 を作成することはできません。
**問題:** IDE File Explorer でサブフォルダ構造 **/home/ec2-user/environment/home/ec2-user/environment** AWS Cloud9 を作成すると、このディレクトリを開くことができないことを示すエラーメッセージが表示されます。
**考えられる原因:** 現在、IDE のファイルシステムを使用して、同じ名前のフォルダ内にサブフォルダ構造 **/home/ec2-user/environment** AWS Cloud9 を作成することはできません。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにはアクセスできませんが、コマンドラインを使用してアクセスできます。この問題の影響を受けるのは **/home/ec2-user/environment/home/ec2-user/environment** のファイルパスだけです。**/test/home/ec2-user/environment** や **/home/ec2-user/environment/test** などのファイルパスは機能します。これは既知の問題であり、IDE File Explorer AWS Cloud9 にのみ影響します。
**推奨される解決策：** 別のファイル名と構造を使用してください。
([先頭に戻ります](#troubleshooting))
### CodeCatalyst の IDE の File Explorer 内にサブフォルダ構造 **/projects/projects** AWS Cloud9 を作成することはできません。
**問題:** CodeCatalyst の AWS Cloud9 IDE File Explorer でサブフォルダ構造 **/projects/projects** を作成すると、このディレクトリを開くことができないことを示すエラーメッセージが表示されます。
**考えられる原因:** 現在、CodeCatalyst の AWS Cloud9 IDE の File Explorer を使用して、同じ名前のフォルダ内にサブフォルダ構造**/プロジェクト**を作成することはできません。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにはアクセスできませんが、コマンドラインを使用してアクセスできます。この問題は **/projects/projects** のファイルパスにのみ影響します。**/test/projects** や **/projects/test** などのファイルパスは正常に機能します。これは既知の問題で、 AWS Cloud9 IDE ファイルエクスプローラーにのみ影響します。
**推奨される解決策：** 別のファイル名と構造を使用してください。
([先頭に戻ります](#troubleshooting))
### `tmux` セッションエラー AWS Cloud9 のため、 でターミナルウィンドウとやり取りできない
**問題:** で新しいターミナルウィンドウを起動しようとすると AWS Cloud9、予想されるコマンドラインインターフェイスは使用できません。コマンドプロンプトがないため、テキストを入力できません。`tmux: need UTF-8 locale (LC_CTYPE)` や `invalid LC_ALL, LC_CTYPE or LANG` などのエラーメッセージが返されます。
**考えられる原因:** tmux エラーが原因でターミナルが応答しない可能性があります。 は [tmux](https://en.wikipedia.org/wiki/Tmux) ユーティリティ AWS Cloud9 を使用します。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。
`tmux` セッションでは、ターミナルウィンドウの表示内容はクライアントによって処理されます。クライアントは、複数のセッションを管理できるサーバーと通信します。サーバーとクライアントは、`tmp` フォルダにあるソケットを介して通信します。開発環境に `tmp` フォルダがないか、過度に制限的なアクセス許可が適用されている場合、`tmux` セッションは実行できません。この場合、IDE のターミナルウィンドウは応答しなくなります。
**推奨される解決策**: `tmux` エラーによってターミナルウィンドウと対話できない場合は、別の方法を使用して適切な許可を持つ `tmp` フォルダを作成する必要があります。これにより、`tmux` セッションを実行できます。1 つの解決策は、`.bash_profile` または `.bashrc` ファイルの `LC_CTYPE` をエクスポートすることです。もう 1 つの推奨される解決策は、 AWS Systems Manager を使用してホスト管理設定をセットアップすることです。これにより、Amazon EC2 コンソールから該当するインスタンスにアクセスできるようになります。
**ホスト管理の設定**
1. まず、 AWS Cloud9 コンソールで、環境のインスタンスの名前を見つけます。これを行うには、**[Your environments]** (自分の環境) ページで該当するパネルを選択し、**[View details]** (詳細を表示) を選択します。[**環境の詳細**] ページで [**インスタンスに移動**] を選択します。Amazon EC2 コンソールで、アクセスする必要があるインスタンスの名前を確認します。
1. AWS Systems Manager コンソールに移動し、ナビゲーションペインで**クイックセットアップ**を選択します。
1. [**クイックセットアップ**] ページで [**作成**] を選択します。
1. [**設定タイプ**] では、[**ホスト管理**] に移動し、[**登録**] を選択します。
1. [**ホスト管理構成オプションのカスタマイズ**] の [**ターゲット**]セクションで、[**手動**]を選択します。
1. アクセスする EC2 インスタンスを選択してから、[**作成**] を選択します。
**インスタンスに接続してコマンドを実行する**
**注記**
次の手順は、新しい EC2 コンソール用です。
1. Amazon EC2 コンソールのナビゲーションペインで、[**インスタンス**] を選択し、接続するインスタンスを選択します。
1. **接続** を選択します。
**[Connect]** (接続) がアクティブ化されていない場合は、最初にインスタンスを起動する必要があります。
1. **[Connect to your instance]** (インスタンスへ接続) ペインの **[Connection method]** (接続方法) で、[**Session Manager**]、**[Connect]** (接続) の順に選択します。
1. 表示されたターミナルセッションウィンドウで、次のコマンドを入力します。これらのコマンドは、tmux ソケットを使用するための適切なアクセス許可を持つ `tmp` フォルダを作成します。
```
sudo mkdir /tmp
sudo chmod 777 /tmp
sudo rmdir /tmp/tmux-*
```
([先頭に戻ります](#troubleshooting))
## Amazon EC2
次のセクションでは、Amazon EC2 に関連する問題のトラブルシューティングについて概説します。
### Amazon EC2 インスタンスが自動的に更新されない
**問題:** 最近のシステム更新は、 AWS Cloud9 開発環境に接続する Amazon EC2 インスタンスに自動的に適用されません。
**原因:** 事前の情報や承認なく自動的に最近の更新を適用すると、コードやAmazon EC2 インスタンスで予期しない動作が発生する可能性があります。
**推奨される解決策:**
「Amazon EC2 ユーザーガイド」**の「[インスタンスソフトウェアの更新](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-updates.html)」にある指示に従って、定期的に Amazon EC2 インスタンスにシステム更新を適用します。
インスタンスでコマンドを実行するには、インスタンスに接続されている環境から IDE AWS Cloud9 のターミナルセッションを使用できます。
また、**ssh** や PuTTY などの SSH リモートアクセスユーティリティを使用してインスタンスに接続できます。これを行うには、ローカルコンピュータから、**ssh-keygen** または PuTTYgen などの SSH キーペア作成ユーティリティを使用します。インスタンスに接続されている環境の AWS Cloud9 IDE を使用して、生成されたパブリックキーをインスタンスに保存します。次に、生成済みのプライベートキーと共に SSH リモートアクセスユーティリティを使用して、インスタンスにアクセスします。詳細については、ユーティリティのドキュメントを参照してください。
### AWS CLI または AWSシェルエラー: EC2 環境の「リクエストに含まれるセキュリティトークンが無効です」
**問題:** AWS Command Line Interface (AWS CLI) または AWS-shell を使用して EC2 環境の IDE AWS Cloud9 でコマンドを実行しようとすると、「リクエストに含まれるセキュリティトークンが無効です」というエラーが表示されます。
**原因:** AWS マネージド一時認証情報があり、以下のいずれかが発生すれば、セキュリティトークンが無効二なる可能性があります。
+ AWS マネージド一時認証情報では許可されていないコマンドを実行しようとしました。許可されたコマンドの一覧については、「[AWS マネージド一時認証情報でサポートされるアクション](security-iam.md#auth-and-access-control-temporary-managed-credentials-supported)」を参照してください。
+ AWS マネージド一時認証情報は 15 分後に自動的に期限切れになります。
+ 環境所有者以外のユーザーが新しいメンバーを追加したため、共有環境の AWS マネージド一時認証情報が非アクティブ化されました。
**推奨される解決策:**
+ AWS マネージド一時認証情報で許可されているコマンドのみを実行します。 AWS マネージド一時認証情報で許可されていないコマンドを実行する必要がある場合は、 環境の AWS CLI または AWSシェルを永続的な認証情報のセットで設定します。これにより、この制限がなくなります。手順については、「[環境に永続的アクセス認証情報を作成して保存する](credentials.md#credentials-permanent-create)」を参照してください。
+ 非アクティブ化または期限切れの認証情報については、 が環境内の一時的な認証情報 AWS Cloud9 を更新できるように、環境所有者が環境を開いていることを確認してください。詳細については、「[AWS マネージド一時認証情報へのアクセスの制御](security-iam.md#temporary-managed-credentials-control)」を参照してください。
### VPC の IP アドレスを Docker が使用しているため、EC2 環境に接続できません
**問題:** EC2 環境で、IPv4 クラスレスドメイン間ルーティング (CIDR) ブロック `172.17.0.0/16` を使用する Amazon VPC で EC2 インスタンスを起動した場合、その環境を開こうとすると、接続が停止することがあります。
**原因:** Docker は、同じブリッジネットワークに接続されているコンテナが通信できるようにするブリッジネットワークと呼ばれるリンクレイヤーデバイスを使用します。 は、コンテナ通信にデフォルトのブリッジを使用するコンテナ AWS Cloud9 を作成します。デフォルトのブリッジは、コンテナのネットワークに通常 `172.17.0.0/16` サブネットを使用します。
環境のインスタンスの VPC サブネットが、Docker で既に使用しているのと同じアドレス範囲を使用している場合、IP アドレスの競合が発生する可能性があります。したがって、 AWS Cloud9 がインスタンスに接続しようとすると、その接続はゲートウェイルートテーブルによって Docker ブリッジにルーティングされます。これにより、 は開発環境をバックアップする EC2 インスタンスに接続 AWS Cloud9 できなくなります。
**推奨される解決策**: Amazon VPC と Docker が同じ IPv4 CIDR アドレスブロックを使用することで発生する IP アドレスの競合を解決するには、EC2 環境をバッキングするインスタンス用に新しい VPC を設定します。この新しいVPC では、`172.17.0.0/16` とは異なる CIDR ブロックを設定します (既存の VPC またはサブネットの IP アドレスの範囲を変更することはできません)。
設定情報については、「Amazon VPC ユーザーガイド」の「[VPC とサブネットサイジング](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#VPC_Sizing)」を参照してください。
### IDE File Explorer でサブフォルダ構造 **/home/ec2-user/environment/home/ec2-user/environment** AWS Cloud9 を作成することはできません。
**問題:** IDE File Explorer でサブフォルダ構造 **/home/ec2-user/environment/home/ec2-user/environment** AWS Cloud9 を作成すると、このディレクトリを開くことができないことを示すエラーメッセージが表示されます。
**考えられる原因:** 現在、IDE のファイルシステムを使用して、同じ名前のフォルダ内にサブフォルダ構造 **/home/ec2-user/environment** AWS Cloud9 を作成することはできません。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにはアクセスできませんが、コマンドラインを使用してアクセスできます。この問題の影響を受けるのは **/home/ec2-user/environment/home/ec2-user/environment** のファイルパスだけです。**/test/home/ec2-user/environment** や **/home/ec2-user/environment/test** などのファイルパスは機能します。これは既知の問題であり、IDE File Explorer AWS Cloud9 にのみ影響します。
**推奨される解決策：** 別のファイル名と構造を使用してください。
### AWS License Manager ライセンス設定が Amazon EC2 インスタンスに関連付けられている場合、コンソール AWS Cloud9 から起動できない
**問題:** コンソールから AWS Cloud9 EC2 環境を起動しようとすると、エラーメッセージ`unable to access your environment`が返されます。
**考えられる原因:** AWS License Manager 全体でソフトウェアベンダーライセンスの管理を合理化します AWS クラウド。License Manager を設定するときは、エンタープライズ契約の条項に基づくライセンスルールのセットであるライセンス設定を作成します。これらのライセンス設定は、Amazon マシンイメージ (AMI) や などのメカニズムにアタッチできます CloudFormation。これらのメカニズムのいずれかを使用して、EC2 インスタンスを起動できます。
AWSServiceRoleForAWSCloud9 サービスにリンクされたロール (SLR) の古いバージョンの **AWSCloud9ServiceRolePolicy** には現在、`license-configuration` リソース条件が含まれていません。このため、 AWS Cloud9 はインスタンスを起動および停止することはできません。そのため、 AWS Cloud9 は Amazon EC2 インスタンスへのアクセスを拒否され、エラーが返されます。
**推奨される解決策**: 既存の AWS Cloud9 環境にアクセスして License Manager を使用できない場合は、古い **AWSCloud9ServiceRolePolicy** サービスにリンクされたロールを、 がインスタンス`license-configuration`に適用されたときに EC2 アクションを明示的に許可する [SLR のバージョン](using-service-linked-roles.md#service-linked-role-permissions)に置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。
### EC2 環境で一部のコマンドやスクリプトを実行できない
**問題:** AWS Cloud9 EC2 開発環境を開いた後、一部のタイプのパッケージをインストールしたり、 `yum` や などのコマンドを実行したり`apt`、他の Linux オペレーティングシステムで通常機能するコマンドを含むスクリプトを実行したりすることはできません。
**原因:** が ECAmazon EC2EC2 インスタンスは、Amazon Linux (Red Hat Enterprise Linux (RHEL) に基づく) または Ubuntu Server のいずれかに依存します。 AWS Cloud9
**解決策:** EC2 環境用に IDE でパッケージをインストールしたり管理したり、コマンドやスクリプトを実行したりする場合は、その環境のインスタンスに応じて、RHEL (Amazon Linux用) または Ubuntu Server と互換性があることを確認してください。
### を使用して EC2 環境を作成するときに「インスタンスプロファイル AWSCloud9SSMInstanceProfile がアカウントに存在しません」と報告するエラーメッセージ CloudFormation
**問題:** [AWS::Cloud9::EnvironmentEC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloud9-environmentec2.html) CloudFormation resource を使用して EC2 環境を作成すると、ユーザーはインスタンスプロファイル AWSCloud9SSMInstanceProfile がアカウントに存在しないというエラーメッセージを受け取ります。
**原因:**no-ingress EC2 環境を作成するときは、サービスロール`AWSCloud9SSMAccessRole` およびインスタンスプロファイル `AWSCloud9SSMInstanceProfile` を作成する必要があります。これらの IAM リソースにより、Systems Manager による開発環境をバックアップする EC2 インスタンスを管理が有効になります。
コンソールで no-ingress 環境を作成する場合、`AWSCloud9SSMAccessRole` および `AWSCloud9SSMInstanceProfile` は自動的に作成されます。ただし、 CloudFormation または を使用して最初の非進入環境 AWS CLI を作成する場合は、これらの IAM リソースを手動で作成する必要があります。
**推奨される解決策: ** CloudFormation テンプレートの編集と IAM アクセス許可の更新については、「」を参照してください。 [CloudFormation を使用して非進入 EC2 環境を作成する](ec2-ssm.md#cfn-role-and-permissions)
### を使用して EC2 環境を作成するときに「 リソース`perform: ssm:StartSession`で」と報告されるエラーメッセージ CloudFormation
**問題:** [AWS::Cloud9::EnvironmentEC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloud9-environmentec2.html) CloudFormation リソースを使用して EC2 環境を作成する`AccessDeniedException`場合、ユーザーは を受け取り、「リソース`ssm:StartSession`で を実行する権限がありません」と通知されます。
**原因:** ユーザーには no-ingress インスタンス用Systems Manager を活用する EC2 環境の設定パートとして必要な`StartSession` API を呼び出す許可がおりていません。
**推奨される解決策: ** CloudFormation テンプレートの編集と IAM アクセス許可の更新については、「」を参照してください[CloudFormation を使用して非進入 EC2 環境を作成する](ec2-ssm.md#cfn-role-and-permissions)。
### を使用して EC2 環境を作成するときに「実行する: `iam:GetInstanceProfile` on resource: instance profile`AWSCloud9SSMInstanceProfile`」という承認がないと報告するエラーメッセージ AWS CLI
**問題:** [AWS CLI](tutorials-basic.md#tutorial-create-environment) を使用して EC2 環境を作成するときに、ユーザーは `AccessDeniedException` を受け取り、 AWS Cloud9 環境には「リソース (インスタンスプロファイル `AWSCloud9SSMInstanceProfile`) に対して iam:GetInstanceProfile を実行する権限がありません」と通知されます。
**原因:** AWS Cloud9 Ingress インスタンスに Systems Manager を使用する EC2 環境の設定の一部として必要な `StartSession` API を呼び出すアクセス許可を付与します。
**推奨される解決策: ** 必要な`AWSCloud9SSMAccessRole`サービスロールと `AWSCloud9SSMInstanceProfile` を AWS Cloud9 環境に追加する方法については、「」を参照してください[を使用した Systems Manager のインスタンスプロファイルの管理 AWS CLI](ec2-ssm.md#aws-cli-instance-profiles)。
### デフォルトの暗号化が Amazon EBS ボリュームに適用されている場合に、環境の作成障害がでる
**問題:** `Failed to create environments. The development environment '[environment-ID]' failed to create` Amazon EC2 環境を作成しようとすると、エラーが返されます。
**考えられる原因:** AWS Cloud9 IDE がデフォルトで暗号化されている Amazon EBS ボリュームを使用している場合、 AWS Identity and Access Management のサービスにリンクされたロール AWS Cloud9 は、これらの EBS ボリューム AWS KMS keys の にアクセスする必要があります。アクセスが提供されていない場合、IDE AWS Cloud9 が起動に失敗し、問題のデバッグが困難になる可能性があります。
**推奨される解決策**: アクセスを提供するには、Amazon EBS AWS Cloud9ボリュームで使用されるカスタマーマネージドキーに`AWSServiceRoleForAWSCloud9`、 のサービスにリンクされたロールを追加します。
このタスクの詳細については、「規範ガイダンスパターン[AWS Cloud9 」の「デフォルトの暗号化で Amazon EBS ボリュームを使用する を作成する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption.html)」を参照してください。 *AWS *
### EC2-Classic アカウントの VPC エラー:「環境にアクセスできません」
**問題**: EC2-Classic は、Amazon EC2 のオリジナルリリースで導入されました。2013 年 12 月 4 日より前にセットアップ AWS アカウント された を使用する場合、 AWS Cloud9 EC2 開発環境の作成時に Amazon VPC とサブネットを設定しないと、このエラーが発生する可能性があります。
デフォルトの VPC 設定を受け入れると、Amazon EC2 インスタンスは EC2-Classic ネットワーク内で起動されます。インスタンスはデフォルト VPC のサブネットで起動されません。環境の作成に失敗すると、次のメッセージが表示されます。
環境エラー
環境にアクセスできません
環境の作成はエラーで失敗しました: 次のリソースの作成に失敗しました:［インスタンス］。ユーザーからロールバックがリクエストされました。
EC2 インスタンスがデフォルト VPC に存在しないためにエラーが発生したことを確認できます。を使用して CloudFormation 、開発環境のスタックイベント履歴を表示します。
1. CloudFormation コンソールを開きます。詳細については、「[CloudFormation コンソールにログイン](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-login.html)」を参照してください。
1. CloudFormation コンソールで、**スタック**を選択します。
1. ［**スタック**］ページで、作成に失敗した開発環境の名前を選択します。
1. **[Stack details]** (スタックの詳細) ページで **[Events]** (イベント) タブを選択し、次のエントリをチェックします。
ステータス: CREATE\$1FAILED
ステータスの理由: AssociatePublicIPAddress パラメータは、VPC の起動でのみサポートされています。[...]
**原因:** AWS Cloud9 開発環境は、特定の VPC 要件を満たす Amazon VPC に関連付ける必要があります。EC2-Classic が有効なアカウントの場合、[EC2 環境の作成](create-environment.md) 時にデフォルトのネットワーク設定を受け入れると、必要な EC2 インスタンスが VPC 内で起動されません。代わりに、インスタンスは EC2-Classic ネットワーク内で起動されます。
**推奨される解決策:** EC2-Classic アカウントでは、[EC2 環境の作成](create-environment.md)時に VPC とサブネットを選択する必要があります。［**設定の構成**］ページの［**ネットワーク設定 (アドバンスト)**］セクションで、EC2 インスタンスを起動できる VPC とサブネットを選択します。
## その他の AWS サービス
次のセクションでは、他の AWS サービスに関連する問題のトラブルシューティングについて概説します。
### CodeCatalyst の IDE の File Explorer 内にサブフォルダ構造 **/projects/projects** AWS Cloud9 を作成することはできません。
**問題:** CodeCatalyst の AWS Cloud9 IDE File Explorer でサブフォルダ構造 **/projects/projects** を作成すると、このディレクトリを開くことができないことを示すエラーメッセージが表示されます。
**考えられる原因:** 現在、CodeCatalyst の AWS Cloud9 IDE の File Explorer を使用して、同じ名前のフォルダ内にサブフォルダ構造**/プロジェクト**を作成することはできません。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにはアクセスできませんが、コマンドラインを使用してアクセスできます。この問題は **/projects/projects** のファイルパスにのみ影響します。**/test/projects** や **/projects/test** などのファイルパスは正常に機能します。これは既知の問題で、 AWS Cloud9 IDE ファイルエクスプローラーにのみ影響します。
**推奨される解決策：** 別のファイル名と構造を使用してください。
### IDE の外部で実行中のアプリケーションを表示できない
**問題:** IDE 外部のウェブブラウザタブで実行中のアプリケーションを表示しようとすると、そのウェブブラウザタブがエラーを表示するか、空白になります。
**考えられる原因:**
+ アプリケーションが IDE で実行していません。
+ アプリケーションが `127.0.0.1` または `localhost` の IP で実行しています。
+ アプリケーションは AWS Cloud9 EC2 開発環境で実行されています。さらに、Amazon EC2 インスタンスに関連付けられているセキュリティグループの 1 つ以上が、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。
+ アプリケーションは、 AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) AWS Cloud9 の SSH 開発環境で実行されています。さらに、対応するインスタンスに関連付けられている仮想プライベートクラウド (VPC) のサブネットのネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。
+ URL に誤りがある。
+ インスタンスのパブリック IP アドレスではなく、アプリケーションプレビュータブの URL がリクエストされている。
+ `127.0.0.1` または `localhost` の IP を含むアドレスに移動しようとしています。これらの IP は、環境のリソースではなく、ローカルコンピュータのリソースにアクセスしようとします。
+ インスタンスのパブリック IP アドレスが変更されています。
+ ウェブリクエストが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のトラフィックをブロックする仮想プライベートネットワーク (VPN) から送信されています。
+ アプリケーションが SSH 環境で実行しています。ただし、サーバーまたは関連付けられたネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。
**推奨される解決策:**
+ IDE でアプリケーションが実行されていることを確認します。
+ アプリケーションが `127.0.0.1` または `localhost` の IP を使用して実行されていないことを確認します。Node.js および Python の例については、「[アプリケーションの実行](app-preview.md#app-preview-run-app)」を参照してください。
+ アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) で実行されているとします。この場合、対応するインスタンスに関連付けられているすべてのセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、および IP アドレスを介したインバウンドトラフィックを許可していることを確認します。指示については、*実行中のアプリケーションをインターネット上で共有する*の [ステップ 2: インスタンスのセキュリティグループを設定する](app-preview-share.md#app-preview-share-security-group) を参照してください。「Amazon VPC ユーザーガイド」**の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)」を参照してください。
+ アプリケーションが AWS クラウドコンピューティングインスタンスで実行されているとします。さらに、対応するインスタンスに関連付けられた VPC のサブネットにネットワーク ACL が存在するとします。この場合、ネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、および IP アドレスを介したインバウンドトラフィックを許可していることを確認します。指示については、*実行中のアプリケーションをインターネット上で共有する*の [ステップ 3: インスタンスのサブネットをセットアップする](app-preview-share.md#app-preview-share-subnet) を参照してください。また、「Amazon VPC ユーザーガイド」**の「[ネットワーク ACL](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)」を参照してください。
+ プロトコル (およびポートを指定する必要がある場合はポート) を含むリクエストしている URL が正しいことを確認します。指示については、*実行中のアプリケーションをインターネット上で共有する*の [ステップ 4: 実行中のアプリケーションの URL を共有する](app-preview-share.md#app-preview-share-url) を参照してください。
+ 形式 `https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/` ( `12a34567b8cd9012345ef67abcd890e1`は環境 AWS Cloud9 に割り当てる ID、 は環境の AWS リージョンの `us-east-2` ID) の URL をリクエストすることはお勧めしません。この URL を使用するには、環境の IDE が開いており、アプリケーションが同じウェブブラウザで実行されている必要があります。
+ `127.0.0.1` または `localhost` の IP を含むアドレスに移動しようとしているとします。代わりに、実行中のアプリケーションの正しい非ローカルアドレスに移動してみてください。詳細については、「[実行中のアプリケーションをインターネット経由で共有する](app-preview-share.md)」を参照してください。
+ アプリケーションが AWS クラウドコンピューティングインスタンスで実行されているとします。インスタンスのパブリック IP アドレスが変更されているかどうかを確認します。インスタンスのパブリック IP アドレスは、インスタンスが再起動されると変更される可能性があります。この IP アドレスの変更を防ぐには、Elastic IP アドレスを割り当てて、それを実行中のインスタンスに割り当てます。指示については、*実行中のアプリケーションをインターネット上で共有する*の [ステップ 4: 実行中のアプリケーションの URL を共有する](app-preview-share.md#app-preview-share-url) を参照してください。
+ ウェブリクエストが VPN から送信されている場合は、その VPN でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のトラフィックが許可されていることを確認します。VPN を変更できない場合は、ネットワーク管理者にお問い合わせください。または、可能であれば、別のネットワークからウェブリクエストを行います。
+ アプリケーションが独自のサーバーの SSH 環境で実行しているとします。サーバーおよび関連付けられているネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していることを確認します。サーバーまたは関連付けられているネットワークを変更できない場合は、サーバーまたはネットワークの管理者にお問い合わせください。
+ `curl` コマンドに URL を続けて実行し、環境のターミナルからアプリケーションの実行を試みます。このコマンドでエラーメッセージが表示される場合は、関連しない他の問題がある可能性があります AWS Cloud9。
### AWS Toolkit の実行中にエラーが発生しました：「環境が inodes を使い果たしています。「fs.inotify.max\$1user\$1watches」の制限を増やしてください。」
**問題:** AWS Toolkit が使用するファイル監視ユーティリティが、監視できるファイルの現在の制限またはクォータに近づいています。
**Cause:** AWS Toolkit は、ファイルとディレクトリへの変更をモニタリングするファイル監視ユーティリティを使用します。ユーティリティが監視できるファイル数が現在のクォータに近づくと、警告メッセージが表示されます。
**推奨される解決策:**ファイルウォッチャーで処理できるファイルの最大数を増やすには、次の操作を行います。
1. ターミナルセッションをスタートするには、メニューバーで、［**Window (ウィンドウ)**］、［**New Terminal (新しいターミナル)**］を選択します。
1. 次のコマンドを入力します。
```
sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p
```
### Lambda ローカル関数実行エラー: SAM Local をインストールできない
**問題:** IDE AWS Cloud9 で AWS Lambda 関数のローカルバージョンを実行しようとすると、ダイアログボックスが表示されます。ダイアログボックスには、 AWS Cloud9 で SAM Local のインストールに問題があることが示されます。 では、ローカルバージョンの AWS Lambda 関数を IDE で実行するために SAM Local AWS Cloud9 が必要です。SAM Local をインストールするまで、IDE でローカルバージョンの Lambda 関数を実行することはできません。
**Cause:** AWS Cloud9 環境内の想定されるパス に SAM Local が見つかりません`~/.c9/bin/sam`。これは SAM Local がまだインストールされていないか、インストールされていても AWS Cloud9 がその場所に見つけられないことが原因です。
**推奨される解決策:** AWS Cloud9 が SAM Local のインストールを完了するのを待つか、自分でインストールできます。
AWS Cloud9 が SAM Local のインストールを試みている様子を確認するには、メニューバーで **Window, Installer** を選択します。
SAM Local を自分でインストールするには、「 デベロッパーガイド[」の「Linux AWS での SAM CLI のインストール](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install-linux.html)」の手順に従います。 *AWS Serverless Application Model *
### AWS Control Tower AWS Cloud9を使用して Amazon EC2 環境を作成しようとすると、「環境の作成がエラーで失敗しました: 次のフック (複数可) が失敗しました:[ControlTower::Guard::Hook]」。
**問題:** AWS Cloud9 および AWS Control Tower プロアクティブコントロール *CT.EC2.PR.8 *との互換性の問題があります。このコントロールが有効な場合、 AWS Cloud9で EC2 環境を作成することはできません。
**原因:** AWS Control Tower は、*AssociatePublicIpAddress* パラメータが AWS CloudFormation テンプレートにあることを想定しています。現在、このパラメータは追加できません。
**推奨される解決策: ** AWS Control Tower コンソールから control*CT.EC2.PR.8* を無効にし、環境を再作成します AWS Cloud9。
### デフォルトの暗号化が Amazon EBS ボリュームに適用されている場合に、環境の作成障害がでる
**問題:** `Failed to create environments. The development environment '[environment-ID]' failed to create` Amazon EC2 環境を作成しようとすると、エラーが返されます。
**考えられる原因:** AWS Cloud9 IDE がデフォルトで暗号化されている Amazon EBS ボリュームを使用している場合、 AWS Identity and Access Management のサービスにリンクされたロール AWS Cloud9 は、これらの EBS ボリューム AWS KMS keys の にアクセスする必要があります。アクセスが提供されていない場合、IDE AWS Cloud9 が起動に失敗し、問題のデバッグが困難になる可能性があります。
**推奨される解決策**: アクセスを提供するには、Amazon EBS AWS Cloud9ボリュームで使用されるカスタマーマネージドキーに`AWSServiceRoleForAWSCloud9`、 のサービスにリンクされたロールを追加します。
このタスクの詳細については、「規範ガイダンスパターン[AWS Cloud9 」の「デフォルトの暗号化で Amazon EBS ボリュームを使用する を作成する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption.html)」を参照してください。 *AWS *
([先頭に戻ります](#troubleshooting))
### AWS License Manager ライセンス設定が Amazon EC2 インスタンスに関連付けられている場合、コンソール AWS Cloud9 から起動できない
**問題:** コンソールから AWS Cloud9 EC2 環境を起動しようとすると、エラーメッセージ`unable to access your environment`が返されます。
**考えられる原因:** AWS License Manager 全体でソフトウェアベンダーライセンスの管理を合理化します AWS クラウド。License Manager を設定するときは、エンタープライズ契約の条項に基づくライセンスルールのセットであるライセンス設定を作成します。これらのライセンス設定は、Amazon マシンイメージ (AMI) や などのメカニズムにアタッチできます CloudFormation。これらのメカニズムのいずれかを使用して、EC2 インスタンスを起動できます。
AWSServiceRoleForAWSCloud9 サービスにリンクされたロール (SLR) の古いバージョンの **AWSCloud9ServiceRolePolicy** には現在、`license-configuration` リソース条件が含まれていません。このため、 AWS Cloud9 はインスタンスを起動および停止することはできません。そのため、 AWS Cloud9 は Amazon EC2 インスタンスへのアクセスを拒否され、エラーが返されます。
**推奨される解決策**: 既存の AWS Cloud9 環境にアクセスして License Manager を使用できない場合は、古い **AWSCloud9ServiceRolePolicy** サービスにリンクされたロールを、 がインスタンス`license-configuration`に適用されたときに EC2 アクションを明示的に許可する [SLR のバージョン](using-service-linked-roles.md#service-linked-role-permissions)に置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。
([先頭に戻ります](#troubleshooting))
## アプリケーションプレビュー
次のセクションでは、アプリケーションプレビューに関連する問題のトラブルシューティングについて概説します。
### 環境を再ロードした後、アプリケーションプレビューを最新の情報に更新する必要がある
**問題:** アプリケーションプレビュータブを表示する環境を再ロードした後、タブにアプリケーションプレビューが表示されません。
**原因:** 無限ループを実行できるコードをユーザーが書くことがあります。または、コードで大量のメモリが使用されるため、アプリケーションプレビューの実行中に AWS Cloud9 IDE が一時停止または停止する可能性があります。これを防ぐには、環境が再ロードされるたびにアプリケーションプレビュータブを再ロード AWS Cloud9 しません。
**解決策:** アプリケーションプレビュータブを表示する環境を再ロードした後で、アプリケーションプレビューを表示するには、タブの ［**Click to load the page (クリックしてページをロード)**］ボタンを選択します。
### アプリケーションプレビューまたはファイルプレビュー通知:「サードパーティーの Cookie が無効になっています」
**問題:** [アプリケーション](app-preview.md)または[ファイルを](file-preview.md)プレビューしようとすると、次のメッセージと通知が表示されます。「ブラウザでサードパーティーの Cookie が無効になっているため、プレビュー機能が無効になっています。」
**原因:** IDE を開くためにサードパーティーの Cookie AWS Cloud9 は必要ありません。ただし、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティーの Cookie を有効にする必要があります。
**解決方法:** ウェブブラウザでサードパーティーの Cookie を有効にし、IDE を再読み込みしてから、もう一度プレビューを開いてみてください。
+ **Apple Safari:** Apple サポートウェブサイトで「[Safari で Cookie と Web サイトのデータを管理する](https://support.apple.com/guide/safari/manage-cookies-and-website-data-sfri11471/mac)」を参照してください。
+ **Google Chrome:** Google Chrome ヘルプウェブサイトで「[Chrome で Cookie の削除、有効化、管理を行う](https://support.google.com/chrome/answer/95647)」の「**Cookie の設定を変更する**」を参照してください。
+ **Internet Explorer:** Microsoft サポートウェブサイトで「**Cookie の削除と管理を行う**」の「[Cookie のブロックまたは許可](https://support.microsoft.com/en-us/help/17442)」を参照してください。
+ **Microsoft Edge:** Microsoft サポートウェブサイトで「[サードパーティの Cookie をブロックする](https://support.microsoft.com/en-us/help/4464209/issue-with-blocking-third-party-cookies)」を参照してください。
+ **Mozilla Firefox:** Mozilla サポートウェブサイトで「[Enable and disable cookies that websites use to track your preferences](https://support.mozilla.org/kb/enable-and-disable-cookies-website-preferences) (設定を追跡するためウェブサイトで使用するCookie を有効または無効にする)」の「**Accept third party cookies** (サードパーティーの Cookie を受け入れる)」を参照してください。
+ **他のウェブブラウザの場合:** そのウェブブラウザのドキュメントを参照してください。
お使いのウェブブラウザでこの精度が許容される場合は、 AWS Cloud9に対してのみサードパーティーの Cookie を有効にできます。そのためには、 AWS Cloud9を使用するサポート対象のドメインに応じて、次のドメインを指定します。
****
| **AWS リージョン** | **ドメイン** |
| --- | --- |
| 米国東部(バージニア北部) | `*.vfs.cloud9.us-east-1.amazonaws.com` `vfs.cloud9.us-east-1.amazonaws.com` |
| 米国東部 (オハイオ) | `*.vfs.cloud9.us-east-2.amazonaws.com` `vfs.cloud9.us-east-2.amazonaws.com` |
| 米国西部 (北カリフォルニア) | `*.vfs.cloud9.us-west-1.amazonaws.com` `vfs.cloud9.us-west-1.amazonaws.com` |
| 米国西部 (オレゴン) | `*.vfs.cloud9.us-west-2.amazonaws.com` `vfs.cloud9.us-west-2.amazonaws.com` |
| アフリカ (ケープタウン) | `*.vfs.cloud9.af-south-1.amazonaws.com` `vfs.cloud9.af-south-1.amazonaws.com` |
| アジアパシフィック (香港) | `*.vfs.cloud9.ap-east-1.amazonaws.com` `vfs.cloud9.ap-east-1.amazonaws.com` |
| アジアパシフィック (ムンバイ) | `*.vfs.cloud9.ap-south-1.amazonaws.com` `vfs.cloud9.ap-south-1.amazonaws.com` |
| アジアパシフィック (大阪) | `*.vfs.cloud9.ap-northeast-3.amazonaws.com` `vfs.cloud9.ap-northeast-3.amazonaws.com` |
| アジアパシフィック (ソウル) | `*.vfs.cloud9.ap-northeast-2.amazonaws.com` `vfs.cloud9.ap-northeast-2.amazonaws.com` |
| アジアパシフィック (シンガポール) | `*.vfs.cloud9.ap-southeast-1.amazonaws.com` `vfs.cloud9.ap-southeast-1.amazonaws.com` |
| アジアパシフィック (シドニー) | `*.vfs.cloud9.ap-southeast-2.amazonaws.com` `vfs.cloud9.ap-southeast-2.amazonaws.com` |
| アジアパシフィック (東京) | `*.vfs.cloud9.ap-northeast-1.amazonaws.com` `vfs.cloud9.ap-northeast-1.amazonaws.com` |
| カナダ (中部) | `*.vfs.cloud9.ca-central-1.amazonaws.com` `vfs.cloud9.ca-central-1.amazonaws.com` |
| 欧州 (フランクフルト) | `*.vfs.cloud9.eu-central-1.amazonaws.com` `vfs.cloud9.eu-central-1.amazonaws.com` |
| 欧州 (アイルランド) | `*.vfs.cloud9.eu-west-1.amazonaws.com` `vfs.cloud9.eu-west-1.amazonaws.com` |
| 欧州 (ロンドン) | `*.vfs.cloud9.eu-west-2.amazonaws.com` `vfs.cloud9.eu-west-2.amazonaws.com` |
| 欧州 (ミラノ) | `*.vfs.cloud9.eu-south-1.amazonaws.com` `vfs.cloud9.eu-south-1.amazonaws.com` |
| ヨーロッパ (パリ) | `*.vfs.cloud9.eu-west-3.amazonaws.com` `vfs.cloud9.eu-west-3.amazonaws.com` |
| ヨーロッパ (ストックホルム) | `*.vfs.cloud9.eu-north-1.amazonaws.com` `vfs.cloud9.eu-north-1.amazonaws.com` |
| 中東 (バーレーン) | `*.vfs.cloud9.me-south-1.amazonaws.com` `vfs.cloud9.me-south-1.amazonaws.com` |
| 南米 (サンパウロ) | `*.vfs.cloud9.sa-east-1.amazonaws.com` `vfs.cloud9.sa-east-1.amazonaws.com` |
### アプリケーションプレビュータブにエラーが表示される、または空白になる
**問題:** IDEのメニューバーで、［**プレビュー、実行中のアプリケーションのプレビュー)**］または［**ツール、プレビュー、実行中のアプリケーションのプレビュー)**］を選択して IDEのプレビュータブでアプリケーションを表示しようとすると、タブにエラーが表示されるか、タブが空白になります。
**考えられる原因:**
+ アプリケーションが IDE で実行していません。
+ アプリケーションが HTTP を使用して実行していません。
+ アプリケーションが複数のポート経由で実行されている。
+ アプリケーションが `8080`、`8081`、または `8082` 以外のポート経由で実行されている。
+ アプリケーションが `127.0.0.1`、`localhost`、または `0.0.0.0` 以外の IP で実行されている。
+ ポート (`8080`、`8081`、または `8082`) がプレビュータブの URL に指定されていません。
+ ネットワークがポート `8080`、`8081`、または `8082` へのインバウンドトラフィックをブロックしています。
+ `127.0.0.1`、`localhost`、または `0.0.0.0` の IP を含むアドレスに移動しようとしています。デフォルトでは、IDE AWS Cloud9 はローカルコンピュータに移動しようとします。環境に接続されているインスタンスや独自のサーバーに移動しようとはしません。
**推奨される解決策:**
+ IDE でアプリケーションが実行されていることを確認します。
+ HTTP を使用してアプリケーションが実行されていることを確認します。Node.js および Python の例については、「[アプリケーションの実行](app-preview.md#app-preview-run-app)」を参照してください。
+ アプリケーションが 1 つのポート経由のみで実行されていることを確認します。Node.js および Python の例については、「[アプリケーションの実行](app-preview.md#app-preview-run-app)」を参照してください。
+ アプリケーションがポート `8080`、`8081`、または `8082` 経由で実行されていることを確認します。Node.js および Python の例については、「[アプリケーションの実行](app-preview.md#app-preview-run-app)」を参照してください。
+ アプリケーションが IP `127.0.0.1`、`localhost`、または `0.0.0.0` を使用して実行されていることを確認します。Node.js および Python の例については、「[アプリケーションの実行](app-preview.md#app-preview-run-app)」を参照してください。
+ プレビュータブの URL に `:8080`、`:8081`、または `:8082` を追加します。
+ ネットワークがポート `8080`、`8081`、または `8082` 経由のインバウンドトラフィックを許可していることを確認します。ネットワークを変更できない場合は、ネットワーク管理者にお問い合わせください。
+ `127.0.0.1`、`localhost`、または `0.0.0.0` の IP を含むアドレスに移動しようとしている場合は、代わりに `https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/` のアドレスに移動してみてください。このアドレスの場合、`12a34567b8cd9012345ef67abcd890e1` は AWS Cloud9 が環境に割り当てる ID です。`us-east-2` は環境の AWS リージョン の ID です。IDE の外部で、このアドレスに移動してみることもできます。ただし、これが可能なのは、環境の IDE が開いていて、アプリケーションが同じウェブブラウザで実行している場合のみです。
+ 上記の条件がすべて満たされていることを確認した後で、アプリケーションを停止してから再度起動してみてください。
+ アプリケーションを停止してから再度起動した場合は、メニューバーで再度［**Preview (プレビュー)］、［Preview Running Application (実行中のアプリケーションのプレビュー)**］または［**Tools (ツール)］、［Preview (プレビュー)］、［Preview Running Application (実行中のアプリケーションのプレビュー)**］を選択します。対応するアプリケーションプレビュータブが既に表示されている場合は、そのタブで［**Refresh (最新の情報に更新)**］ボタン (円状の矢印) を選択します。
### サイトへの接続が安全でないため、IDE で ウェブコンテンツをプレビューできません
**問題:** AWS Cloud9 EC2 環境でホストされている WordPress サイトなどのウェブコンテンツにアクセスしようとすると、IDE プレビューウィンドウには表示されません。
**考えられる原因:** デフォルトでは、IDE のアプリケーションプレビュータブでアクセスするすべてのウェブページは自動的に HTTPS AWS Cloud9 プロトコルを使用します。ページの URI が安全でない `http` プロトコルを備えている場合、`https` に自動的に置き換えられます。また、手動で `https` を `http` に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。
**推奨される解決策**: IDE でプレビューしようとしている ウェブサイトから安全ではない HTTP スクリプトまたはコンテンツを削除します。HTTPS の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってください。
### ファイルをプレビューすると 499 エラーが返される
**問題:** AWS Cloud9 IDE を使用して、 `src` 属性を含み、 属性が `type`に設定されている ``。次に、変更したファイルを保存し、もう一度プレビューを試みます。
## パフォーマンス
次のセクションでは、パフォーマンスに関連する問題のトラブルシューティングについて概説します。
### AWS Cloud9 IDE の長時間のフリーズ
**問題:** 起動時および更新時に、IDE AWS Cloud9 ターミナルが長時間フリーズし、使用できなくなります。
**原因:** ご使用の環境に大量のファイルがあり、 AWS Cloud9のファイル監視モジュールによって再帰的に監視されている可能性があります。
**推奨される解決策:** ファイル監視の深さを減らし (最小値は 1)、大きいフォルダや、ソースコードに関係のないフォルダ (ビルド出力/アーティファクト、サードパーティパッケージ) を、無視するパターンに追加することを検討できます。これを行うには、[設定] > [ユーザー設定] > [ファイル監視] に移動します。これにより、 AWS Toolkit の CodeLenses が正しく動作しないことに注意してください。
別の解決策としては、検索するファイルの最大数を減らして、ソースコードに関係のない大きなファイルやフォルダを無視することを検討します。これを行うには、[設定] > [プロジェクト設定] > [フォルダを指定して検索] に移動します。これにより、無視したフォルダはファイル検索に表示されなくなることに注意してください。
### コンソールの警告:「最小限のコード補完エンジンに切り替えます...」
**問題:** AWS Cloud9 コンソールで作業する場合 (IDE を開くときや IDE のウェブページを更新するときなど）、「1 つ以上のセッションまたは共同作業者がこの環境でアクティブです。メモリを節約するために最小限のコード補完エンジンに切り替えます。」」というメッセージが表示される。このメッセージと相関して、コード補完の動作が遅いか断続的になっている可能性がある。
**原因:** コード補完エンジンを実行すると、環境からメモリと CPU サイクルが消費されます。さらに、共同作業者および追加のセッションごとに個別のコード補完エンジンが必要です。特に t2.nanoや などの小さなインスタンスサイズで大量のリソースを使用しないようにt2.micro、 は最小限のコード補完エンジン AWS Cloud9 に切り替えます。
**推奨される解決策:** 長期間にわたって頻繁に共同作業を行う場合は、EC2 環境の作成時により大きい Amazon EC2 インスタンスを選択します。または、SSH 環境をより容量の大きいインスタンスに接続します。
**注記**
より大きな Amazon EC2 インスタンスを選択すると、 AWS アカウント に追加料金が発生する可能性があります。詳細については、[Amazon EC2 の料金表](https://aws.amazon.com/ec2/pricing/)を参照してください。
### IDE による警告:「この環境のメモリが不足しています」または「この環境の CPU ロードが高くなっています」
**問題:** IDE の実行中、「この環境のメモリが不足しています」または「この環境の CPU ロードが高くなっています」という内容のメッセージが表示される。
**原因:** IDE に、遅延やハングアップしないで実行を続けるのに必要なコンピューティングリソースがない可能性があります。
**推奨される解決策:**
+ 実行中のプロセスを 1 つ以上停止し、使用可能なメモリを解放してください。これを行うには、メニューバーにある環境用 IDE で、［**ツール、プロセスリスト)**］を選択します。停止するプロセスごとに、プロセスを選択して［**Force Kill (強制終了)**］を選択します。
+ 環境で swap ファイルを作成します。*スワップファイル*は、オペレーティングシステムが仮想メモリとして使用できる環境内のファイルです。
環境で現在スワップメモリを使用しているかどうかを確認するには、環境のターミナルセッションで **`top`** コマンドを実行します。スワップメモリが使用されている場合、出力にゼロ以外の `Swap` メモリ統計が表示されます (たとえば、`Swap: 499996k total, 1280k used, 498716 free, 110672k cached`)。リアルタイムのメモリ情報の表示をやめるには、`Ctrl + C` を押します。
スワップファイルを作成するには、環境で次のようなコマンドを実行します。
```
sudo fallocate --length 512MB /var/swapfile && sudo chmod 600 /var/swapfile && sudo mkswap /var/swapfile && echo '/var/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab > /dev/null
```
前述のコマンドは以下の処理を実行します。
1. `/var` ディレクトリに `swapfile` という名前で 512 MB のファイルを作成します。
1. `swapfile` ファイルのアクセス権限を所有者のみの読み取り/書き込みに変更します。
1. `swapfile` ファイルをスワップファイルとして設定します。
1. `/etc/fstab file` に情報を書き込みます。これにより、システムをリブートするたびに、このスワップファイルを使用できます。
前述のコマンドを実行したら、このスワップファイルをすぐに使用可能にするために、次のコマンドを実行します。
```
sudo swapon /var/swapfile
```
+ 環境をコンピューティングリソースの多いインスタンスまたはサーバーに移動するか、サイズを変更します。Amazon EC2 インスタンスを移動またはサイズ変更するには、「[Amazon EBS AWS Cloud9 ボリュームからの IDE の移動](move-environment.md)」を参照してください。他のインスタンスまたはサーバータイプについては、インスタンスまたはサーバーのドキュメントを参照してください。
### IDE AWS Cloud9 にファイルをアップロードできない
**問題:** ユーザーは IDE AWS Cloud9 に大きなファイルをアップロードできません。アップロードは失敗しています。
**原因:** AWS Cloud9 IDE AWS Cloud9 へのアップロード速度をスロットリングし、その結果、ファイルのアップロードリクエストがタイムアウトします。
**推奨される解決策:** ファイルを Amazon S3 にアップロードし、Amazon S3 を使用して IDE の CLI AWS Cloud9 を使用して環境にファイルをダウンロードすることをお勧めします。Amazon S3 にファイルをアップロードする方法の詳細については、「Amazon S3 ユーザーガイド」の「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。**
### IDE AWS Cloud9 のダウンロード速度が遅い
**問題:** IDE AWS Cloud9 からファイルをダウンロードしようとすると、ダウンロード速度が低下します。
**原因:** IDE からローカルファイルシステムにファイルをダウンロードする場合、転送速度は 0.1 メガバイト/秒に制限されます。
**推奨される解決策:** ファイル転送の速度を上げるには、IDE の CLI AWS Cloud9 を使用して Amazon S3 にファイルをアップロードし、Amazon S3 を使用してそこからファイルをダウンロードします。
### サイトへの接続が安全でないため、IDE で ウェブコンテンツをプレビューできません
**問題:** AWS Cloud9 EC2 環境でホストされている WordPress サイトなどのウェブコンテンツにアクセスしようとすると、IDE プレビューウィンドウには表示されません。
**考えられる原因:** デフォルトでは、IDE のアプリケーションプレビュータブでアクセスするすべてのウェブページは自動的に HTTPS AWS Cloud9 プロトコルを使用します。ページの URI が安全でない `http` プロトコルを備えている場合、`https` に自動的に置き換えられます。また、手動で `https` を `http` に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。
**推奨される解決策**: IDE でプレビューしようとしている ウェブサイトから安全ではない HTTP スクリプトまたはコンテンツを削除します。HTTPS の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってください。
([先頭に戻ります](#troubleshooting))
## サードパーティのアプリケーションとサービス
次のセクションでは、サードパーティのアプリケーションとサービスに関連する問題のトラブルシューティングについて概説します。
### `tmux` セッションエラー AWS Cloud9 のため、 でターミナルウィンドウとやり取りできない
**問題:** で新しいターミナルウィンドウを起動しようとすると AWS Cloud9、予想されるコマンドラインインターフェイスが使用できなくなります。コマンドプロンプトがないため、テキストを入力できません。`tmux: need UTF-8 locale (LC_CTYPE)` や `invalid LC_ALL, LC_CTYPE or LANG` などのエラーメッセージが返されます。
**考えられる原因:** tmux エラーが原因でターミナルが応答しない可能性があります。 は [tmux](https://en.wikipedia.org/wiki/Tmux) ユーティリティ AWS Cloud9 を使用します。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。
`tmux` セッションでは、ターミナルウィンドウの表示内容はクライアントによって処理されます。クライアントは、複数のセッションを管理できるサーバーと通信します。サーバーとクライアントは、`tmp` フォルダにあるソケットを介して通信します。開発環境に `tmp` フォルダがないか、過度に制限的なアクセス許可が適用されている場合、`tmux` セッションは実行できません。この場合、IDE のターミナルウィンドウは応答しなくなります。
**推奨される解決策**: `tmux` エラーによってターミナルウィンドウと対話できない場合は、別の方法を使用して適切な許可を持つ `tmp` フォルダを作成する必要があります。これにより、`tmux` セッションを実行できます。1 つの解決策は、`.bash_profile` または `.bashrc` ファイルの `LC_CTYPE` をエクスポートすることです。もう 1 つの推奨される解決策は、 AWS Systems Manager を使用してホスト管理設定をセットアップすることです。これにより、Amazon EC2 コンソールから該当するインスタンスにアクセスできるようになります。
**ホスト管理の設定**
1. まず、 AWS Cloud9 コンソールで、環境のインスタンスの名前を見つけます。これを行うには、**[Your environments]** (自分の環境) ページで該当するパネルを選択し、**[View details]** (詳細を表示) を選択します。[**環境の詳細**] ページで [**インスタンスに移動**] を選択します。Amazon EC2 コンソールで、アクセスする必要があるインスタンスの名前を確認します。
1. AWS Systems Manager コンソールに移動し、ナビゲーションペインで**クイックセットアップ**を選択します。
1. [**クイックセットアップ**] ページで [**作成**] を選択します。
1. [**設定タイプ**] では、[**ホスト管理**] に移動し、[**登録**] を選択します。
1. [**ホスト管理構成オプションのカスタマイズ**] の [**ターゲット**]セクションで、[**手動**]を選択します。
1. アクセスする EC2 インスタンスを選択してから、[**作成**] を選択します。
**インスタンスに接続してコマンドを実行する**
**注記**
次の手順は、新しい EC2 コンソール用です。
1. Amazon EC2 コンソールのナビゲーションペインで、[**インスタンス**] を選択し、接続するインスタンスを選択します。
1. **接続** を選択します。
**[Connect]** (接続) がアクティブ化されていない場合は、最初にインスタンスを起動する必要があります。
1. **[Connect to your instance]** (インスタンスへ接続) ペインの **[Connection method]** (接続方法) で、[**Session Manager**]、**[Connect]** (接続) の順に選択します。
1. 表示されたターミナルセッションウィンドウで、次のコマンドを入力します。これらのコマンドは、tmux ソケットを使用するための適切なアクセス許可を持つ `tmp` フォルダを作成します。
```
sudo mkdir /tmp
sudo chmod 777 /tmp
sudo rmdir /tmp/tmux-*
```
### 古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードすることはできません
**問題:** Microsoft Edgeウェブブラウザを使用して IDE AWS Cloud9 をロードしようとすると、`HTTP403: FORBIDDEN`エラーが返されます。
**考えられる原因:** AWS Cloud9 IDE は、特定の古いバージョンの をサポートしていませんMicrosoft Edge。
**推奨される解決策:** ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンをクリックします。メニューで、**[Settings]** (設定) を選択して **[About Microsoft Edge]** ( について) を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。
### C\$1\$1 プロジェクトのデバッグ時に、`gdb` を伴うエラー
**問題:**IDE で C\$1\$1 プロジェクトをデバッグしようとすると、`gdb` デバッガに報告されるエラー
**考えられる原因:** AWS Cloud9 環境が特定の EC2 インスタンスタイプ ( `t3.small`や など) を使用しているとします`m5.large`。この場合、IDE の組み込みランナーを使用して C\$1\$1 プロジェクトを実行およびデバッグしようとすると、デバッグエラーが発生することがあります。このエラーは、環境にプリインストールされた `gdb` (GNU プロジェクトデバッガ) は、特定のプロセッサプラットフォームでは動作しません。次のエラーコードが表示される可能性があります。
```
GDB server terminated with code 1
```
**推奨される解決策:**`gdb`が特定のプロセッサプラットフォームをサポートしていないという問題は、バージョン*3.0*以降で修正されました。古いバージョンのデバッガをアンインストールし、新しいバージョンの `gdb` にアップグレードします。
1. AWS Cloud9 ターミナルで次のコマンドを実行して、デバッガーの既存のバージョンを削除します。
```
sudo yum -y remove gdb
```
1. `gdb` のアーカイブを取得して展開し、次のコマンドを実行して、展開したファイルが含まれているディレクトリに移動します。
```
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
```
1. 次のコマンドを実行してデバッガーを構築します。これを行うには、次のテキストをコピーして単一のブロックとして貼り付け、**Return** を押して `make` を実行します。
```
./configure --prefix=/usr \
--with-system-readline \
--with-python=/usr/bin/python3 &&
make
```
1. デバッガーをインストールします。
```
sudo make -C gdb install
```
1. 更新したバージョンのデバッガーがインストールされたことを確認します。
```
gdb --version
```
### での PHP ランナーの問題 AWS Cloud9
**問題:** ユーザーは PHP CLI ランナーターミナルで出力を表示できません。
**原因:** CLI ランナーを PHP に設定し、デバッガーモードを有効にする必要があります。
**推奨される解決策:** CLI ランナーを PHP に設定し、デバッガーモードが有効になっていることを確認します。
### Node.js に関連する GLIBC エラー
**問題:** ユーザーが Node.js を実行できず、GLIBC エラーが発生します。エラーメッセージの例を以下に示します。
```
node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node)
```
**原因:** 使用しているインスタンスに関連する Node.js バージョンに問題がある可能性があります。
**推奨ソリューション:** Node.js を AWS Cloud9にインストールする方法について、「[ステップ 1: 必要なツールをインストールする](sample-nodejs.md#sample-nodejs-install)」セクションを参照してください。