[GH-ISSUE #1077] [BUG]: Linux AppImage - Error on update! (solution in comments) #665

Closed
opened 2026-02-22 18:20:42 -05:00 by yindo · 18 comments
Owner

Originally created by @renegadephysicist on GitHub (Apr 10, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/1077

Originally assigned to: @timothycarambat on GitHub.

How are you running AnythingLLM?

AnythingLLM desktop app

What happened?

System: Linux Ubuntu using AppImage
AythingLLM Version: 1.4.4
When attempting to change the "Workspace LLM Provider" in "Chat Settings" I get the error below.
Seems to be the same error for both anthropic and openai. It's possible to change the LLM at the instance level by changing "LLM Provider" just not at Workspace level

Error:
Invalid `prisma.workspaces.update()` invocation:

{
where: {
id: 3
},
data: {
chatProvider: "anthropic",
~~~~~~~~~~~~
chatModel: "claude-instant-1.2",
chatMode: "chat",
openAiHistory: 20,
openAiPrompt: "Given the following conversation, relevant context, and a follow up question, reply with an answer to the current question the user is asking. Return only your response to the question given the above information following the users instructions as needed.",
openAiTemp: 0.7,
? name?: String | StringFieldUpdateOperationsInput,
? slug?: String | StringFieldUpdateOperationsInput,
? vectorTag?: String | NullableStringFieldUpdateOperationsInput | Null,
? createdAt?: DateTime | DateTimeFieldUpdateOperationsInput,
? lastUpdatedAt?: DateTime | DateTimeFieldUpdateOperationsInput,
? similarityThreshold?: Float | NullableFloatFieldUpdateOperationsInput | Null,
? topN?: Int | NullableIntFieldUpdateOperationsInput | Null,
? workspace_users?: workspace_usersUpdateManyWithoutWorkspacesNestedInput,
? documents?: workspace_documentsUpdateManyWithoutWorkspaceNestedInput,
? workspace_suggested_messages?: workspace_suggested_messagesUpdateManyWithoutWorkspaceNestedInput,
? embed_configs?: embed_configsUpdateManyWithoutWorkspaceNestedInput,
? threads?: workspace_threadsUpdateManyWithoutWorkspaceNestedInput
}
}

Unknown argument `chatProvider`. Available options are listed in green.

I get an error when starting the AppImage:
EROFS: read-only file system, unlink '/tmp/.mount_Anythib4quPA/resources/backend/node_modules/.prisma/client/index.js'
Not sure if this is related or not.

Are there known steps to reproduce?

After clicking "Update Workspace" the following error should appear if a value different from "System Default" is selected for "Workspace LLM Provider"
image

Originally created by @renegadephysicist on GitHub (Apr 10, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/1077 Originally assigned to: @timothycarambat on GitHub. ### How are you running AnythingLLM? AnythingLLM desktop app ### What happened? System: Linux Ubuntu using AppImage AythingLLM Version: 1.4.4 When attempting to change the "Workspace LLM Provider" in "Chat Settings" I get the error below. Seems to be the same error for both anthropic and openai. It's possible to change the LLM at the instance level by changing "LLM Provider" just not at Workspace level ``` Error: Invalid `prisma.workspaces.update()` invocation: { where: { id: 3 }, data: { chatProvider: "anthropic", ~~~~~~~~~~~~ chatModel: "claude-instant-1.2", chatMode: "chat", openAiHistory: 20, openAiPrompt: "Given the following conversation, relevant context, and a follow up question, reply with an answer to the current question the user is asking. Return only your response to the question given the above information following the users instructions as needed.", openAiTemp: 0.7, ? name?: String | StringFieldUpdateOperationsInput, ? slug?: String | StringFieldUpdateOperationsInput, ? vectorTag?: String | NullableStringFieldUpdateOperationsInput | Null, ? createdAt?: DateTime | DateTimeFieldUpdateOperationsInput, ? lastUpdatedAt?: DateTime | DateTimeFieldUpdateOperationsInput, ? similarityThreshold?: Float | NullableFloatFieldUpdateOperationsInput | Null, ? topN?: Int | NullableIntFieldUpdateOperationsInput | Null, ? workspace_users?: workspace_usersUpdateManyWithoutWorkspacesNestedInput, ? documents?: workspace_documentsUpdateManyWithoutWorkspaceNestedInput, ? workspace_suggested_messages?: workspace_suggested_messagesUpdateManyWithoutWorkspaceNestedInput, ? embed_configs?: embed_configsUpdateManyWithoutWorkspaceNestedInput, ? threads?: workspace_threadsUpdateManyWithoutWorkspaceNestedInput } } Unknown argument `chatProvider`. Available options are listed in green. ``` I get an error when starting the AppImage: EROFS: read-only file system, unlink '/tmp/.mount_Anythib4quPA/resources/backend/node_modules/.prisma/client/index.js' Not sure if this is related or not. ### Are there known steps to reproduce? After clicking "Update Workspace" the following error should appear if a value different from "System Default" is selected for "Workspace LLM Provider" ![image](https://github.com/Mintplex-Labs/anything-llm/assets/32599092/bdda9582-4dca-4fae-8f54-fb57f96492c1)
yindo added the bugDesktopOS: Linux labels 2026-02-22 18:20:42 -05:00
yindo closed this issue 2026-02-22 18:20:42 -05:00
Author
Owner

@timothycarambat commented on GitHub (Apr 10, 2024):

Fully close the application and re-open it so that the migrations can run and you can use that feature as it requires a migration. If the application was updated while running - the migrations will not run.

@timothycarambat commented on GitHub (Apr 10, 2024): Fully close the application and re-open it so that the migrations can run and you can use that feature as it requires a migration. If the application was updated while running - the migrations will not run.
Author
Owner

@renegadephysicist commented on GitHub (Apr 10, 2024):

I've tried opening and closing the application several times yet the issue persists.
I only downloaded the AppImage today (version 1.4.4)

@renegadephysicist commented on GitHub (Apr 10, 2024): I've tried opening and closing the application several times yet the issue persists. I only downloaded the AppImage today (version 1.4.4)
Author
Owner

@timothycarambat commented on GitHub (Apr 10, 2024):

Just modified the Linux version to help debug this issue. Can you see if this error reproduces with this app image?
https://s3.us-west-1.amazonaws.com/public.useanything.com/latest/AnythingLLMDesktop.AppImage

Let's see if this boots on your distro + allows you to update that workspace config. Definitely prisma related, but local to on the AppImage

@timothycarambat commented on GitHub (Apr 10, 2024): Just modified the Linux version to help debug this issue. Can you see if this error reproduces with this app image? https://s3.us-west-1.amazonaws.com/public.useanything.com/latest/AnythingLLMDesktop.AppImage Let's see if this boots on your distro + allows you to update that workspace config. Definitely prisma related, but local to on the AppImage
Author
Owner

@renegadephysicist commented on GitHub (Apr 10, 2024):

I tried to run this appImage but I ran into the problem described here (https://github.com/Mintplex-Labs/anything-llm/issues/898). I tried to fix it but got the error below. Running Ubuntu 22.04.4, I didn't have this issue with the image I downloaded from the website.
Screenshot from 2024-04-10 22-17-47
Screenshot from 2024-04-10 22-13-42

@renegadephysicist commented on GitHub (Apr 10, 2024): I tried to run this appImage but I ran into the problem described here (https://github.com/Mintplex-Labs/anything-llm/issues/898). I tried to fix it but got the error below. Running Ubuntu 22.04.4, I didn't have this issue with the image I downloaded from the website. ![Screenshot from 2024-04-10 22-17-47](https://github.com/Mintplex-Labs/anything-llm/assets/32599092/734680d5-1d71-43e3-af63-c9092c332ba6) ![Screenshot from 2024-04-10 22-13-42](https://github.com/Mintplex-Labs/anything-llm/assets/32599092/b98b74a3-6f16-492f-9c57-e5967bde8d03)
Author
Owner

@timothycarambat commented on GitHub (Apr 10, 2024):

Okay, that was expected to be seen honestly. That was the previous issue. Just reverted to the prior image which was causing the original issue.

While the provider per workspace functionality is not available in 1.4.2, are you able to even set the model per workspace in this version (1.4.2)
https://s3.us-west-1.amazonaws.com/public.useanything.com/legacy/1.4.2/AnythingLLMDesktop.AppImage

@timothycarambat commented on GitHub (Apr 10, 2024): Okay, that was expected to be seen honestly. That was the previous issue. Just reverted to the prior image which was causing the original issue. While the provider per workspace functionality is not available in 1.4.2, are you able to even set the model per workspace in this version (1.4.2) https://s3.us-west-1.amazonaws.com/public.useanything.com/legacy/1.4.2/AnythingLLMDesktop.AppImage
Author
Owner

@timothycarambat commented on GitHub (Apr 10, 2024):

It looks like here, for some reason, the Prisma client is failing to generate after migration, this blocks the client from being able to use any updated schema and then fails to update workspaces who use the new fields from the updated schema

@timothycarambat commented on GitHub (Apr 10, 2024): It looks like here, for some reason, the Prisma client is failing to generate after migration, this blocks the client from being able to use any updated schema and then fails to update workspaces who use the new fields from the updated schema
Author
Owner

@renegadephysicist commented on GitHub (Apr 10, 2024):

based on what you said

It looks like here, for some reason, the Prisma client is failing to generate after migration, this blocks the client from being able to use any updated schema and then fails to update workspaces who use the new fields from the updated schema

I tried to run the same process as described in https://github.com/Mintplex-Labs/anything-llm/issues/898 with the AppImage I downloaded earlier from the website

cd to where ur AnythingLLMDesktop.AppImage is
run ./AnythingLLMDesktop.AppImage --appimage-extract
cd squashfs-root/resources/backend/
node node_modules/prisma generate (will need node installed)
cd ../../
./AppRun

This worked, used node 20.12.2... I'm not familiar with javascript packaging, prisma etc. So I'm not sure how to fix this, maybe a CI step to create the AppImage?

@renegadephysicist commented on GitHub (Apr 10, 2024): based on what you said > It looks like here, for some reason, the Prisma client is failing to generate after migration, this blocks the client from being able to use any updated schema and then fails to update workspaces who use the new fields from the updated schema I tried to run the same process as described in https://github.com/Mintplex-Labs/anything-llm/issues/898 with the AppImage I downloaded earlier from the website > > cd to where ur AnythingLLMDesktop.AppImage is > run ./AnythingLLMDesktop.AppImage --appimage-extract > cd squashfs-root/resources/backend/ > node node_modules/prisma generate (will need node installed) > cd ../../ > ./AppRun This worked, used node 20.12.2... I'm not familiar with javascript packaging, prisma etc. So I'm not sure how to fix this, maybe a CI step to create the AppImage?
Author
Owner

@timothycarambat commented on GitHub (Apr 10, 2024):

That likely could be the fix. Asking people to unzip the AppImage is a bit crazy so I wanted to hold off on recommending that, but it looks like patching the app post-install seems to be the most continuously reliable solution. :/

The main issue is that whatever CI we use to build the image we will have the same issue since Openssl binary native likely wont match what is used on the user OS and will instead come with whatever the CI was using.

Thinking we might just make the app a shell script at this point that can make the appimage on-machine to avoid all of these compatibility quirks. Docker just works for Linux on all distro but nobody wants to use that solution, which is why AppImage even exists

@timothycarambat commented on GitHub (Apr 10, 2024): That likely could be the fix. Asking people to unzip the AppImage is a bit crazy so I wanted to hold off on recommending that, but it looks like patching the app post-install seems to be the most continuously reliable solution. :/ The main issue is that whatever CI we use to build the image we will have the same issue since `Openssl` binary native likely wont match what is used on the user OS and will instead come with whatever the CI was using. Thinking we might just make the app a shell script at this point that can make the appimage on-machine to avoid all of these compatibility quirks. Docker just works for Linux on all distro but nobody wants to use that solution, which is why AppImage even exists
Author
Owner

@renegadephysicist commented on GitHub (Apr 10, 2024):

I asked ChatGPT lol and it came back with the following:

Prisma provides a feature to generate a static binary that includes all its dependencies. This can help ensure that the Prisma Client does not depend on the system's OpenSSL version. To generate a static binary for Prisma, you can configure your schema.prisma file with an appropriate binaryTargets option:

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-1.1.x"]
}

This configuration tells Prisma to generate a client that is compatible with both the native platform it's generated on and specifically for debian-openssl-1.1.x. Adjust the binaryTargets as needed for your deployment target.

I'm not sure how you fixed this previously..
Here is the relevant prisma documentation, they mention this exact issue with the fix above:
https://www.prisma.io/docs/orm/prisma-schema/overview/generators

It looks like debian-openssl-1.1.x will target ubuntu up to 21.04 and debian-openssl-3.0.x for any version above that.
https://www.prisma.io/docs/orm/reference/prisma-schema-reference#linux-ubuntu-x86_64

Adding this to the prisma.schema generator client might do it:

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-1.1.x",  "debian-openssl-3.0.x"]
}
@renegadephysicist commented on GitHub (Apr 10, 2024): I asked ChatGPT lol and it came back with the following: > Prisma provides a feature to generate a static binary that includes all its dependencies. This can help ensure that the Prisma Client does not depend on the system's OpenSSL version. To generate a static binary for Prisma, you can configure your schema.prisma file with an appropriate binaryTargets option: ``` generator client { provider = "prisma-client-js" binaryTargets = ["native", "debian-openssl-1.1.x"] } ``` > This configuration tells Prisma to generate a client that is compatible with both the native platform it's generated on and specifically for debian-openssl-1.1.x. Adjust the binaryTargets as needed for your deployment target. I'm not sure how you fixed this previously.. Here is the relevant prisma documentation, they mention this exact issue with the fix above: https://www.prisma.io/docs/orm/prisma-schema/overview/generators It looks like `debian-openssl-1.1.x` will target ubuntu up to 21.04 and `debian-openssl-3.0.x` for any version above that. https://www.prisma.io/docs/orm/reference/prisma-schema-reference#linux-ubuntu-x86_64 Adding this to the [prisma.schema](https://github.com/Mintplex-Labs/anything-llm/blob/master/server/prisma/schema.prisma#L2) generator client might do it: ``` generator client { provider = "prisma-client-js" binaryTargets = ["native", "debian-openssl-1.1.x", "debian-openssl-3.0.x"] } ```
Author
Owner

@renegadephysicist commented on GitHub (Apr 10, 2024):

I had a look at the package.json file that is used to create the electron app to see if I could figure out why the prisma schema is not being generated and I had to manually do it above.

I'm not familiar with prisma but it might be idea to put the generate command after the migrate command in the package.json file e.g.:

"prisma:setup": "yarn prisma:migrate && yarn prisma:generate && yarn prisma:seed",

@renegadephysicist commented on GitHub (Apr 10, 2024): I had a look at the `package.json` file that is used to create the electron app to see if I could figure out why the prisma schema is not being generated and I had to manually do it above. I'm not familiar with prisma but it might be idea to put the generate command after the migrate command in the [package.json](https://github.com/Mintplex-Labs/anything-llm/blob/master/package.json#L22) file e.g.: `"prisma:setup": "yarn prisma:migrate && yarn prisma:generate && yarn prisma:seed",`
Author
Owner

@timothycarambat commented on GitHub (Apr 14, 2024):

@renegadephysicist you may have just solved a big headache. Will see if we can wrap a new Linux version and test to see if this resolves everyone's issues. If this does, would be happy to mark you as a contributor

Related: https://github.com/prisma/prisma/issues/8112

@timothycarambat commented on GitHub (Apr 14, 2024): @renegadephysicist you may have just solved a big headache. Will see if we can wrap a new Linux version and test to see if this resolves everyone's issues. If this does, would be happy to mark you as a contributor Related: https://github.com/prisma/prisma/issues/8112
Author
Owner

@naveenjujaray commented on GitHub (Apr 17, 2024):

I concur that Prisma is the root cause of the problem, yet I find myself unable to rectify the situation.
you may find this helpful: https://github.com/prisma/prisma/issues/5340
Screenshot 2024-04-18 031825

@naveenjujaray commented on GitHub (Apr 17, 2024): I concur that Prisma is the root cause of the problem, yet I find myself unable to rectify the situation. you may find this helpful: https://github.com/prisma/prisma/issues/5340 <img width="960" alt="Screenshot 2024-04-18 031825" src="https://github.com/Mintplex-Labs/anything-llm/assets/44742201/7581000f-dccb-48bb-bb9e-73ac72767983">
Author
Owner

@timothycarambat commented on GitHub (Apr 17, 2024):

For now. The solution to simply this for all distros is the run the AppImage in the following way:

./AnythingLLMDesktop.AppImage --appimage-extract && \
cd squashfs-root && \
./AppRun

This will ensure on run that the prisma binaries for your system are installed automatically. Since AppImages mount to /tmp/ and this in not writeable this is the current solution for Linux while we work on a workaround or comprehensive solution..

@timothycarambat commented on GitHub (Apr 17, 2024): For now. The solution to simply this for all distros is the run the AppImage in the following way: ```bash ./AnythingLLMDesktop.AppImage --appimage-extract && \ cd squashfs-root && \ ./AppRun ``` This will ensure on run that the `prisma` binaries for your system are installed automatically. Since AppImages mount to /tmp/ and this in not writeable this is the current solution for Linux while we work on a workaround or comprehensive solution..
Author
Owner

@wpq3142 commented on GitHub (Apr 21, 2024):

目前。对于所有发行版本来说,简单的解决方案是按以下方式运行AppImage:

./AnythingLLMDesktop.AppImage --appimage-extract && \
cd squashfs-root && \
./AppRun

这将保证在运行时prisma自动安装系统的二进制文件。由于AppImages挂载到/tmp/并且是不可写的,因此这是Linux的当前解决方案,同时我们正在研究解决方法或综合解决方案。

原来如此!!

@wpq3142 commented on GitHub (Apr 21, 2024): > 目前。对于所有发行版本来说,简单的解决方案是按以下方式运行AppImage: > > ```shell > ./AnythingLLMDesktop.AppImage --appimage-extract && \ > cd squashfs-root && \ > ./AppRun > ``` > > 这将保证在运行时`prisma`自动安装系统的二进制文件。由于AppImages挂载到/tmp/并且是不可写的,因此这是Linux的当前解决方案,同时我们正在研究解决方法或综合解决方案。 原来如此!!
Author
Owner

@fengyunzaidushi commented on GitHub (Apr 28, 2024):

For now. The solution to simply this for all distros is the run the AppImage in the following way:

./AnythingLLMDesktop.AppImage --appimage-extract && \
cd squashfs-root && \
./AppRun

This will ensure on run that the prisma binaries for your system are installed automatically. Since AppImages mount to /tmp/ and this in not writeable this is the current solution for Linux while we work on a workaround or comprehensive solution..

it works,thank you very much!

@fengyunzaidushi commented on GitHub (Apr 28, 2024): > For now. The solution to simply this for all distros is the run the AppImage in the following way: > > ```shell > ./AnythingLLMDesktop.AppImage --appimage-extract && \ > cd squashfs-root && \ > ./AppRun > ``` > > This will ensure on run that the `prisma` binaries for your system are installed automatically. Since AppImages mount to /tmp/ and this in not writeable this is the current solution for Linux while we work on a workaround or comprehensive solution.. it works,thank you very much!
Author
Owner

@la2yyu commented on GitHub (Apr 29, 2024):

my system is windows, is there any sulution for this issue?

@la2yyu commented on GitHub (Apr 29, 2024): my system is windows, is there any sulution for this issue?
Author
Owner

@13829386012 commented on GitHub (Apr 29, 2024):

我的系統是Windows,這個問題有什麼解決辦法嗎?

Me too,Encountered the same problem in windows system

@13829386012 commented on GitHub (Apr 29, 2024): > 我的系統是Windows,這個問題有什麼解決辦法嗎? Me too,Encountered the same problem in windows system
Author
Owner

@Yan2603 commented on GitHub (May 8, 2024):

我的系統是Windows,這個問題有什麼解決辦法嗎?

Me too,Encountered the same problem in windows system

我也遇到了,解决了吗

@Yan2603 commented on GitHub (May 8, 2024): > > 我的系統是Windows,這個問題有什麼解決辦法嗎? > > Me too,Encountered the same problem in windows system 我也遇到了,解决了吗
yindo changed title from [BUG]: Linux AppImage - Error on update! (solution in comments) to [GH-ISSUE #1077] [BUG]: Linux AppImage - Error on update! (solution in comments) 2026-06-05 14:36:33 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#665