Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #3999] [FEAT]: Add configurable --no-sandbox flag for Chromium/Puppeteer on unsupported kernels (e.g. Synology DSM) #2544

New Issue
Closed
opened 2026-02-22 18:30:08 -05:00 by yindo · 3 comments
yindo commented 2026-02-22 18:30:08 -05:00
Owner
Copy Link
Copy Source

Originally created by @Sarmingsteiner on GitHub (Jun 13, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3999

Originally assigned to: @timothycarambat on GitHub.

What would you like to see?

On Synology DSM devices, the custom Linux kernel obviously does not support Chromium’s native SUID sandbox. As a result, Anything LLM’s collector process fails to launch Chromium/Puppeteer with the following error:

[collector] error: Failed to scrape https://www.xyz.com. Error: Failed to launch the browser process!
[FATAL:zygote_host_impl_linux.cc(127)] No usable sandbox! Update your kernel or see …
If you want to live dangerously … try using --no-sandbox.

So far, not a single attempt - neither manual Docker entrypoint overrides nor command overrides - has been successful in reliably suppressing the sandbox error message.

It would be extremely helpful to expose a setting (e.g. ANYTHINGLLM_CHROME_FLAGS or similar) so that users on unsupported platforms can simply toggle sandboxing off without forking or rebuilding the container image.

Originally created by @Sarmingsteiner on GitHub (Jun 13, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3999 Originally assigned to: @timothycarambat on GitHub. ### What would you like to see? On Synology DSM devices, the custom Linux kernel obviously does not support Chromium’s native SUID sandbox. As a result, Anything LLM’s collector process fails to launch Chromium/Puppeteer with the following error: ``` [collector] error: Failed to scrape https://www.xyz.com. Error: Failed to launch the browser process! [FATAL:zygote_host_impl_linux.cc(127)] No usable sandbox! Update your kernel or see … If you want to live dangerously … try using --no-sandbox. ``` So far, not a single attempt - neither manual Docker entrypoint overrides nor command overrides - has been successful in reliably suppressing the sandbox error message. It would be extremely helpful to expose a setting (e.g. ANYTHINGLLM_CHROME_FLAGS or similar) so that users on unsupported platforms can simply toggle sandboxing off without forking or rebuilding the container image.
yindo added the enhancementDockerfeature request labels 2026-02-22 18:30:09 -05:00
yindo closed this issue 2026-02-22 18:30:09 -05:00
yindo commented 2026-02-22 18:30:09 -05:00
Author
Owner
Copy Link
Copy Source

@AbanoubNassem commented on GitHub (Jun 17, 2025):

facing the same exact issue , also the documents drop down is broken

@AbanoubNassem commented on GitHub (Jun 17, 2025): facing the same exact issue , also the documents drop down is broken
yindo commented 2026-02-22 18:30:09 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jun 24, 2025):

also the documents drop down is broken

@AbanoubNassem Any information, screenshots, or anything that could describe or help anyone repro your issue would be nice to see. Otherwise this is too ambigious. Are you on Docker, Desktop, etc etc

@Sarmingsteiner Understood, this kind of configuration can possibly achieve this by a manually set ENV in the associated storage ENV file via a param string. eg: PUPEETEER_ENVS="--no-sandbox,--disable-setuid-sandbox" which can get this to work. Will attach PR when done.

Its obviously not something we really want to encourage since it can cause security issues, but if someone is in this situation anyway, they likely understand the risks anyways

@timothycarambat commented on GitHub (Jun 24, 2025): > also the documents drop down is broken @AbanoubNassem Any information, screenshots, or anything that could describe or help anyone repro your issue would be nice to see. Otherwise this is too ambigious. Are you on Docker, Desktop, etc etc @Sarmingsteiner Understood, this kind of configuration can possibly achieve this by a _manually_ set ENV in the associated storage ENV file via a param string. eg: `PUPEETEER_ENVS="--no-sandbox,--disable-setuid-sandbox"` which can get this to work. Will attach PR when done. Its obviously not something we really want to encourage since it can cause security issues, but if someone is in this situation anyway, they likely understand the risks anyways
yindo commented 2026-02-22 18:30:09 -05:00
Author
Owner
Copy Link
Copy Source

@spartako commented on GitHub (Aug 11, 2025):

This SE answer helped me understand the security implications of this. Seems clear to me now that running a container with the SYS_ADMIN cap is way worse than running with the --no-sandbox flag as long as you are doing it within an already isolated environment (such as the container). An env var would definitely be helpful here to let the admin decide.

@spartako commented on GitHub (Aug 11, 2025): [This](https://security.stackexchange.com/a/239202) SE answer helped me understand the security implications of this. Seems clear to me now that running a container with the SYS_ADMIN cap is way worse than running with the --no-sandbox flag as long as you are doing it within an already isolated environment (such as the container). An env var would definitely be helpful here to let the admin decide.
yindo changed title from [FEAT]: Add configurable --no-sandbox flag for Chromium/Puppeteer on unsupported kernels (e.g. Synology DSM) to [GH-ISSUE #3999] [FEAT]: Add configurable --no-sandbox flag for Chromium/Puppeteer on unsupported kernels (e.g. Synology DSM) 2026-06-05 14:47:09 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label Docker enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2544
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?