End of support notice: On October 7th, 2026, AWS will discontinue support for AWS IoT Greengrass Version 1. After October 7th, 2026, you will no longer be able to access the AWS IoT Greengrass V1 resources. For more information, please visit [Migrate from AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html).
# Access local resources with Lambda functions and connectors
This feature is available for AWS IoT Greengrass Core v1.3 and later.
With AWS IoT Greengrass, you can author AWS Lambda functions and configure [connectors](connectors.md) in the cloud and deploy them to core devices for local execution. On Greengrass cores running Linux, these locally deployed Lambda functions and connectors can access local resources that are physically present on the Greengrass core device. For example, to communicate with devices that are connected through Modbus or CANbus, you can enable your Lambda function to access the serial port on the core device. To configure secure access to local resources, you must guarantee the security of your physical hardware and your Greengrass core device OS.
To get started accessing local resources, see the following tutorials:
+ [How to configure local resource access using the AWS command line interface](lra-cli.md)
+ [How to configure local resource access using the AWS Management Console](lra-console.md)
## Supported resource types
You can access two types of local resources: volume resources and device resources.
**Volume resources**
Files or directories on the root file system (except under `/sys`, `/dev`, or `/var`). These include:
+ Folders or files used to read or write information across Greengrass Lambda functions (for example, `/usr/lib/python2.x/site-packages/local`).
+ Folders or files under the host's /proc file system (for example, `/proc/net` or `/proc/stat`). Supported in v1.6 or later. For additional requirements, see [Volume resources under the /proc directory](#lra-proc-resources).
To configure the `/var`, `/var/run`, and `/var/lib` directories as volume resources, first mount the directory in a different folder and then configure the folder as a volume resource.
When you configure volume resources, you specify a *source* path and a *destination* path. The source path is the absolute path of the resource on the host. The destination path is the absolute path of the resource inside the Lambda namespace environment. This is the container that a Greengrass Lambda function or connector runs in. Any changes to the destination path are reflected in the source path on the host file system.
Files in the destination path are visible in the Lambda namespace only. You can't see them in a regular Linux namespace.
**Device resources**
Files under `/dev`. Only character devices or block devices under `/dev` are allowed for device resources. These include:
+ Serial ports used to communicate with devices connected through serial ports (for example, `/dev/ttyS0`, `/dev/ttyS1`).
+ USB used to connect USB peripherals (for example, `/dev/ttyUSB0` or `/dev/bus/usb`).
+ GPIOs used for sensors and actuators through GPIO (for example, `/dev/gpiomem`).
+ GPUs used to accelerate machine learning using on-board GPUs (for example, `/dev/nvidia0`).
+ Cameras used to capture images and videos (for example, `/dev/video0`).
`/dev/shm` is an exception. It can be configured as a volume resource only. Resources under `/dev/shm` must be granted `rw` permission.
AWS IoT Greengrass also supports resource types that are used to perform machine learning inference. For more information, see [Perform machine learning inference](ml-inference.md).
## Requirements
The following requirements apply to configuring secure access to local resources:
+ You must be using AWS IoT Greengrass Core Software v1.3 or later. To create resources for the host's /proc directory, you must be using v1.6 or later.
+ The local resource (including any required drivers and libraries) must be correctly installed on the Greengrass core device and consistently available during use.
+ The desired operation of the resource, and access to the resource, must not require root privileges.
+ Only `read` or `read and write` permissions are available. Lambda functions cannot perform privileged operations on the resources.
+ You must provide the full path of the local resource on the operating system of the Greengrass core device.
+ A resource name or ID has a maximum length of 128 characters and must use the pattern `[a-zA-Z0-9:_-]+`.
### Volume resources under the /proc directory
The following considerations apply to volume resources that are under the host's /proc directory.
+ You must be using AWS IoT Greengrass Core Software v1.6 or later.
+ You can allow read-only access for Lambda functions, but not read-write access. This level of access is managed by AWS IoT Greengrass.
+ You might also need to grant OS group permissions to enable read access in the file system. For example, suppose your source directory or file has a 660 file permission, which means that only the owner or user in the group has read (and write) access. In this case, you must add the OS group owner's permissions to the resource. For more information, see [Group owner file access permission](#lra-group-owner).
+ The host environment and the Lambda namespace both contain a /proc directory, so be sure to avoid naming conflicts when you specify the destination path. For example, if /proc is the source path, you can specify /host-proc as the destination path (or any path name other than "*/proc*").
## Group owner file access permission
An AWS IoT Greengrass Lambda function process normally runs as `ggc_user` and `ggc_group`. However, you can give additional file access permissions to the Lambda function process in the local resource definition, as follows:
+ To add the permissions of the Linux group that owns the resource, use the `GroupOwnerSetting#AutoAddGroupOwner` parameter or **Automatically add file system permissions of the system group that owns the resource** console option.
+ To add the permissions of a different Linux group, use the `GroupOwnerSetting#GroupOwner` parameter or **Specify another system group to add file system permissions** console option. The `GroupOwner` value is ignored if `GroupOwnerSetting#AutoAddGroupOwner` is true.
An AWS IoT Greengrass Lambda function process inherits all of the file system permissions of `ggc_user`, `ggc_group`, and the Linux group (if added). For the Lambda function to access a resource, the Lambda function process must have the required permissions to the resource. You can use the `chmod(1)` command to change the permission of the resource, if necessary.
## See also
+ [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/greengrass.html#limits_greengrass) for resources in the *Amazon Web Services General Reference*
# How to configure local resource access using the AWS command line interface
This feature is available for AWS IoT Greengrass Core v1.3 and later.
To use a local resource, you must add a resource definition to the group definition that is deployed to your Greengrass core device. The group definition must also contain a Lambda function definition in which you grant access permissions for local resources to your Lambda functions. For more information, including requirements and constraints, see [Access local resources with Lambda functions and connectors](access-local-resources.md).
This tutorial describes the process for creating a local resource and configuring access to it using the AWS Command Line Interface (CLI). To follow the steps in the tutorial, you must have already created a Greengrass group as described in [Getting started with AWS IoT Greengrass](gg-gs.md).
For a tutorial that uses the AWS Management Console, see [How to configure local resource access using the AWS Management Console](lra-console.md).
## Create local resources
First, you use the `[CreateResourceDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createresourcedefinition-post.html)` command to create a resource definition that specifies the resources to be accessed. In this example, we create two resources, `TestDirectory` and `TestCamera`:
```
aws greengrass create-resource-definition --cli-input-json '{
"Name": "MyLocalVolumeResource",
"InitialVersion": {
"Resources": [
{
"Id": "data-volume",
"Name": "TestDirectory",
"ResourceDataContainer": {
"LocalVolumeResourceData": {
"SourcePath": "/src/LRAtest",
"DestinationPath": "/dest/LRAtest",
"GroupOwnerSetting": {
"AutoAddGroupOwner": true,
"GroupOwner": ""
}
}
}
},
{
"Id": "data-device",
"Name": "TestCamera",
"ResourceDataContainer": {
"LocalDeviceResourceData": {
"SourcePath": "/dev/video0",
"GroupOwnerSetting": {
"AutoAddGroupOwner": true,
"GroupOwner": ""
}
}
}
}
]
}
}'
```
**Resources**: A list of `Resource` objects in the Greengrass group. One Greengrass group can have up to 50 resources.
**Resource\$1Id**: The unique identifier of the resource. The ID is used to refer to a resource in the Lambda function configuration. Max length 128 characters. Pattern: [a-zA-Z0-9:\$1-]\$1.
**Resource\$1Name**: The name of the resource. The resource name is displayed in the Greengrass console. Max length 128 characters. Pattern: [a-zA-Z0-9:\$1-]\$1.
**LocalDeviceResourceData\$1SourcePath**: The local absolute path of the device resource. The source path for a device resource can refer only to a character device or block device under `/dev`.
**LocalVolumeResourceData\$1SourcePath**: The local absolute path of the volume resource on the Greengrass core device. This location is outside of the [container](lambda-group-config.md#lambda-function-containerization) that the function runs in. The source path for a volume resource type cannot start with `/sys`.
**LocalVolumeResourceData\$1DestinationPath**: The absolute path of the volume resource inside the Lambda environment. This location is inside the container that the function runs in.
**GroupOwnerSetting**: Allows you to configure additional group privileges for the Lambda process. This field is optional. For more information, see [Group owner file access permission](access-local-resources.md#lra-group-owner).
**GroupOwnerSetting\$1AutoAddGroupOwner**: If true, Greengrass automatically adds the specified Linux OS group owner of the resource to the Lambda process privileges. Thus the Lambda process has the file access permissions of the added Linux group.
**GroupOwnerSetting\$1GroupOwner**: Specifies the name of the Linux OS group whose privileges are added to the Lambda process. This field is optional.
A resource definition version ARN is returned by `[CreateResourceDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createresourcedefinition-post.html)`. The ARN should be used when updating a group definition.
```
{
"LatestVersionArn": "arn:aws:greengrass:us-west-2:012345678901:/greengrass/definition/resources/ab14d0b5-116e-4951-a322-9cde24a30373/versions/a4d9b882-d025-4760-9cfe-9d4fada5390d",
"Name": "MyLocalVolumeResource",
"LastUpdatedTimestamp": "2017-11-15T01:18:42.153Z",
"LatestVersion": "a4d9b882-d025-4760-9cfe-9d4fada5390d",
"CreationTimestamp": "2017-11-15T01:18:42.153Z",
"Id": "ab14d0b5-116e-4951-a322-9cde24a30373",
"Arn": "arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/resources/ab14d0b5-116e-4951-a322-9cde24a30373"
}
```
## Create the Greengrass function
After the resources are created, use the `[CreateFunctionDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createfunctiondefinition-post.html)` command to create the Greengrass function and grant the function access to the resource:
```
aws greengrass create-function-definition --cli-input-json '{
"Name": "MyFunctionDefinition",
"InitialVersion": {
"Functions": [
{
"Id": "greengrassLraTest",
"FunctionArn": "arn:aws:lambda:us-west-2:012345678901:function:lraTest:1",
"FunctionConfiguration": {
"Pinned": false,
"MemorySize": 16384,
"Timeout": 30,
"Environment": {
"ResourceAccessPolicies": [
{
"ResourceId": "data-volume",
"Permission": "rw"
},
{
"ResourceId": "data-device",
"Permission": "ro"
}
],
"AccessSysfs": true
}
}
}
]
}
}'
```
**ResourceAccessPolicies**: Contains the `resourceId` and `permission` which grant the Lambda function access to the resource. A Lambda function can access a maximum of 20 resources.
**ResourceAccessPolicy\$1Permission**: Specifies which permissions the Lambda function has on the resource. The available options are `rw` (read/write) or `ro` (read-only).
**AccessSysfs**: If true, the Lambda process can have read access to the `/sys` folder on the Greengrass core device. This is used in cases where the Greengrass Lambda function needs to read device information from `/sys`.
Again, `[CreateFunctionDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createfunctiondefinition-post.html)` returns a function definition version ARN. The ARN should be used in your group definition version.
```
{
"LatestVersionArn": "arn:aws:greengrass:us-west-2:012345678901:/greengrass/definition/functions/3c9b1685-634f-4592-8dfd-7ae1183c28ad/versions/37f0d50e-ef50-4faf-b125-ade8ed12336e",
"Name": "MyFunctionDefinition",
"LastUpdatedTimestamp": "2017-11-22T02:28:02.325Z",
"LatestVersion": "37f0d50e-ef50-4faf-b125-ade8ed12336e",
"CreationTimestamp": "2017-11-22T02:28:02.325Z",
"Id": "3c9b1685-634f-4592-8dfd-7ae1183c28ad",
"Arn": "arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/functions/3c9b1685-634f-4592-8dfd-7ae1183c28ad"
}
```
## Add the Lambda function to the group
Finally, use `[CreateGroupVersion](https://docs.aws.amazon.com/greengrass/v1/apireference/creategroupversion-post.html)` to add the function to the group. For example:
```
aws greengrass create-group-version --group-id "b36a3aeb-3243-47ff-9fa4-7e8d98cd3cf5" \
--resource-definition-version-arn "arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/resources/db6bf40b-29d3-4c4e-9574-21ab7d74316c/versions/31d0010f-e19a-4c4c-8098-68b79906fb87" \
--core-definition-version-arn "arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/cores/adbf3475-f6f3-48e1-84d6-502f02729067/versions/297c419a-9deb-46dd-8ccc-341fc670138b" \
--function-definition-version-arn "arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/functions/d1123830-da38-4c4c-a4b7-e92eec7b6d3e/versions/a2e90400-caae-4ffd-b23a-db1892a33c78" \
--subscription-definition-version-arn "arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/subscriptions/7a8ef3d8-1de3-426c-9554-5b55a32fbcb6/versions/470c858c-7eb3-4abd-9d48-230236bfbf6a"
```
**Note**
To learn how to get the group ID to use with this command, see [Getting the group ID](deployments.md#api-get-group-id).
A new group version is returned:
```
{
"Arn": "arn:aws:greengrass:us-west-2:012345678901:/greengrass/groups/b36a3aeb-3243-47ff-9fa4-7e8d98cd3cf5/versions/291917fb-ec54-4895-823e-27b52da25481",
"Version": "291917fb-ec54-4895-823e-27b52da25481",
"CreationTimestamp": "2017-11-22T01:47:22.487Z",
"Id": "b36a3aeb-3243-47ff-9fa4-7e8d98cd3cf5"
}
```
Your Greengrass group now contains the *lraTest* Lambda function that has access to two resources: TestDirectory and TestCamera.
This example Lambda function, `lraTest.py`, written in Python, writes to the local volume resource:
```
# Demonstrates a simple use case of local resource access.
# This Lambda function writes a file test to a volume mounted inside
# the Lambda environment under destLRAtest. Then it reads the file and
# publishes the content to the AWS IoT LRAtest topic.
import sys
import greengrasssdk
import platform
import os
import logging
# Setup logging to stdout
logger = logging.getLogger(__name__)
logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
# Create a Greengrass Core SDK client.
client = greengrasssdk.client('iot-data')
volumePath = '/dest/LRAtest'
def function_handler(event, context):
try:
client.publish(topic='LRA/test', payload='Sent from AWS IoT Greengrass Core.')
volumeInfo = os.stat(volumePath)
client.publish(topic='LRA/test', payload=str(volumeInfo))
with open(volumePath + '/test', 'a') as output:
output.write('Successfully write to a file.')
with open(volumePath + '/test', 'r') as myfile:
data = myfile.read()
client.publish(topic='LRA/test', payload=data)
except Exception as e:
logger.error('Failed to publish message: ' + repr(e))
return
```
These commands are provided by the Greengrass API to create and manage resource definitions and resource definition versions:
+ [CreateResourceDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createresourcedefinition-post.html)
+ [CreateResourceDefinitionVersion](https://docs.aws.amazon.com/greengrass/v1/apireference/createresourcedefinitionversion-post.html)
+ [DeleteResourceDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/deleteresourcedefinition-delete.html)
+ [GetResourceDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/getresourcedefinition-get.html)
+ [GetResourceDefinitionVersion](https://docs.aws.amazon.com/greengrass/v1/apireference/getresourcedefinitionversion-get.html)
+ [ListResourceDefinitions](https://docs.aws.amazon.com/greengrass/v1/apireference/listresourcedefinitions-get.html)
+ [ListResourceDefinitionVersions](https://docs.aws.amazon.com/greengrass/v1/apireference/listresourcedefinitionversions-get.html)
+ [UpdateResourceDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/updateresourcedefinition-put.html)
## Troubleshooting
+ **Q:** Why does my Greengrass group deployment fail with an error similar to:
```
group config is invalid:
ggc_user or [ggc_group root tty] don't have ro permission on the file: /dev/tty0
```
**A:** This error indicates that the Lambda process doesn't have permission to access the specified resource. The solution is to change the file permission of the resource so that Lambda can access it. (See [Group owner file access permission](access-local-resources.md#lra-group-owner) for details).
+ **Q:** When I configure `/var/run` as a volume resource, why does the Lambda function fail to start with an error message in the runtime.log:
```
[ERROR]-container_process.go:39,Runtime execution error: unable to start lambda container.
container_linux.go:259: starting container process caused "process_linux.go:345:
container init caused \"rootfs_linux.go:62: mounting \\\"/var/run\\\" to rootfs \\\"/greengrass/ggc/packages/1.3.0/rootfs_sys\\\" at \\\"/greengrass/ggc/packages/1.3.0/rootfs_sys/run\\\"
caused \\\"invalid argument\\\"\""
```
**A:** AWS IoT Greengrass core currently doesn't support the configuration of `/var`, `/var/run`, and `/var/lib` as volume resources. One workaround is to first mount `/var`, `/var/run` or `/var/lib` in a different folder and then configure the folder as a volume resource.
+ **Q:** When I configure `/dev/shm` as a volume resource with read-only permission, why does the Lambda function fail to start with an error in the runtime.log:
```
[ERROR]-container_process.go:39,Runtime execution error: unable to start lambda container.
container_linux.go:259: starting container process caused "process_linux.go:345:
container init caused \"rootfs_linux.go:62: mounting \\\"/dev/shm\\\" to rootfs \\\"/greengrass/ggc/packages/1.3.0/rootfs_sys\\\" at \\\"/greengrass/ggc/packages/1.3.0/rootfs_sys/dev/shm\\\"
caused \\\"operation not permitted\\\"\""”
```
**A:** `/dev/shm` can only be configured as read/write. Change the resource permission to `rw` to resolve the issue.
# How to configure local resource access using the AWS Management Console
This feature is available for AWS IoT Greengrass Core v1.3 and later.
You can configure Lambda functions to securely access local resources on the host Greengrass core device. *Local resources* refer to buses and peripherals that are physically present on the host, or file system volumes on the host OS. For more information, including requirements and constraints, see [Access local resources with Lambda functions and connectors](access-local-resources.md).
This tutorial describes how to use the AWS Management Console to configure access to local resources that are present on an AWS IoT Greengrass core device. It contains the following high-level steps:
1. [Create a Lambda function deployment package](#lra-console-create-package)
1. [Create and publish a Lambda function](#lra-console-create-function)
1. [Add the Lambda function to the group](#lra-console-add-function)
1. [Add a local resource to the group](#lra-console-create-resource)
1. [Add subscriptions to the group](#lra-console-add-subscription)
1. [Deploy the group](#lra-console-deploy-group)
For a tutorial that uses the AWS Command Line Interface, see [How to configure local resource access using the AWS command line interface](lra-cli.md).
## Prerequisites
To complete this tutorial, you need:
+ A Greengrass group and a Greengrass core (v1.3 or later). To create a Greengrass group or core, see [Getting started with AWS IoT Greengrass](gg-gs.md).
+ The following directories on the Greengrass core device:
+ /src/LRAtest
+ /dest/LRAtest
The owner group of these directories must have read and write access to the directories. You might use the following command to grant access:
```
sudo chmod 0775 /src/LRAtest
```
## Step 1: Create a Lambda function deployment package
In this step, you create a Lambda function deployment package, which is a ZIP file that contains the function's code and dependencies. You also download the AWS IoT Greengrass Core SDK to include in the package as a dependency.
1. On your computer, copy the following Python script to a local file named `lraTest.py`. This is the app logic for the Lambda function.
```
# Demonstrates a simple use case of local resource access.
# This Lambda function writes a file test to a volume mounted inside
# the Lambda environment under destLRAtest. Then it reads the file and
# publishes the content to the AWS IoT LRAtest topic.
import sys
import greengrasssdk
import platform
import os
import logging
# Setup logging to stdout
logger = logging.getLogger(__name__)
logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
# Create a Greengrass Core SDK client.
client = greengrasssdk.client('iot-data')
volumePath = '/dest/LRAtest'
def function_handler(event, context):
try:
client.publish(topic='LRA/test', payload='Sent from AWS IoT Greengrass Core.')
volumeInfo = os.stat(volumePath)
client.publish(topic='LRA/test', payload=str(volumeInfo))
with open(volumePath + '/test', 'a') as output:
output.write('Successfully write to a file.')
with open(volumePath + '/test', 'r') as myfile:
data = myfile.read()
client.publish(topic='LRA/test', payload=data)
except Exception as e:
logger.error('Failed to publish message: ' + repr(e))
return
```
1. From the [AWS IoT Greengrass Core SDK](what-is-gg.md#gg-core-sdk-download) downloads page, download the AWS IoT Greengrass Core SDK for Python to your computer.
1. Unzip the downloaded package to get the SDK. The SDK is the `greengrasssdk` folder.
1. Zip the following items into a file named `lraTestLambda.zip`:
+ `lraTest.py`. App logic.
+ `greengrasssdk`. Required library for all Python Lambda functions.
The `lraTestLambda.zip` file is your Lambda function deployment package. Now you're ready to create a Lambda function and upload the deployment package.
## Step 2: Create and publish a Lambda function
In this step, you use the AWS Lambda console to create a Lambda function and configure it to use your deployment package. Then, you publish a function version and create an alias.
First, create the Lambda function.
1. In the AWS Management Console, choose **Services**, and open the AWS Lambda console.
1. Choose **Functions**.
1. Choose **Create function** and then choose **Author from scratch**.
1. In the **Basic information** section, use the following values.
1. For **Function name**, enter **TestLRA**.
1. For **Runtime**, choose **Python 3.7**.
1. For **Permissions**, keep the default setting. This creates an execution role that grants basic Lambda permissions. This role isn't used by AWS IoT Greengrass.
1. Choose **Create function**.
![\[The Create function page with Create function highlighted.\]](http://docs.aws.amazon.com/greengrass/v1/developerguide/images/lra-console/create-function.png)
1. Upload your Lambda function deployment package and register the handler.
1. On the **Code** tab, under **Code source**, choose **Upload from**. From the dropdown, choose **.zip file**.
![\[The Upload from dropdown with .zip file highlighted.\]](http://docs.aws.amazon.com/greengrass/v1/developerguide/images/lra-console/upload-deployment-package.png)
1. Choose **Upload**, and then choose your `lraTestLambda.zip` deployment package. Then, choose **Save**.
1. On the **Code** tab for the function, under **Runtime settings**, choose **Edit**, and then enter the following values.
+ For **Runtime**, choose **Python 3.7**.
+ For **Handler**, enter **lraTest.function\$1handler**.
1. Choose **Save**.
**Note**
The **Test** button on the AWS Lambda console doesn't work with this function. The AWS IoT Greengrass Core SDK doesn't contain modules that are required to run your Greengrass Lambda functions independently in the AWS Lambda console. These modules (for example, `greengrass_common`) are supplied to the functions after they are deployed to your Greengrass core.
Next, publish the first version of your Lambda function. Then, create an [alias for the version](https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html).
Greengrass groups can reference a Lambda function by alias (recommended) or by version. Using an alias makes it easier to manage code updates because you don't have to change your subscription table or group definition when the function code is updated. Instead, you just point the alias to the new function version.
1. From **Actions**, choose **Publish new version**.
1. For **Version description**, enter **First version**, and then choose **Publish**.
1. On the **TestLRA: 1** configuration page, from **Actions**, choose **Create alias**.
1. On the **Create alias** page, for **Name**, enter **test**. For **Version**, enter **1**.
**Note**
AWS IoT Greengrass doesn't support Lambda aliases for **\$1LATEST** versions.
1. Choose **Create**.
![\[The Create a new alias page with Create highlighted.\]](http://docs.aws.amazon.com/greengrass/v1/developerguide/images/lra-console/create-alias.png)
You can now add the Lambda function to your Greengrass group.
## Step 3: Add the Lambda function to the Greengrass group
In this step, you add the function to your group and configure the function's lifecycle.
First, add the Lambda function to your Greengrass group.
1. In the AWS IoT console navigation pane, under **Manage**, expand **Greengrass devices**, and then choose **Groups (V1)**.
1. Choose the Greengrass group where you want to add the Lambda function.
1. On the group configuration page, choose the **Lambda functions** tab.
1. Under **My Lambda functions** section, choose **Add**.
1. On the **Add Lambda function** page, choose the **Lambda function**. Select **TestLRA**.
1. Choose the **Lambda function version**.
1. In the **Lambda function configuration** section, select **System user and group** and **Lambda function containerization**.
Next, configure the lifecycle of the Lambda function.
1. For **Timeout**, choose **30 seconds**.
**Important**
Lambda functions that use local resources (as described in this procedure) must run in a Greengrass container. Otherwise, deployment fails if you try to deploy the function. For more information, see [Containerization](lambda-group-config.md#lambda-function-containerization).
1. At the bottom of the page, choose **Add Lambda function**.
## Step 4: Add a local resource to the Greengrass group
In this step, you add a local volume resource to the Greengrass group and grant the function read and write access to the resource. A local resource has a group-level scope. You can grant permissions for any Lambda function in the group to access the resource.
1. On the group configuration page, choose the **Resources** tab.
1. Under the **Local resources** section, choose **Add**.
1. On the **Add a local resource** page, use the following values.
1. For **Resource name**, enter **testDirectory**.
1. For **Resource type**, choose **Volume**.
1. For **Local device path**, enter **/src/LRAtest**. This path must exist on the host OS.
The local device path is the local absolute path of the resource on the file system of the core device. This location is outside of the [container](lambda-group-config.md#lambda-function-containerization) that the function runs in. The path can't start with `/sys`.
1. For **Destination path**, enter **/dest/LRAtest**. This path must exist on the host OS.
The destination path is the absolute path of the resource in the Lambda namespace. This location is inside the container that the function runs in.
1. Under **System group owner and file access permission**, select **Automatically add file system permissions of the system group that owns the resource**.
The **System group owner and file access permission** option lets you grant additional file access permissions to the Lambda process. For more information, see [Group owner file access permission](access-local-resources.md#lra-group-owner).
1. Choose **Add resource**. The **Resources** page displays the new testDirectory resource.
## Step 5: Add subscriptions to the Greengrass group
In this step, you add two subscriptions to the Greengrass group. These subscriptions enable bidirectional communication between the Lambda function and AWS IoT.
First, create a subscription for the Lambda function to send messages to AWS IoT.
1. On the group configuration page, choose the **Subscriptions** tab.
1. Choose **Add**.
1. On the **Create a subscription** page, configure the source and target, as follows:
1. For **Source type**, choose **Lambda function**, and then choose **TestLRA**.
1. For **Target type**, choose **Service**, and then choose **IoT Cloud**.
1. For **Topic filter**, enter **LRA/test**, and then choose **Create subscription**.
1. The **Subscriptions** page displays the new subscription.
Next, configure a subscription that invokes the function from AWS IoT.
1. On the **Subscriptions** page, choose **Add Subscription**.
1. On the **Select your source and target** page, configure the source and target, as follows:
1. For **Source type**, choose **Lambda function**, and then choose **IoT Cloud**.
1. For **Target type**, choose **Service**, and then choose **TestLRA**.
1. Choose **Next**.
1. On the **Filter your data with a topic** page, for **Topic filter**, enter **invoke/LRAFunction**, and then choose **Next**.
1. Choose **Finish**. The **Subscriptions** page displays both subscriptions.
## Step 6: Deploy the AWS IoT Greengrass group
In this step, you deploy the current version of the group definition.
1. Make sure that the AWS IoT Greengrass core is running. Run the following commands in your Raspberry Pi terminal, as needed.
1. To check whether the daemon is running:
```
ps aux | grep -E 'greengrass.*daemon'
```
If the output contains a `root` entry for `/greengrass/ggc/packages/1.11.6/bin/daemon`, then the daemon is running.
**Note**
The version in the path depends on the AWS IoT Greengrass Core software version that's installed on your core device.
1. To start the daemon:
```
cd /greengrass/ggc/core/
sudo ./greengrassd start
```
1. On the group configuration page, choose **Deploy**.
**Note**
Deployment fails if you run your Lambda function without containerization and try to access attached local resources.
1. If prompted, on the **Lambda function** tab, under **System Lambda functions**, select **IP detector**, and then **Edit**, and then **Automatically detect**.
This enables devices to automatically acquire connectivity information for the core, such as IP address, DNS, and port number. Automatic detection is recommended, but AWS IoT Greengrass also supports manually specified endpoints. You're only prompted for the discovery method the first time that the group is deployed.
**Note**
If prompted, grant permission to create the [Greengrass service role](service-role.md) and associate it with your AWS account in the current AWS Region. This role allows AWS IoT Greengrass to access your resources in AWS services.
The **Deployments** page shows the deployment timestamp, version ID, and status. When completed, the deployment status is **Completed**.
For troubleshooting help, see [Troubleshooting AWS IoT Greengrass](gg-troubleshooting.md).
## Test local resource access
Now you can verify whether the local resource access is configured correctly. To test, you subscribe to the `LRA/test` topic and publish to the `invoke/LRAFunction` topic. The test is successful if the Lambda function sends the expected payload to AWS IoT.
1. From the AWS IoT console navigation menu, under **Test**, choose **MQTT test client**.
1. Under **Subscribe to a topic**, for **Topic filter**, enter **LRA/test**.
1. Under **Additional information**, for **MQTT payload display**, select **Display payloads as strings**.
1. Choose **Subscribe**. Your Lambda function publishes to the LRA/test topic.
![\[The Subscriptions page with Subscribe to topic highlighted.\]](http://docs.aws.amazon.com/greengrass/v1/developerguide/images/lra-console/test-subscribe.png)
1. Under **Publish to a topic**, in the **Topic name**enter **invoke/LRAFunction**, and then choose **Publish** to invoke your Lambda function. The test is successful if the page displays the function's three message payloads.
![\[The Subscriptions page with the invoke/LRAFunction topic and Publish to topic highlighted, and test results with message data.\]](http://docs.aws.amazon.com/greengrass/v1/developerguide/images/lra-console/test-publish.png)
The test file created by the Lambda function is in the `/src/LRAtest` directory on the Greengrass core device. Although the Lambda function writes to a file in the `/dest/LRAtest` directory, that file is visible in the Lambda namespace only. You can't see it in a regular Linux namespace. Any changes to the destination path are reflected in the source path on the file system.
For troubleshooting help, see [Troubleshooting AWS IoT Greengrass](gg-troubleshooting.md).