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 #4763] Docker v1.9.1 crashes on Synology NAS while v1.9.0 works (Weaviate) #3005

New Issue
Closed
opened 2026-02-22 18:32:13 -05:00 by yindo · 7 comments
yindo commented 2026-02-22 18:32:13 -05:00
Owner
Copy Link
Copy Source

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

Description:
After upgrading from AnythingLLM v1.9.0 to v1.9.1 in Docker on a Synology NAS, the container crashes as soon as any query is submitted.

  • Docker image / tag: v1.9.1
  • Platform: Synology NAS (CPU without AVX2 support)
  • Previous working version: v1.9.0
  • Observed behavior: Container stops/crashes immediately after submitting a query.
  • Expected behavior: Container should process queries normally, as in v1.9.0.
  • Logs: No error messages appear in container logs.

Steps to reproduce:

  1. Pull or build Docker image for AnythingLLM v1.9.1.
  2. Run container on Synology NAS.
  3. Submit any query to the LLM.
  4. Observe that the container crashes immediately, with no logs indicating the cause.
  5. Downgrading to v1.9.0 restores normal functionality.

Additional info / suspected cause:

  • Internal Ollama binaries may require CPU instructions (e.g., AVX2) that are not available on some Synology NAS models.
  • We are using Weaviate as the database backend. There were also changes in v1.9.1 related to scoring (see changelog), which might contribute to the crash.
  • No illegal instruction message or log is displayed inside the container.

Request:
Please investigate the crash in the v1.9.1 Docker image on Synology NAS systems. Note that we are using Weaviate as the database backend, and there were changes related to scoring in this version that might be relevant. The internal Ollama binaries may also use CPU instructions such as AVX2, which could contribute to the issue. A solution or workaround for NAS environments would be appreciated.

Originally created by @Sarmingsteiner on GitHub (Dec 11, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4763 Description: After upgrading from AnythingLLM v1.9.0 to v1.9.1 in Docker on a Synology NAS, the container crashes as soon as any query is submitted. - Docker image / tag: v1.9.1 - Platform: Synology NAS (CPU without AVX2 support) - Previous working version: v1.9.0 - Observed behavior: Container stops/crashes immediately after submitting a query. - Expected behavior: Container should process queries normally, as in v1.9.0. - Logs: No error messages appear in container logs. Steps to reproduce: 1. Pull or build Docker image for AnythingLLM v1.9.1. 2. Run container on Synology NAS. 3. Submit any query to the LLM. 4. Observe that the container crashes immediately, with no logs indicating the cause. 5. Downgrading to v1.9.0 restores normal functionality. Additional info / suspected cause: - Internal Ollama binaries may require CPU instructions (e.g., **AVX2**) that are not available on some Synology NAS models. - We are using **Weaviate** as the database backend. There were also changes in v1.9.1 related to scoring (see changelog), which might contribute to the crash. - No `illegal instruction` message or log is displayed inside the container. Request: Please investigate the crash in the v1.9.1 Docker image on Synology NAS systems. Note that we are using Weaviate as the database backend, and there were changes related to scoring in this version that might be relevant. The internal Ollama binaries may also use CPU instructions such as AVX2, which could contribute to the issue. A solution or workaround for NAS environments would be appreciated.
yindo added the Dockerneeds info / can't replicateinvestigating labels 2026-02-22 18:32:13 -05:00
yindo closed this issue 2026-02-22 18:32:13 -05:00
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Dec 11, 2025):

Please investigate the crash in the v1.9.1 Docker image on Synology NAS systems.

We have no way of replicating this environment. That being said not having AVX2 has been known to cause issues but that was entirely if the system attempted to load LanceDB in any way, shape, or form.

However, the core of this issue likely lies here since we pre-emptively load LanceDB as the failover DB. However it not showing the container crash command is different from how it previously manifested.

The Docker image does not have an internal Ollama - so it cannot be that. Unless you are using the Desktop app in which this is an entirely different issue

@timothycarambat commented on GitHub (Dec 11, 2025): > Please investigate the crash in the v1.9.1 Docker image on Synology NAS systems. We have no way of replicating this environment. That being said not having AVX2 has [been known to cause issues](https://github.com/Mintplex-Labs/anything-llm/issues/1331#issuecomment-2122238892) but that was entirely if the system attempted to load LanceDB in any way, shape, or form. However, the core of this issue [likely lies here](https://github.com/Mintplex-Labs/anything-llm/blob/baab837b5886190f951e9958a049bf0ca6948573/server/utils/helpers/index.js#L85) since we pre-emptively load LanceDB as the failover DB. However it not showing the container crash command is different from how it previously manifested. The Docker image does not have an internal Ollama - so it cannot be that. Unless you are using the Desktop app in which this is an entirely different issue
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Dec 11, 2025):

Attempting to reproduce:

  • Create c2.large instance which has Intel Xeon E5-2680 v2 (Ivy Bridge)
  • Confirm no avx2 - only has avx support
$ lscpu | grep avx

fpu vme de pse ... avx f16c rdrand hypervisor ...
  • Launch docker container
export STORAGE_LOCATION=$HOME/anythingllm && \
mkdir -p $STORAGE_LOCATION && \
touch "$STORAGE_LOCATION/.env" && \
docker run -d -p 3001:3001 \
--cap-add SYS_ADMIN \
-v ${STORAGE_LOCATION}:/app/server/storage \
-v ${STORAGE_LOCATION}/.env:/app/server/.env \
-e STORAGE_DIR="/app/server/storage" \
mintplexlabs/anythingllm
  • Complete onboarding, using CPU embedder + default LanceDB vector DB.
  • Are able to embed and query documents (using OpenAI as LLM)
  • Create Weaviate cluster on Weaviate cloud. Confirm change
  • Re-embed document again. Confirm that the collection in Weaviate is created.
  • Resend same prompt, get citation response.

Not sure what else there is I can do to reproduce this. I am able to use weaviate as well as even embed and use lanceDB with AVX support.

Unless this instance somehow does have AVX2 in which case this reproduction does not help

@timothycarambat commented on GitHub (Dec 11, 2025): Attempting to reproduce: - Create c2.large instance which has Intel Xeon E5-2680 v2 (Ivy Bridge) - Confirm **no avx2** - only has avx support ```shell $ lscpu | grep avx fpu vme de pse ... avx f16c rdrand hypervisor ... ``` - Launch docker container ```shell export STORAGE_LOCATION=$HOME/anythingllm && \ mkdir -p $STORAGE_LOCATION && \ touch "$STORAGE_LOCATION/.env" && \ docker run -d -p 3001:3001 \ --cap-add SYS_ADMIN \ -v ${STORAGE_LOCATION}:/app/server/storage \ -v ${STORAGE_LOCATION}/.env:/app/server/.env \ -e STORAGE_DIR="/app/server/storage" \ mintplexlabs/anythingllm ``` - Complete onboarding, using CPU embedder + default LanceDB vector DB. - Are able to embed and query documents (using OpenAI as LLM) - Create Weaviate cluster on Weaviate cloud. Confirm change - Re-embed document again. Confirm that the collection in Weaviate is created. - Resend same prompt, get citation response. Not sure what else there is I can do to reproduce this. I am able to use weaviate as well as even embed and use lanceDB with AVX support. Unless this instance somehow does have AVX2 in which case this reproduction does not help
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Dec 11, 2025):

Merged https://github.com/Mintplex-Labs/anything-llm/pull/4764 - which will only load lancedb and it's possibly offending imports on non-AVX2 systems unless explicitly asked or on failover

When build https://github.com/Mintplex-Labs/anything-llm/actions/runs/20142341319/job/57813183173 completes, try to pull latest and see if your issue still persists

@timothycarambat commented on GitHub (Dec 11, 2025): Merged https://github.com/Mintplex-Labs/anything-llm/pull/4764 - which will only load `lancedb` and it's possibly offending imports on non-AVX2 systems unless explicitly asked _or on failover_ When build https://github.com/Mintplex-Labs/anything-llm/actions/runs/20142341319/job/57813183173 completes, try to pull `latest` and see if your issue still persists
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@Sarmingsteiner commented on GitHub (Dec 12, 2025):

Thanks for taking a look at the bug report so quickly! 🙏
In the meantime, until the change is fully pushed, I’ll manually remove the preloading of LanceDB to avoid any issues on non-AVX(2) systems.

Once build #20142341319
completes, I’ll pull the latest and check if the issue still persists.

@Sarmingsteiner commented on GitHub (Dec 12, 2025): Thanks for taking a look at the bug report so quickly! 🙏 In the meantime, until the change is fully pushed, I’ll manually remove the preloading of LanceDB to avoid any issues on non-AVX(2) systems. Once build [#20142341319](https://github.com/Mintplex-Labs/anything-llm/actions/runs/20142341319/job/57813183173) completes, I’ll pull the latest and check if the issue still persists.
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Dec 12, 2025):

@Sarmingsteiner That build errored due to some random HTTP issue. That being said, we made commits since that merge and master has since built successfully, so latest currently has the change you need right now.

@timothycarambat commented on GitHub (Dec 12, 2025): @Sarmingsteiner That build errored due to some random HTTP issue. That being said, we made commits since that merge and master has since built successfully, so `latest` currently has the change you need right now.
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@Sarmingsteiner commented on GitHub (Dec 17, 2025):

@timothycarambat Thank you very much for the update and the clarification.
I’ve pulled the latest version and can confirm that everything is now working as expected.
Much appreciated – thanks for the quick follow-up and fix!

@Sarmingsteiner commented on GitHub (Dec 17, 2025): @timothycarambat Thank you very much for the update and the clarification. I’ve pulled the latest version and can confirm that everything is now working as expected. Much appreciated – thanks for the quick follow-up and fix!
yindo commented 2026-02-22 18:32:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Dec 18, 2025):

@Sarmingsteiner thanks for discovering that! There are a surprising amount of non-AVX2 CPUs still out there in the world apparently, so no reason they shouldnt be able to use AnythingLLM

@timothycarambat commented on GitHub (Dec 18, 2025): @Sarmingsteiner thanks for discovering that! There are a surprising amount of non-AVX2 CPUs still out there in the world apparently, so no reason they shouldnt be able to use AnythingLLM
yindo changed title from Docker v1.9.1 crashes on Synology NAS while v1.9.0 works (Weaviate) to [GH-ISSUE #4763] Docker v1.9.1 crashes on Synology NAS while v1.9.0 works (Weaviate) 2026-06-05 14:49:46 -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 investigating needs info / can't replicate
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#3005
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?