Troubleshooting AWS Cloud9

Use the following information to help you identify and address issues with AWS Cloud9.

If your issue is not listed, or if you need additional help, see the AWS Cloud9 Discussion Forum. (When you enter this forum, AWS might require you to sign in.) You can also contact us directly.

Environment creation error: "We are unable to create EC2 instances ..."

Issue: When you try to create an AWS Cloud9 development environment, a message appears with the phrase "We are unable to create EC2 instances in your account during account verification and activation."

Cause: AWS is currently verifying and activating your AWS account. Until activation is complete, which could take up to 24 hours, you can't create this or other environments.

Solution: Try creating the environment again later. If you're still receiving this message after 24 hours, email [e-mail]. Be advised that AWS CloudFormation creates a related stack in your account, even though the attempt to create an environment fails. These stacks count against the stack creation limit in your account. To help avoid the stack creation limit, you can safely delete these failed stacks. For more information, see Deleting a Stack on the AWS CloudFormation Console in the AWS CloudFormation User Guide.

(back to top)

Environment creation error: "Not authorized to perform sts:AssumeRole"

Issue: When you try to create a new environment, you see this error: "Not authorized to perform sts:AssumeRole," and the environment is not created.

Possible causes: An AWS Cloud9 service-linked role doesn't exist in your AWS account.

Recommended solutions: Create an AWS Cloud9 service-linked role in your AWS account by running the following command with the AWS Command Line Interface (AWS CLI) or the aws-shell.

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.

If you cannot do this, check with your AWS account administrator.

After you run this command, try creating the environment again.

(back to top)

Console error: "User is not authorized to perform action on resource"

Issue: When you try to use the AWS Cloud9 console to create or manage an AWS Cloud9 development environment, you see an error that contains a phrase similar to "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," where:

• arn:aws:iam::123456789012:user/MyUser is the Amazon Resource Name (ARN) of the requesting user.

• action is the name of the operation that the user requested.

• arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1 is the ARN of the environment that the user requested to run the operation.

Cause: The user you signed in to the AWS Cloud9 console with doesn't have the correct AWS access permissions to perform the action.

Solution: Ensure the user has the correct AWS access permissions, and then try to perform the action again. For more information, see one or more of the following:

• Step 3: Add AWS Cloud9 access permissions to the group in Team Setup

• Step 6. Enable groups and users within the organization to use AWS Cloud9 in Enterprise Setup

• About environment member access roles in Working with Shared Environments

(back to top)

Federated identities cannot create environments

Issue: When you try to use an AWS federated identity to create an AWS Cloud9 development environment, an access error message is displayed, and the environment isn't created.

Cause: : AWS Cloud9 uses service-linked roles. The service-linked role is created the first time an environment is created in an account using the iam:CreateServiceLinkedRole call. However, federated users can't call IAM APIs. For more information, see GetFederationToken in the AWS Security Token Service API Reference.

Solution: Ask an AWS account administrator to create the service-linked role for AWS Cloud9 either in the IAM console or by running this command with the AWS Command Line Interface (AWS CLI):

aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com

Or this command with the aws-shell:

iam create-service-linked-role --aws-service-name cloud9.amazonaws.com

For more information, see Using Service-Linked Roles in the IAM User Guide.

(back to top)

Cannot open an environment

Issue: When you try to open an environment, the IDE does not display for a long time (after at least five minutes).

Possible causes:

• The IAM user that is signed in to the AWS Cloud9 console does not have the required AWS access permissions to open the environment.

• If the environment is associated with an AWS cloud compute instance (for example an Amazon EC2 instance):

  • The instance's associated VPC is not set to the correct settings for AWS Cloud9.

  • The instance is transitioning between states or is failing automated status checks, during the time when AWS Cloud9 is trying to connect to the instance.

• If the environment is an SSH environment, the associated cloud compute instance or your own server is not set up correctly to allow AWS Cloud9 to access it.

Recommended solutions:

• Make sure the IAM user that is signed in to the AWS Cloud9 console has the required AWS access permissions to open the environment, and then try opening the environment again. For more information see the following, or check with your AWS account administrator:

  • Step 3: Add AWS Cloud9 access permissions to the group in Team Setup

  • AWS managed policies for AWS Cloud9 in Authentication and Access Control

  • Customer managed policy examples for teams using AWS Cloud9 in Advanced Team Setup

  • Customer managed policy examples in Authentication and Access Control

  • Changing Permissions for an IAM User in the IAM User Guide

  • Troubleshoot IAM Policies in the IAM User Guide

  If the signed-in IAM user still cannot open the environment, you could try signing out and then signing back in as either the AWS account root user or an IAM administrator user in the account. Then try opening the environment again. If you are able to open the environment in this way, then there is most likely a problem with the IAM user's access permissions.

• If the environment is associated with an AWS cloud compute instance (for example an Amazon EC2 instance):

  • Make sure the instance's associated VPC is set to the correct settings for AWS Cloud9, and then try opening the environment again. For details, see Amazon VPC requirements for AWS Cloud9.

    If the AWS cloud compute instance's associated VPC is set to the correct settings for AWS Cloud9 and you still cannot open the environment, the instance's security group might be preventing access to AWS Cloud9. As a troubleshooting technique only, check the security group to make sure that at minimum, inbound SSH traffic is allowed over port 22 for all IP addresses (Anywhere or 0.0.0.0/0). For instructions, see Describing Your Security Groups and Updating Security Group Rules in the Amazon EC2 User Guide for Linux Instances.

    For additional VPC troubleshooting steps, watch the related 5-minute video AWS Knowledge Center Videos: What can I check if I cannot connect to an instance in a VPC? on the YouTube website.

    Warning

    When you have finished troubleshooting, be sure to set the inbound rules to an appropriate address range, as described in Inbound SSH IP address ranges for AWS Cloud9.

  • Restart the instance, make sure the instance is running and has passed all system checks, and then try opening the environment again. For details, see Reboot Your Instance and Viewing Status Checks in the Amazon EC2 User Guide for Linux Instances.

• If the environment is an SSH environment, make sure the associated cloud compute instance or your own server is set up correctly to allow AWS Cloud9 to access it, and then try opening the environment again. For details, see SSH environment host requirements.

(back to top)

The AWS Cloud9 installer hangs or fails

Issue: When you download and run the AWS Cloud9 Installer, one or more error messages display, and the installer script does not show Done.

Cause: The AWS Cloud9 Installer has encountered one or more errors that it cannot recover from and therefore fails.

Solution: See common issues, their possible causes, and recommended solutions, in Troubleshooting the AWS Cloud9 Installer.

(back to top)

SSH environment error: "Python version 2.7 is required to install pty.js"

Issue: After you open an AWS Cloud9 SSH development environment, the terminal in the AWS Cloud9 IDE displays a message that begins with "Python version 2.7 is required to install pty.js."

Cause: To work as expected, an SSH environment requires that Python version 2.7 is installed.

Solution: Install Python version 2.7 in the environment. To check your version, from your server's terminal, run the command python --version . To install Python 2.7 on your server, see one of the following:

• Step 1: Install Python in the Python Sample.

• Download Python on the Python website and Installing Packages in the Python Packaging User Guide.

(back to top)

Application preview or file preview notice: "Third-party cookies disabled"

Issue: When you attempt to preview an application or a file, a notice is displayed with the following message: "Preview functionality is disabled because your browser has third-party cookies disabled."

Cause: Although third-party cookies are not needed to open the AWS Cloud9 IDE, you must enable third-party cookies to use the Application Preview or File Preview features.

Solution: Enable third-party cookies in your web browser, reload your IDE, and then try opening the preview again.

• Apple Safari: Manage cookies and website data in Safari on the Apple Support website.

• Google Chrome: Change your cookie settings in Clear, enable, and manage cookies in Chrome on the Google Chrome Help website.

• Internet Explorer: Block or allow cookies in Delete and manage cookies on the Microsoft Support website.

• Microsoft Edge: Blocking third-party cookies on the Microsoft Support website.

• Mozilla Firefox: Accept third party cookies setting in Enable and disable cookies that websites use to track your preferences on the Mozilla Support website.

• Any other web browser: see that web browser's documentation.

To enable third-party cookies only for AWS Cloud9 (if your web browser allows this granularity), specify the following domains, depending on the supported AWS Regions where you want to use AWS Cloud9.

AWS Region	Domains
US East (N. Virginia)	*.vfs.cloud9.us-east-1.amazonaws.com vfs.cloud9.us-east-1.amazonaws.com
US East (Ohio)	*.vfs.cloud9.us-east-2.amazonaws.com vfs.cloud9.us-east-2.amazonaws.com
US West (N. California)	*.vfs.cloud9.us-west-1.amazonaws.com vfs.cloud9.us-west-1.amazonaws.com
US West (Oregon)	*.vfs.cloud9.us-west-2.amazonaws.com vfs.cloud9.us-west-2.amazonaws.com
Asia Pacific (Hong Kong)	*.vfs.cloud9.ap-east-1.amazonaws.com vfs.cloud9.ap-east-1.amazonaws.com
Asia Pacific (Mumbai)	*.vfs.cloud9.ap-south-1.amazonaws.com vfs.cloud9.ap-south-1.amazonaws.com
Asia Pacific (Seoul)	*.vfs.cloud9.ap-northeast-2.amazonaws.com vfs.cloud9.ap-northeast-2.amazonaws.com
Asia Pacific (Singapore)	*.vfs.cloud9.ap-southeast-1.amazonaws.com vfs.cloud9.ap-southeast-1.amazonaws.com
Asia Pacific (Sydney)	*.vfs.cloud9.ap-southeast-2.amazonaws.com vfs.cloud9.ap-southeast-2.amazonaws.com
Asia Pacific (Tokyo)	*.vfs.cloud9.ap-northeast-1.amazonaws.com vfs.cloud9.ap-northeast-1.amazonaws.com
Canada (Central)	*.vfs.cloud9.ca-central-1.amazonaws.com vfs.cloud9.ca-central-1.amazonaws.com
Europe (Frankfurt)	*.vfs.cloud9.eu-central-1.amazonaws.com vfs.cloud9.eu-central-1.amazonaws.com
Europe (Ireland)	*.vfs.cloud9.eu-west-1.amazonaws.com vfs.cloud9.eu-west-1.amazonaws.com
Europe (London)	*.vfs.cloud9.eu-west-2.amazonaws.com vfs.cloud9.eu-west-2.amazonaws.com
Europe (Milan)	*.vfs.cloud9.eu-south-1.amazonaws.com vfs.cloud9.eu-south-1.amazonaws.com
Europe (Paris)	*.vfs.cloud9.eu-west-3.amazonaws.com vfs.cloud9.eu-west-3.amazonaws.com
Europe (Stockholm)	*.vfs.cloud9.eu-north-1.amazonaws.com vfs.cloud9.eu-north-1.amazonaws.com
Middle East (Bahrain)	*.vfs.cloud9.me-south-1.amazonaws.com vfs.cloud9.me-south-1.amazonaws.com
South America (São Paulo)	*.vfs.cloud9.sa-east-1.amazonaws.com vfs.cloud9.sa-east-1.amazonaws.com

(back to top)

Application preview tab displays an error or is blank

Issue: On the menu bar in the IDE, when you choose Preview, Preview Running Application or Tools, Preview, Preview Running Application to try to display your application on a preview tab in the IDE, the tab displays an error, or the tab is blank.

Possible causes:

• Your application is not running in the IDE.

• Your application is not running using HTTP.

• Your application is running over more than one port.

• Your application is running over a port other than 8080, 8081, or 8082.

• Your application is running with an IP other than 127.0.0.1, localhost, or 0.0.0.0.

• The port (8080, 8081, or 8082) is not specified in the URL on the preview tab.

• Your network blocks inbound traffic to ports 8080, 8081, or 8082.

• You are trying to go to an address that contains an IP of 127.0.0.1, localhost, or 0.0.0.0. The default, built-in behavior of the AWS Cloud9 IDE is that this will attempt to go to your local computer instead of attempting to go the instance or your own server that is connected to the environment.

Recommended solutions:

• Ensure that the application is running in the IDE.

• Ensure that the application is running using HTTP. For examples in Node.js and Python, see Run an application.

• Ensure that the application is running over only one port. For examples in Node.js and Python, see Run an application.

• Ensure that the application is running over port 8080, 8081, or 8082. For examples in Node.js and Python, see Run an application.

• Ensure that the application is running with an IP of 127.0.0.1, localhost, or 0.0.0.0. For examples in Node.js and Python, see Run an application.

• Add :8080, :8081, or :8082 to the URL on the preview tab.

• Ensure that your network allows inbound traffic over ports 8080, 8081, or 8082. If you cannot make changes to your network, see your network administrator.

• If you are trying to go to an address that contains an IP of 127.0.0.1, localhost, or 0.0.0.0, try going to the following address instead: https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/, where 12a34567b8cd9012345ef67abcd890e1 is the ID that AWS Cloud9 assigns to the environment, and us-east-2 is the ID of the AWS Region for the environment. You can also try to go to this address outside of the IDE, but it works only when the IDE for the environment is open and the application is running in the same web browser.

• After you are sure that all of the preceding conditions are met, try stopping the application and then starting it again.

• If you stopped the application and then started it again, try choosing Preview, Preview Running Application or Tools, Preview, Preview Running Application on the menu bar again. Or try choosing the Refresh button (the circular arrow) on the corresponding application preview tab, if the tab is already visible.

(back to top)

Cannot display your running application outside of the IDE

Issue: When you or others try to display your running application in a web browser tab outside of the IDE, that web browser tab displays an error, or the tab is blank.

Possible causes:

• The application is not running in the IDE.

• The application is running with an IP of 127.0.0.1 or localhost.

• The application is running in an AWS Cloud9 EC2 development environment, and one or more security groups that are associated with the corresponding Amazon EC2 instance do not allow inbound traffic over the protocols, ports, or IP addresses that the application requires.

• The application is running in an AWS Cloud9 SSH development environment for an AWS cloud compute instance (for example an Amazon EC2 instance), and the network ACL for the subnet in the virtual private cloud (VPC) that is associated with the corresponding instance does not allow inbound traffic over the protocols, ports, or IP addresses that the application requires.

• The URL is incorrect.

• The URL in the application preview tab is being requested instead of the instance's public IP address.

• You are trying to go to an address that contains an IP of 127.0.0.1 or localhost. These IPs will attempt to access resources on your local computer instead of resources in the environment.

• The instance's public IP address has changed.

• The web request originates from a virtual private network (VPN) that blocks traffic over the protocols, ports, or IP addresses that the application requires.

• The application is running in an SSH environment, and your server or the associated network does not allow traffic over the protocols, ports, or IP addresses that the application requires.

Recommended solutions:

• Ensure that the application is running in the IDE.

• Ensure that the application is not running with an IP of 127.0.0.1 or localhost. For some examples in Node.js and Python, see Run an application.

• If the application is running on an AWS cloud compute instance (for example an Amazon EC2 instance), ensure all security groups that are associated with the corresponding instance allow inbound traffic over the protocols, ports, and IP addresses that the application requires. For instructions, see Step 2: Set up the security group for the instance in Share a running application over the internet. See also Security Groups for Your VPC in the Amazon VPC User Guide.

• If the application is running on an AWS cloud compute instance, and a network ACL exists for the subnet in the VPC that is associated with the corresponding instance, ensure that network ACL allows inbound traffic over the protocols, ports, and IP addresses that the application requires. For instructions, see Step 3: Set up the subnet for the instance in Share a running application over the internet. See also Network ACLs in the Amazon VPC User Guide.

• Ensure that the requesting URL, including the protocol (and port, if it must be specified), is correct. For more information, see Step 5: Share the running application URL in Share a running application over the internet.

• We do not recommend requesting a URL with the format https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/ (where 12a34567b8cd9012345ef67abcd890e1 is the ID that AWS Cloud9 assigns to the environment, and us-east-2 is the ID of the AWS Region for the environment). This URL works only when the IDE for the environment is open and the application is running in the same web browser.

• If you are trying to go to an address that contains an IP of 127.0.0.1 or localhost, try going to the correct non-local address for the running application instead. For more information, see Share a running application over the internet.

• If the application is running on an AWS cloud compute instance, determine whether the instance's public IP address has changed. The instance's public IP address might change anytime the instance restarts. To prevent this IP address from changing, you can allocate an Elastic IP address and assign it to the running instance. For more information, see Step 5: Share the running application URL in Share a running application over the internet.

• If the web request originates from a VPN, ensure that VPN allows traffic over the protocols, ports, and IP addresses that the application requires. If you cannot make changes to your VPN, see your network administrator. Or make the web request from a different network if possible.

• If the application is running in an SSH environment for your own server, ensure your server and the associated network allow traffic over the protocols, ports, and IP addresses that the application requires. If you cannot make changes to your server or the associated network, see your server or network administrator.

• Try running the application from a terminal in the environment by running the curl command, followed by the URL. If this command displays an error message, there might be some other issue that is not related to AWS Cloud9.

(back to top)

After reloading an environment, you must refresh application preview

Issue: After you reload an environment that displays an application preview tab, the tab doesn't display the application preview.

Cause: Sometimes users write code that can run an infinite loop or that otherwise uses so much memory that the AWS Cloud9 IDE can pause or stop when the application preview is running. To keep this from happening, AWS Cloud9 doesn't reload application preview tabs whenever an environment is reloaded.

Solution: After you reload an environment that displays an application preview tab, to display the application preview, choose the Click to load the page button on the tab.

(back to top)

Cannot run some commands or scripts in an EC2 environment

Issue: After you open an AWS Cloud9 EC2 development environment, you cannot install some types of packages, run commands such as yum or apt, or run scripts containing commands that typically work with other Linux operating systems.

Cause: The Amazon EC2 instances that AWS Cloud9 uses for an EC2 environment rely on either Amazon Linux (which is based on Red Hat Enterprise Linux (RHEL)) or Ubuntu Server.

Solution: If you install or manage packages or run commands or scripts in the IDE for an EC2 environment, ensure they are compatible with either RHEL (for Amazon Linux) or Ubuntu Server, depending on the instance for that environment.

(back to top)

AWS CLI / aws-shell error: "The security token included in the request is invalid" in an EC2 environment

Issue: When you try to use the AWS Command Line Interface (AWS CLI) or the aws-shell to run a command in the AWS Cloud9 IDE for an EC2 environment, an error displays: "The security token included in the request is invalid."

Cause: An invalid security token can result if you have AWS managed temporary credentials enabled and one of the following occurred:

• You tried to run a command that's not allowed by AWS managed temporary credentials. For a list of allowed commands, see Actions supported by AWS managed temporary credentials.

• The AWS managed temporary credentials automatically expired after 15 minutes.

• The AWS managed temporary credentials for a shared environment were deactivated because a new member was added by someone other than the environment owner.

Recommended solutions:

• Run only those commands that are allowed by AWS managed temporary credentials. If you need to run a command that's not allowed by AWS managed temporary credentials, you can configure the AWS CLI or aws-shell in the environment with a set of permanent credentials, which removes this limitation. For instructions, see Create and store permanent access credentials in an Environment.

• For deactivated or expired credentials, ensure the environment owner opens the environment so that AWS Cloud9 can refresh temporary credentials in the environment. For more information, see Controlling access to AWS managed temporary credentials.

(back to top)

Amazon EC2 instances are not automatically updated

Issue: Recent system updates are not automatically applied to an Amazon EC2 instance that connects to an AWS Cloud9 development environment.

Cause: Automatically applying recent system updates could cause your code or the Amazon EC2 instance to behave in unexpected ways, without your prior knowledge or approval.

Recommended solutions:

Apply system updates to the Amazon EC2 instance on a regular basis by following the instructions in Updating Instance Software in the Amazon EC2 User Guide for Linux Instances.

To run commands on the instance, you can use a terminal session in the AWS Cloud9 IDE from the environment that is connected to the instance.

Alternatively, you can use an SSH remote access utility such as ssh or PuTTY to connect to the instance. To do this, from your local computer, use an SSH key pair creation utility such as ssh-keygen or PuTTYgen. Use the AWS Cloud9 IDE from the environment that is connected to the instance to store the generated public key on the instance. Then use the SSH remote access utility along with the generate private key to access the instance. For more information, see your utility's documentation.

(back to top)

Lambda local function run error: Cannot install SAM Local

Issue: After you try to run the local version of an AWS Lambda function in the AWS Cloud9 IDE, a dialog box is displayed, stating that AWS Cloud9 is having trouble installing SAM Local. AWS Cloud9 needs SAM Local to run local versions of AWS Lambda functions in the IDE. Until SAM Local is installed, you cannot run local versions of Lambda functions in the IDE.

Cause: AWS Cloud9 can't find SAM Local at the expected path in the environment, which is ~/.c9/bin/sam. This is because SAM Local is not yet installed, or if it is installed, AWS Cloud9 can't find it at that location.

Recommended solutions: You can wait for AWS Cloud9 to try to finish installing SAM Local, or you can install it yourself.

To see how AWS Cloud9 is doing with attempting to install SAM Local, choose Window, Installer on the menu bar.

To install SAM Local yourself, follow the instructions provided by Installing the AWS SAM CLI on Linux in the AWS Serverless Application Model Developer Guide.

IDE warning: "This environment is running low on memory" or "This environment has high CPU load"

Issue: While the IDE is running, you see a message that contains the phrase "this environment is running low on memory" or "this environment has high CPU load."

Cause: The IDE might not have enough compute resources available to continue running without delays or hangs.

Recommended solutions:

• Stop one or more running processes to free up available memory. To do this, on the menu bar in the IDE for the environment, choose Tools, Process List. For each process you want to stop, choose the process, and then choose Force Kill.

• Create a swap file in the environment. A swap file is a file in the environment that the operating system can use as virtual memory.

  To confirm whether the environment is currently using swap memory, run the top command in a terminal session in the environment. If swap memory is being used, the output displays non-zero Swap memory statistics (for example, Swap: 499996k total, 1280k used, 498716 free, 110672k cached). To stop showing real-time memory information, press Ctrl + C.

  To create a swap file, you could run a command such as the following in the environment.

  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

  The preceding command does the following:

  1. Creates a 512 MB file named swapfile in the /var directory.

  2. Changes access permissions for the swapfile file to read-write for the owner only.

  3. Sets up the swapfile file as a swap file.

  4. Writes information to the /etc/fstab file, which makes this swap file available whenever the system reboots.

  After you run the preceding command, to make this swap file available immediately instead of waiting for a reboot, run the following command.

  sudo swapon /var/swapfile

• Move or resize the environment to an instance or server with more compute resources. To move or resize Amazon EC2 instances, see Moving an environment and resizing or encrypting Amazon EBS volumes. For other instance or server types, refer to your instance's or server's documentation.

(back to top)

Previewing a file returns a 499 error

Issue: When you try to use the AWS Cloud9 IDE to preview a file that contains a <script> element containing the src attribute and with the type attribute set to module, a 499 error occurs and the script doesn't run as expected.

Cause: File preview fetch requests in the AWS Cloud9 IDE require cookies to be sent by the web browser to authenticate. By default, web browsers send cookies for regular script requests, but not for module script requests, unless you add the crossorigin attribute.

Solution: Add the crossorigin attribute to the <script> element. For example, <script type="module" src="index.js" crossorigin></script>. Then save the changed file, and try to preview the it again.

(back to top)

Environment deletion error: "One or more environments failed to delete"

Issue: When you try to delete one or more environments in the AWS Cloud9 console, a message is displayed that reads "one or more environments failed to delete," and at least one of the environments is not deleted.

Possible cause: AWS CloudFormation might have a problem deleting one or more of the environments. (AWS Cloud9 relies on AWS CloudFormation to create and delete environments.)

Recommended solution: Try using AWS CloudFormation to delete each of the undeleted environments, as follows.

1. Open the AWS CloudFormation console at https://console.aws.amazon.com/cloudformation.

2. On the AWS navigation bar, choose the AWS Region for the environment.

3. In the list of AWS CloudFormation stacks, select the entry where Stack name contains the undeleted environment name and Status is DELETE_FAILED. For example, if the environment name is my-demo-environment, choose the stack that begins with the name aws-cloud9-my-demo-environment. (Choose the box or option next to the environment name, not the environment name itself.)

4. Choose Actions, Delete Stack.

5. If prompted, choose Yes, Delete.

The process of deleting a stack might take a few minutes.

If the stack disappears from the list, the environment is now deleted.

If the stack is still displays displayed with DELETE_FAILED after a few minutes, the environment is still not deleted. In this case, you can try to manually delete each of the failed stack's resources.

Note

Manually deleting a failed stack's resources doesn't remove the stack itself from your AWS account.

To manually delete these resources, in the AWS CloudFormation console, choose the failed stack, and then select the Resources section. Go to the console in AWS for each resource in this list, and then use that console to manually delete the resource.

(back to top)

Console warning: "Switching to the minimal code completion engine..."

Issue: When working in the AWS Cloud9 console (for example, when opening the IDE or refreshing the IDE's web page), you see this message: "One or more sessions or collaborators are active on this environment. Switching to the minimal code completion engine to conserve memory." In correlation with this message, the code-completion behavior might be slow or intermittent.

Cause: Running the code-completion engine takes memory and CPU cycles from the environment. Additionally, a separate code-completion engine is required for each collaborator and each additional session. To avoid using too many resources, especially on small instance sizes like t2.nano and t2.micro, AWS Cloud9 switches to the minimal code-completion engine.

Recommended solution: If you will be collaborating often and for long periods of time, choose a larger Amazon EC2 instance when creating your EC2 environment (or connect your SSH environment to an instance with more capacity).

Note

Choosing a larger Amazon EC2 instance might result in additional charges to your AWS account. For more information, see Amazon EC2 Pricing.

(back to top)

AWS Cloud9 installer doesn't finish after displaying: "Package Cloud9 IDE 1"

Issue: AWS Cloud9 is installed on your existing Amazon EC2 instance or on your own server as part of the process of creating an SSH development environment. The installation stalls after you see this message in the AWS Cloud9 Installer dialog box: "Package Cloud9 IDE 1". If you choose Cancel, you see the following message: "Installation Failed." This error occurs when AWS Cloud9 packages can't be installed on the customer's SSH host.

Cause: An SSH host requires that you have Node.js installed. We currently support versions from Node.js 0.6.16 to Node.js 12.x An installation error can occur if you have a version of Node.js on your host that AWS Cloud9 doesn't support.

Recommended solution: Install a version of Node.js that AWS Cloud9 supports on your SSH host.

(back to top)

VPC error for EC2-Classic accounts: "Unable to access your environment"

Issue: EC2-Classic was introduced in the original release of Amazon EC2. If you're using an AWS account that was set up before December 4, 2013, this error might occur if you don't explicitly configure a virtual private cloud (Amazon VPC) and subnet when creating an AWS Cloud9 EC2 development environment.

If you accept the default VPC settings, the Amazon EC2 instance is launched into the EC2-Classic network and not into a subnet of the default VPC. The following message is displayed when the creation of the environment fails:

Environment Error

Unable to access your environment

The environment creation failed with the error: The following resource(s) failed to create: [Instance]. . Rollback requested by user..

You can confirm that the error is caused by the EC2 instance not being in the default VPC. Use AWS CloudFormation to view the stack event history for the development environment.

1. Open the AWS CloudFormation console. For more information, see Logging in to the AWS CloudFormation console.

2. In the AWS CloudFormation console, choose Stacks.

3. On the Stacks page, choose the name of the development environment that failed to create.

4. On the Stack details page, choose the Events tab and check for the following entry:

   Status: CREATE_FAILED

   Status reason: The AssociatePublicIpAddress parameter is only supported by VPC launches. [...]

Cause: An AWS Cloud9 development environment must be associated with an Amazon VPC that meets specific VPC requirements. For accounts with EC2-Classic enabled, accepting the default network settings when creating an EC2 environment means that the required EC2 instance isn't launched into the VPC. Instead, the instance is launched into the EC2-Classic network.

Recommended solution: With an EC2-Classic account, you must select a VPC and subnet when creating an EC2 environment. On the Configure settings page, in the Network settings (advanced) section, select the VPC and subnet that you can launch your EC2 instance into.

(back to top)

Unable to open AWS Cloud9 environment: "This environment cannot be currently accessed by collaborators. Please wait until the removal of managed temporary credentials is complete, or contact the owner of this environment."

Issue: If a new collaborator is added to an environment by someone who is not the environment owner, AWS managed temporary credentials are disabled. The credentials are disabled by the deletion of the ~/.aws/credentials file. While the deletion of the ~/.aws/credentials file is progressing, new collaborators can't access the AWS Cloud9 environment.

Cause: Preventing access to the environment during the deletion of AWS managed temporary credentials is a security measure. It allows environment owners to confirm that only trusted collaborators have access to managed credentials. If they're satisfied that the list of collaborators is valid, environment owners can re-enable managed credentials so they can be shared. For more information, see Controlling access to AWS managed temporary credentials.

Recommended solutions: You can wait for the deletion of the ~/.aws/credentials file to complete before trying again to open the AWS Cloud9 environment. The maximum waiting time for credentials expiry is 15 minutes. Alternatively, ask the environment owner to re-enable or disable the managed temporary credentials. After the credentials are re-enabled or disabled, collaborators can immediately access the environment. (By toggling the state of managed credentials to ENABLED or DISABLED, the environment owner ensures the credentials don't remain in an intermediate state that prevents collaborators from accessing the environment.)

Note

If the environment owner and collaborator belong to the same AWS account, the collaborator can identify the environment owner to contact by reviewing the card for an environment in the Your environments page on the console. The environment owner is also listed in the Environment details page.

(back to top)

Error message reporting "Instance profile AWSCloud9SSMInstanceProfile does not exist in account" when creating EC2 environment using AWS CloudFormation

Issue: When using the AWS::Cloud9::EnvironmentEC2 AWS CloudFormation resource to create an EC2 environment, users receive an error message that Instance profile AWSCloud9SSMInstanceProfile does not exist in account.

Cause: When creating a no-ingress EC2 environment, you must create the service role AWSCloud9SSMAccessRole and the instance profile AWSCloud9SSMInstanceProfile. These IAM resources enable Systems Manager to manage the EC2 instance that backs your development environment.

If you create a no-ingress environment with the console, AWSCloud9SSMAccessRole and AWSCloud9SSMInstanceProfile are created automatically. But when using AWS CloudFormation or AWS CLI to create your first no-ingress environment, you must create these IAM resources manually.

Recommended solution: For information on editing your AWS CloudFormation template and updating IAM permissions, see Using AWS CloudFormation to create no-ingress EC2 environments

Error message reporting "not authorized to perform: ssm:StartSession on resource" when creating EC2 environment using AWS CloudFormation

Issue: When using the AWS::Cloud9::EnvironmentEC2 AWS CloudFormation resource to create an EC2 environment, users receive an AccessDeniedException and are informed that they're "not authorized to perform: ssm:StartSession on resource".

Cause: The user lacks the permission to call the StartSession API that's required as part of the configuration for EC2 environments that use Systems Manager for no-ingress instances.

Recommended solution: For information on editing your AWS CloudFormation template and updating IAM permissions, see Using AWS CloudFormation to create no-ingress EC2 environments.

(back to top)

Unable to connect to EC2 environment because VPC's IP addresses are used by Docker

Issue: For an EC2 environment, if you launch the EC2 instance into an Amazon VPC (virtual private cloud) that uses the IPv4 Classless Inter-Domain Routing (CIDR) block 172.17.0.0/16, the connection may stall when you try to open that environment.

Cause: Docker uses a link layer device called a bridge network that enables containers connected to the same bridge network to communicate. AWS Cloud9 creates containers that use a default bridge for container communication. The default bridge typically uses the 172.17.0.0/16 subnet for container networking.

If the VPC subnet for your environment's instance uses the same address range that's already used by Docker, an IP address conflict can occur. So when AWS Cloud9 tries to connect its instance, that connection is routed by the gateway route table to the Docker bridge instead of the EC2 instance. This prevents AWS Cloud9 from connecting to the EC2 instance that backs the development environment.

Recommended solution: To resolve an IP address conflict caused by Amazon VPC and Docker using the same IPv4 CIDR address block, configure a new VPC for the instance backing your EC2 environment. For this new VPC, configure a CIDR block that's different from 172.17.0.0/16. (You cannot change the IP address range of an existing VPC or subnet.)

For configuration information, see VPC and subnet sizing in the Amazon VPC User Guide.

(back to top)

Error when running AWS Toolkit: "Your environment is running out of inodes, please increase 'fs.inotify.max_user_watches' limit."

Issue: A file watcher utility used by AWS Toolkit is approaching its current limit of files it can watch.

Cause: AWS Toolkit uses a file watcher utility that monitors changes to files and directories. A warning message appears when the utility is nearly at its current limit of files it can watch.

Recommended solution: To increase the maximum number of files that can be handled by file watcher, do the following:

1. Start a terminal session by choosing Window, New Terminal on the menu bar.

2. Enter the following at the command line:

   sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p

(back to top)

Notice: Failed to install dependencies for collaboration support

Issue: AWS Cloud9 needs internet access to download dependencies. If AWS Cloud9 cannot download those dependencies, you will see a Notice dialog box with the following error.

Failed to install dependencies for collaboration support
      
Please try to resolve this problem and refresh the page to enable collaboration support. A common cause is a lack of available disk space. Error was:
      
Error downloading from location
<LINK> to <LOCATION>
Problem was: Error: connect ETIMEDOUT <IPADDRESS>

Possible causes: If your AWS Cloud9 environment is using a proxy to access the internet, AWS Cloud9 needs the proxy details to install dependencies. This error will appear if you have not provided your proxy details to AWS Cloud9.

Recommended solutions: To provide your proxy details to AWS Cloud9, append the following to your environment's ~/.bashrc file.

export http_proxy=<proxy url for http>
export https_proxy=<proxy url for https>

For example, if your http proxy URL is http://172.31.26.80:3128 and your https proxy URL is https://172.31.26.80:3129, add the following lines to your ~/.bashrc file.

export http_proxy=http://172.31.26.80:3128
export https_proxy=https://172.31.26.80:3129

Note

If these environment variables are present in /etc/profile but not ~/.bashrc, AWS Cloud9 cannot use them as /etc/profile is intended only for login shells. Because /etc/profile also loads ~/.bashrc, putting the configuration in ~/.bashrc will ensure the environment variables are available to both login shells and AWS Cloud9.

(back to top)

Error with gdb when debugging C++ projects

Issue: Error reported for gdb debugger when trying to debug C++ project in the IDE.

Possible causes: If your AWS Cloud9 environment uses certain EC2 instance types (such as t3.small or m5.large, for example), a debug error may occur when you try to run and debug a C++ project using the IDE's built-in runner. This error can happen because the version of the gdb (the GNU Project Debugger) that's pre-installed for your environment doesn't work on certain processor platforms. You may see the following error code:

GDB server terminated with code 1

Recommended solutions: The problem with gdb not supporting certain processor platforms was fixed from version 3.0 onwards. So uninstall the older version of the debugger and upgrade to a newer version of gdb:

1. Remove the existing version of the debugger by running the following command in the AWS Cloud9 terminal:

   sudo yum -y remove gdb

2. Retrieve the archive for gdb, unpack it, and then navigate to the directory that contains the extracted files by running the following commands:

   wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
   tar xzf gdb-8.3.tar.gz
   cd gdb-8.3                          

3. Now build the debugger by running the following command (paste the text below as a single block and press Return to run make):

   ./configure --prefix=/usr \
               --with-system-readline \
               --with-python=/usr/bin/python3 &&
   make

4. Now install the debugger:

   sudo make -C gdb install

5. Finally, confirm that the updated version of the debugger is installed:

    gdb --version

(back to top)

Error running SAM applications locally in AWS Toolkit because the AWS Cloud9 environment doesn't have enough disk space

Issue: Error occurs when you use the AWS Toolkit to run AWS SAM CLI commands for applications defined by SAM templates.

Possible causes: When you run and debug serverless applications locally with the AWS Toolkit, AWS SAM uses Docker images that provide a runtime environment and build tools that emulate the Lambda environment that you're planning to deploy to.

But if your environment's lacks enough disk space, the Docker image providing these features can't build and your local SAM application fails to run. If this occurs, you may receive an error in the Output tab similar to the following :

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.

This error relates to a SAM application that's built using the Python runtime. You may receive a slightly different message, depending on the runtime that you chose for your application.

Recommended solutions: Free up disk space in your environment so the Docker image can build. Remove any unused Docker images by running the following command in the IDE's terminal:

docker image prune -a

If you're repeatedly having issues with SAM CLI commands because of disk-space restrictions, consider switching to a development environment uses a different instance type.

(back to top)

Unable to load IDE using older versions of Microsoft Edge browser

Issue: HTTP403: FORBIDDEN error is returned when trying to load AWS Cloud9 IDE using the Microsoft Edge web browser.

Possible causes: The AWS Cloud9 IDE doesn't support certain older versions of Microsoft Edge.

Recommended solutions: To update the browser, choose the ellipsis (...) button in the Microsoft Edge toolbar. From the menu, choose Settings and then choose About Microsoft Edge. If an update is required, it's automatically downloaded and installed.

(back to top)

Failure to create environment when default encryption is applied to Amazon EBS volumes

Issue: Failed to create environments. The development environment '[environment-ID]' failed to create error is returned when trying to create an Amazon EC2 environment.

Possible causes: If your AWS Cloud9 IDE uses Amazon EBS volumes that are encrypted by default, the AWS Identity and Access Management service-linked role for AWS Cloud9 requires access to the AWS Key Management Service (AWS KMS) customer master key (CMK) for these EBS volumes. If access is not provided, the AWS Cloud9 IDE might fail to launch and debugging might be difficult.

Recommended solutions: To provide access, add the service-linked role for AWS Cloud9, AWSServiceRoleForAWSCloud9, to the CMK that's used by your Amazon EBS volumes.

For more information on this task, see Create an AWS Cloud9 that uses Amazon EBS volumes with default encryption in AWS Prescriptive Guidance Patterns.

(back to top)