Being able to connect your AWS Lambda Serverless function to an EFS file system opens the door to a lot of new uses for Lambda functions. You are no longer limited to 512 MB of /tmp/ storage, which is shared across all active invocations. You can use the EFS file system to read, write, and work with large files, or large sets of files easily. Unfortunately there are a few common issues and errors you may encounter while linking your EFS file system to your Lambda function.
“The function couldn’t connect to the Amazon EFS file system with access point”
If you are having trouble connecting to your EFS File System Access Point from your AWS Lambda Function, and you get an error like “The function couldn’t connect to the Amazon EFS file system with access point ….” the issue is likely a networking problem you need to solve with security groups.
By default your EFS File System will take on the default Security Group for your VPC for each AZ connection. If that Security Group doesn’t allow for NFS (TCP port 2049) traffic from the Lambda to the EFS file system, you will get the error above. Personally I don’t like to use the default security group for much, as it can either be too permissive, or too automatic. I want all my networking rules to be specific and applied with forethought.
To solve this issue, I recommend creating a new Security Group, under the VPC area of the AWS Console. I named mine “VPC-EFS-Access”. For my needs I am happy to allow NFS access to the EFS file system from anywhere in my VPC. I setup both Inbound Rules and Outbound Rules (although I think the Outbound rules may be unnecessary). On both Inbound and Outbound I allow traffic on TCP port 2049 (NFS) and for Source and Destination I add a rule each for both the VPC’s IPv4 subnet, and the IPv6 subnet.
EFS-SG-Inbound
Then go into the EFS section of the AWS Console, go into File Systems. Then select the EFS File System you are trying to mount from your AWS Lambda function. Click on the Network tab (far right), and then click on the Manage button (right side of the screen). Now for each of the Availability Zones, select your new Security Group and add it to each AZ, and Save.
This should allow your Lambda to access your EFS File System without connectivity or network issues!
“EACCES: permission denied”
If you get an error accessing files (reading or writing) on your EFS mount from your AWS Lambda function, it may be due to a path mismatch.
This wasn’t clear to me while setting things up initially, but the EFS Access Point’s Root Directory Path setting has to align with the Lambda’s EFS Mount’s Local Mount Path setting. Basically the EFS Access Point’s Root Directory Path has to be the same as the EFS Mount’s Local Mount Path, minus the “/mnt” prefix, and vice versa.
If you leave the EFS Access Point’s path to the default of “/”, then the Lambda’s Mount path must be “/mnt/”. If you want the Lambda Mount path to be “/mnt/myproject” then you MUST set the EFS Access Point’s path to “/myproject”. Once these settings align, you should be able to access the EFS file system from your AWS Lambda function.
If you run into any other issues mounting your EFS volume for your AWS Lambda functions, let me know! I can add solutions to common issues to this post!
In EFS Access point I have give as /opt/test/packs. In Lambda I have given /mnt/efs. When I am listing the files from /mnt/efs I can see all the folders inside that. but when I was trying to create a file inside the /mnt/efs i am getting the “errorMessage”: “[Errno 13] Permission denied: ‘/mnt/efs/demo/requirements-tests.txt'”,
Mano, try to fix your paths to line up as I’ve discussed in the last section of this article. If you leave the Access Point path as “/opt/test/packs”, then try the Lambda mount path of “/mnt/opt/test/packs”. See if that fixes your error.
Hi Devon. thanks a lot for sharing this article. I was able to quickly fix this issue with your help.