[Errno 13] Permission denied: '/var/task/function.py'

What it means

A zip archive stores POSIX permission bits alongside each file, and Lambda preserves them when it extracts your package into /var/task. That is usually invisible and occasionally decisive: a file packaged without read permission for other users arrives unreadable, and the runtime cannot load it even though it is sitting exactly where the handler configuration says.

The reason this catches people is that everything looks correct. The file is in the archive. The handler string matches. Listing the package shows it there. Only the mode column distinguishes a working deployment from this error, and almost nobody looks at the mode column.

The runtime does not execute as the file's owner, so "readable by me" is not the property that matters — "readable by others" is. A file with mode 600 is entirely normal on a developer machine, where you own it, and unreadable in /var/task.

Two build environments produce this reliably. Containers: a build running as root inside Docker creates files owned by root, often with a restrictive umask, and those modes travel into the zip. Cross-platform archivers: some tools write no permission information at all, leaving the extractor to choose defaults that may not include read access. Both reproduce nowhere except in the pipeline that built them, which is why this tends to appear after a CI change that touched no code.

Directories are worth checking as well as files, because the failure they cause is misattributed. A directory without its execute bit cannot be traversed, so a perfectly readable file inside it is unreachable — and the error names the file, sending you to inspect permissions that are already correct. 644 for files, 755 for directories, applied in the packaging step, covers every version of this.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

The path in the message is the giveaway: /var/task/ is where your deployment package is extracted, so this is your own code rather than anything of AWS's. It appears right after INIT_START, before any of your logging, because the file could not be read to be loaded.

Distinguish it from the file being absent. "Permission denied" means the runtime found it and was refused; "cannot find" or "no such file" means it was not there. They come from the same initialization step and have completely different fixes, and the archive listing tells you which you have in one command.

Causes, most likely first

Fixes

bashfind dist -type f -exec chmod 644 {} +
find dist -type d -exec chmod 755 {} +
cd dist && zip -qr ../function.zip . && cd ..

# The mode column should read -rw-r--r-- for files.
unzip -Z function.zip | head

bashdocker run --rm \
  --user "$(id -u):$(id -g)" \
  -v "$PWD":/var/task \
  public.ecr.aws/lambda/nodejs:22 \
  npm ci --omit=dev

bashunzip -Z function.zip | awk '$1 ~ /^d/ { print }' | head

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Troubleshoot deployment issues
• AWS Lambda Developer Guide — Deploy Lambda functions with .zip file archives