n8n - Puppeteer - shared libraries failure
-
I'm trying to use Puppeteer in n8n and getting an error. Normally I would just install the package, but since these are in a docker container and
/var/lib/dpkg
is read-only, that doesn't seem like it will work. Does anyone have a workaround, either for getting puppeteer to work or to install packages in an app? I don't want to use a 3rd party browserless/headless service.Problem in node βPuppeteerβ
Failed to launch/connect to browser: Failed to launch the browser process! /home/cloudron/.cache/puppeteer/chrome/linux-135.0.7049.84/chrome-linux64/chrome: error while loading shared libraries: libatk-1.0.so.0: cannot open shared object file: No such file or directory TROUBLESHOOTING: https://pptr.dev/troubleshooting
-
Hey @djxx
Please see: https://docs.cloudron.io/apps/n8n/#custom-node-modules
This might solve your issue alreadyFor the forum seo and searchability tho
Custom node modules
To install custom node modules, edit
/app/data/env.sh
using the File manager:# note: this is a space separated list export EXTRA_NODE_MODULES="handlebars@4.7.7 jsonata@2.0.2 marked@4.3.0"
The modules have to be whitelisted for use:
# note: this is a comma separated list export NODE_FUNCTION_ALLOW_EXTERNAL=handlebars,jsonata,marked
Restart the app and use the module in Function nodes. Restarting the app will install the modules specified in
EXTRA_NODE_MODULES
automatically. See upstream docs for more information. -
@BrutalBirdie - thanks, but these are Node modules and not OS modules. Luckily, I did find a workaround. Step by step, I found all the missing modules, downloaded the deb files from https://packages.debian.org/, then extracted them into =
/app/data/libatk/
(because that was the first missing library)After this, I discovered the entrypoint script calls an editable script and edited
/app/data/env.sh
with these lines:export PATH="/app/data/libatk:$PATH" export LD_LIBRARY_PATH="/app/data/libatk"
Once I did this, I was able to enable
Add Container Arguments
on the Puppeteer nodes options in n8n and it worked just fine. The "container arguments" has it ignore all sandboxing best practices (which is OK since we're running in a container).It would be good if the base n8n application for Cloudron would include the dependencies mentioned above, because my hack will get overwritten at each application update.
-
OH WOW! This is one impressive hack I've not seen or thought of yet.
Impressive!
I don't think this is how the/app/data/env.sh
was ever intended to extend thePATH
variable.
But it works!I believe, I do not have to tell you that these librarys do not get automatically updated. And thus might be a security risk. If you are able to pull off this stunt, you must know this
@djxx said in n8n - Puppeteer - shared libraries failure:
because my hack will get overwritten at each application update.
No, no it will not
since you store everything in
/app/data/
this is part of the backup.
Nothing in/app/data/
will be overwritten with an app update. -
Yes, I've been doing this for years, you just have to make /app/data friendly enough for apps to find what they need. This generally involves setting a few env variables:
- HOME
- PATH (including NODE_PATH avoiding npm i -g)
- LD_LIBRARY_PATH (less common)
- other app specific ENVs
All of these changes do not affect the running app since it's already running with its own ENVs.
So these are great for additional services.Nice work @djxx