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 #4657] [BUG]: External Prisma.sh Service Internal Server Error #2953

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

Originally created by @merihilgor on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4657

How are you running AnythingLLM?

Docker (local)

What happened?

External Prisma.sh Service Internal Server Error
Overview:
The anything-llm pod in your GKE autopilot cluster is repeatedly crashing and restarting due to an "Error: Failed to fetch the engine file at https://binaries.prisma.sh/... - 500 Internal Server Error". This 500 Internal Server Error indicates a problem on the server-side of binaries.prisma.sh, meaning the request from your GKE pod successfully reached the Prisma service, but the Prisma service itself encountered an internal error while trying to fulfill the request.

I investigated in GCP environment and found no network policies or firewall rules blocking egress traffic from your GKE cluster to binaries.prisma.sh. Specifically:

I ran kubectl get networkpolicy -n anything and found no network policies defined in the anything namespace.
I ran gcloud compute firewall-rules list and found an egress firewall rule named allow-all-out with priority 1000, which permits all outbound traffic from your GCP network to 0.0.0.0/0.
I ran gcloud container clusters describe gcp-ai-cluster --region europe-west4 and found that the cluster's networkPolicyConfig is disabled.
The anything-llm container within the anything-llm-58b447458c-89rnq pod is repeatedly failing and being restarted by Kubernetes, as evidenced by the 'CrashLoopBackOff' status and increasing restart count. The error count for pod anything-llm-58b447458c-89rnq was anomalously high, increasing by 30 between 2025-11-18 13:04 UTC and 2025-11-18 14:04 UTC, which aligns with the reported 500 Internal Server Error.

pod securityContext config:

      securityContext:
        readOnlyRootFilesystem: true
        privileged: false
        runAsUser: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
          - ALL
        seLinuxOptions: {}
        seccompProfile:
          type: RuntimeDefault

Are there known steps to reproduce?

No response

Originally created by @merihilgor on GitHub (Nov 18, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4657 ### How are you running AnythingLLM? Docker (local) ### What happened? External Prisma.sh Service Internal Server Error Overview: The anything-llm pod in your GKE autopilot cluster is repeatedly crashing and restarting due to an "Error: Failed to fetch the engine file at https://binaries.prisma.sh/... - 500 Internal Server Error". This 500 Internal Server Error indicates a problem on the server-side of binaries.prisma.sh, meaning the request from your GKE pod successfully reached the Prisma service, but the Prisma service itself encountered an internal error while trying to fulfill the request. I investigated in GCP environment and found no network policies or firewall rules blocking egress traffic from your GKE cluster to binaries.prisma.sh. Specifically: I ran kubectl get networkpolicy -n anything and found no network policies defined in the anything namespace. I ran gcloud compute firewall-rules list and found an egress firewall rule named allow-all-out with priority 1000, which permits all outbound traffic from your GCP network to 0.0.0.0/0. I ran gcloud container clusters describe gcp-ai-cluster --region europe-west4 and found that the cluster's networkPolicyConfig is disabled. The anything-llm container within the anything-llm-58b447458c-89rnq pod is repeatedly failing and being restarted by Kubernetes, as evidenced by the 'CrashLoopBackOff' status and increasing restart count. The error count for pod anything-llm-58b447458c-89rnq was anomalously high, increasing by 30 between 2025-11-18 13:04 UTC and 2025-11-18 14:04 UTC, which aligns with the reported 500 Internal Server Error. pod securityContext config: securityContext: readOnlyRootFilesystem: true privileged: false runAsUser: 1000 runAsGroup: 1000 runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: - ALL seLinuxOptions: {} seccompProfile: type: RuntimeDefault ### Are there known steps to reproduce? _No response_
yindo added the possible bug label 2026-02-22 18:32:00 -05:00
yindo closed this issue 2026-02-22 18:32:00 -05:00
yindo commented 2026-02-22 18:32:00 -05:00
Author
Owner
Copy Link
Copy Source

@shatfield4 commented on GitHub (Nov 18, 2025):

So it looks like the issue here is that you have readOnlyRootFilesystem: true in your config. On startup of AnythingLLM Prisma needs to download the db engine binary and the readOnlyRootFilesystem option is causing Prisma to not have a temp directory for it to download this binary.

I suggest that you add these to your config and this should provide the correct temp volumes to allow Prisma to download and store the binaries.

- name: tmp-volume
  mountPath: /tmp
- name: node-modules-cache
  mountPath: /app/server/node_modules/.prisma

volumes:
- name: tmp-volume
  emptyDir: {}
- name: node-modules-cache
  emptyDir: {}
@shatfield4 commented on GitHub (Nov 18, 2025): So it looks like the issue here is that you have `readOnlyRootFilesystem: true` in your config. On startup of AnythingLLM Prisma needs to download the db engine binary and the `readOnlyRootFilesystem` option is causing Prisma to not have a temp directory for it to download this binary. I suggest that you add these to your config and this should provide the correct temp volumes to allow Prisma to download and store the binaries. ```volumeMounts: - name: tmp-volume mountPath: /tmp - name: node-modules-cache mountPath: /app/server/node_modules/.prisma volumes: - name: tmp-volume emptyDir: {} - name: node-modules-cache emptyDir: {}
yindo commented 2026-02-22 18:32:00 -05:00
Author
Owner
Copy Link
Copy Source

@merihilgor commented on GitHub (Nov 19, 2025):

I used :
this helm chart

https://github.com/la-cc/anything-llm-helm-chart/tree/main/charts/anything-llm

with values :

config:
PRISMA_ENGINES_CHECKSUM_IGNORE_MISSING: "1"
PRISMA_CLIENT_ENGINE_TYPE: "binary"
STORAGE_DIR: "/app/server/storage"

volumes:
- name: server-storage
mountPath: /app/server/storage
- name: node-modules-cache
mountPath: /app/server/node_modules/.prisma
- name: npm-cache
mountPath: /app/.npm/
- name: tmd-dir
mountPath: /tmp

and in the pod yaml I can see :

volumeMounts:
- mountPath: /app/server/storage
  name: server-storage
- mountPath: /app/server/node_modules/.prisma
  name: node-modules-cache
- mountPath: /app/.npm/
  name: npm-cache
- mountPath: /tmp
  name: tmd-dir

volumes:

  • name: server-storage
    persistentVolumeClaim:
    claimName: server-storage
  • name: node-modules-cache
    persistentVolumeClaim:
    claimName: node-modules-cache
  • name: npm-cache
    persistentVolumeClaim:
    claimName: npm-cache
  • name: tmd-dir
    persistentVolumeClaim:
    claimName: tmd-dir

and. latest logs :

Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Error:
ENOENT: no such file or directory, copyfile '/app/server/node_modules/prisma/query-engine-debian-openssl-3.0.x' -> '/app/server/node_modules/.prisma/client/query-engine-debian-openssl-3.0.x'

@merihilgor commented on GitHub (Nov 19, 2025): I used : this helm chart https://github.com/la-cc/anything-llm-helm-chart/tree/main/charts/anything-llm with values : config: PRISMA_ENGINES_CHECKSUM_IGNORE_MISSING: "1" PRISMA_CLIENT_ENGINE_TYPE: "binary" STORAGE_DIR: "/app/server/storage" volumes: - name: server-storage mountPath: /app/server/storage - name: node-modules-cache mountPath: /app/server/node_modules/.prisma - name: npm-cache mountPath: /app/.npm/ - name: tmd-dir mountPath: /tmp and in the pod yaml I can see : volumeMounts: - mountPath: /app/server/storage name: server-storage - mountPath: /app/server/node_modules/.prisma name: node-modules-cache - mountPath: /app/.npm/ name: npm-cache - mountPath: /tmp name: tmd-dir volumes: - name: server-storage persistentVolumeClaim: claimName: server-storage - name: node-modules-cache persistentVolumeClaim: claimName: node-modules-cache - name: npm-cache persistentVolumeClaim: claimName: npm-cache - name: tmd-dir persistentVolumeClaim: claimName: tmd-dir and. latest logs : Environment variables loaded from .env Prisma schema loaded from prisma/schema.prisma Error: ENOENT: no such file or directory, copyfile '/app/server/node_modules/prisma/query-engine-debian-openssl-3.0.x' -> '/app/server/node_modules/.prisma/client/query-engine-debian-openssl-3.0.x'
yindo changed title from [BUG]: External Prisma.sh Service Internal Server Error to [GH-ISSUE #4657] [BUG]: External Prisma.sh Service Internal Server Error 2026-06-05 14:49:30 -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 possible bug
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#2953
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?