/tmp/chromium: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory Vercel

Question

when I try to access my API uploaded on vercel server, I'm getting this error.

Did anyone have the same error?

When I run it locally, it works fine.

2021-02-15T19:38:59.218Z 0109b575-a2e7-478e-aefe-aa3335b5b6b8 ERROR Error: Failed to launch the browser process! /tmp/chromium: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md at onClose (/var/task/node_modules/puppeteer-core/lib/cjs/puppeteer/node/BrowserRunner.js:193:20) at Interface. (/var/task/node_modules/puppeteer-core/lib/cjs/puppeteer/node/BrowserRunner.js:183:68) at Interface.emit (events.js:327:22) at Interface.close (readline.js:424:8) at Socket.onend (readline.js:202:10) at Socket.emit (events.js:327:22) at endReadableNT (internal/streams/readable.js:1327:12) at processTicksAndRejections (internal/process/task_queues.js:80:21)

code

import puppeteer, { Page } from 'puppeteer-core'
import chrome from 'chrome-aws-lambda'

export async function getOptions() {
  const isDev = !process.env.AWS_REGION
  let options;

  const chromeExecPaths = {
    win32: 'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
    linux: '/usr/bin/google-chrome',
    darwin: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
  }
  
  const exePath = chromeExecPaths[process.platform]

  if (isDev) {
    options = {
      args: [],
      executablePath: exePath,
      headless: true
    }
  } else {
    options = {
      args: chrome.args,
      executablePath: await chrome.executablePath,
      headless: chrome.headless
    }
  }

  return options
}

let _page: Page | null
async function getPage(): Promise<Page> {
  if (_page) {
    return _page
  }

  const options = await getOptions()
  const browser = await puppeteer.launch(options)

  _page = await browser.newPage()

  return _page
}


export async function getScreenshot(html: string, { width, height } = { width: 800, height: 800 }) {
  const page = await getPage();

  await page.setContent(html);
  await page.setViewport({ width, height });

  const file = await page.screenshot({ type: 'png' });

  return file;
}

Answer 1

I encountered an issue while deploying my project's Docker image to AWS Lambda. Everything was working fine initially, but it suddenly stopped working and threw a libnss3.so error. Strangely, the code was working fine without the Docker container.

After investigating, I discovered that Docker now defaults to using Node.js version 20 when not explicitly defined in the Dockerfile.

Before:

FROM amazon/aws-lambda-nodejs

Fix:

FROM amazon/aws-lambda-nodejs:18

This fix explicitly specifies Node.js version 18 in the Dockerfile, resolving the issue. If you're facing a similar problem, this adjustment might save you some troubleshooting time.

Answer 2

The chrome-aws-lambda project seems to be abandoned as of Sep 2023; the last commit was 2 years ago.

The sparticuz/chromium is a fork of chrome-aws-lambda, and it is well-maintained at the time of writing. There are minor differences in the API, but porting my old code to sparticuz/chromium was quick and easy.

I was able to get everything up and running on AWS Lambda with Node.js 18 on the first attempt; all went smoothly. Consider putting sparticuz/chromium into a Lambda layer to avoid the 50MB limit of Lambda.

Answer 3

I faced this issue while working with linux server, you should install missing dependancies by using below command and restart your nodejs server.

apt-get install ca-certificates fonts-liberation libappindicator3-1 libasound2 libatk-bridge2.0-0 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 libgcc1 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 lsb-release wget xdg-utils

Answer 4

For people who are actually using Vercel and not AWS:

The problem correctly lies in the Node.js version of your app. You must use Node.js 14 instead of 16 like all other answers mentioned. To do this on Vercel, do 2 things:

1. Go to your project's Settings page, in the General tab, Node.js Version section: Select 14.x

2. Inside your app's package.json, under engines, set "node": "^14"

// package.json

{
  ...
  "engines": {
    "node": "^14"
  }
  ...
}

Reference: Vercel documentation

Answer 5

I didn't notice that my serverless.yml was on runtime: nodejs16.x. When I changed it to nodejs14.x I was able to run without this error on AWS Lambda.

Error

"/tmp/chromium: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory"

Fix

Changed serverless.yml to

provider:
  name: aws
  runtime: nodejs14.x

and redeployed

Answer 6

I had the same issue where puppeteer was running okay on my local environment but when i deployed to AWS EC2 i face up the same error shared loading libraries Solution

1. First check the version of nodejs you are running and if its not less than v14.0 or greater than v14.0. Upgrade or downgrade (recommended to upgrade) and restart your app then try.

The most common cause is a bug in Node.js v14.0.0 which broke extract-zip, the module Puppeteer uses to extract browser downloads into the right place. The bug was fixed in Node.js v14.1.0, so please make sure you're running that version or higher. Alternatively, if you cannot upgrade, you could downgrade to Node.js v12, but we recommend upgrading when possible.

2. Trivial:- Make sure the directory where your project folder is located is not owned by root.

For those who might have experience this issue while running on windows enviroment, You can try to pass ignoreDefaultArgs: ['--disable-extensions'] option when launching it chromium from code i.e

const browser = await puppeteer.launch({ignoreDefaultArgs: ['--disable-extensions']})

This will deactivate default behaviour of puppeteer from disabling any extensions usually used by chromium/chrome.

Linux and MAcOS uses

The issues that results in this error

UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process! error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory TROUBLESHOOTING

is mostly but not all the times caused by missing dependencies that are required in the latest version. The good thing is you can easily check the missing chrome dependencies causing the crash.

• Make sure you are in the root folder of your project
• Navigate to node_modules folder
• Navigate to the folder where puppeteer chrome Linux tools are installed

• cd /project_folder/node_modules/puppeteer/.local-chromium/linux-some number/chrome-linux
  replace the linux-some number with whatever ls will output
• ls at /.local-chromium to check name of your directory

• At the last directory [ chrome-linux ] run below command to check the missing dependencies

  ldd chrome | grep not

if you see any missing dependencies, run this command to install everything and restart your application.

sudo apt-get install ca-certificates fonts-liberation libappindicator3-1 libasound2 libatk-bridge2.0-0 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 libgcc1 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 lsb-release wget xdg-utils

Voila!! everything should be fixed

Answer 7

Thanks to @andrew-mititi and his awesome answer, I was able to solve the issue in my environment, which is Docker FROM node:16 (which is Debian GNU/Linux 10) + puppeteer v13 (not puppeteer-core). I did the following steps:

• build & run Docker container: make build & docker run
• go to container: docker exec -it CONTAINER_ID /bin/bash
• find pptr chromium folder: ls project_folder/node_modules/puppeteer/.local-chromium, it was linux-961656 in my case
• find next folder: ls project_folder/node_modules/puppeteer/.local-chromium/linux-961656, it was chrome-linux
• run missing-dependencies script in that folder: ldd node_modules/puppeteer/.local-chromium/linux-961656/chrome-linux/chrome | grep not, it should show something like

    libnss3.so => not found
    libnssutil3.so => not found
    libsmime3.so => not found
    libnspr4.so => not found
    libatk-1.0.so.0 => not found
    libatk-bridge-2.0.so.0 => not found
    libcups.so.2 => not found
    libdrm.so.2 => not found
    libdbus-1.so.3 => not found
    libxkbcommon.so.0 => not found
    libXcomposite.so.1 => not found
    libXdamage.so.1 => not found
    libXfixes.so.3 => not found
    libXrandr.so.2 => not found
    libgbm.so.1 => not found
    libasound.so.2 => not found
    libatspi.so.0 => not found

The last step was to convert this list into correct apt-get command and add it to the Docker make-script after installing the project's npm dependencies. In my case it was:

RUN apt-get update && apt-get install -y libnss3 libnspr4 libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 libxkbcommon0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 libasound2

Answer 8

For anyone having libnss3.so: cannot open shared object file issue on aws lambda. For me the fix was to bump both chrome-aws-lambda and puppeteer-core to version >= 6.0.0 - this is minimum version required while running runtime: nodejs14.x.

Answer 9

Try adding jontewks/puppeteer-heroku-buildpack buildpack. Adding this buildpack worked for me.

heroku buildpacks:add jontewks/puppeteer

Also don't forget to trigger build with a commit.