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

[GH-ISSUE #947] [BUG]: Crash when navigating to localhost. #574

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

Originally created by @AndreasSlette on GitHub (Mar 21, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/947

How are you running AnythingLLM?

Docker (local)

What happened?

Container starts fine, but when navigating to localhost:3001 it throws an error and the container stops.

Log:
2024-03-21 14:21:38 /app/server/node_modules/bcrypt/bcrypt.js:166
2024-03-21 14:21:38 throw new Error('data and hash arguments required');
2024-03-21 14:21:38 ^
2024-03-21 14:21:38
2024-03-21 14:21:38 Error: data and hash arguments required
2024-03-21 14:21:38 at Object.compareSync (/app/server/node_modules/bcrypt/bcrypt.js:166:15)
2024-03-21 14:21:38 at validatedRequest (/app/server/utils/middleware/validatedRequest.js:41:15)
2024-03-21 14:21:38
2024-03-21 14:21:38 Node.js v18.19.1

Are there known steps to reproduce?

Started the container and mounted local folder:

$env:STORAGE_LOCATION="$HOME\Documents\anythingllm"; If(!(Test-Path $env:STORAGE_LOCATION)) {New-Item $env:STORAGE_LOCATION -ItemType Directory};
If(!(Test-Path "$env:STORAGE_LOCATION.env")) {New-Item "$env:STORAGE_LOCATION.env" -ItemType File}; docker run -d -p 3001:3001
--cap-add SYS_ADMIN -v "$env:STORAGE_LOCATION:/app/server/storage" -v "$env:STORAGE_LOCATION\.env:/app/server/.env"
-e STORAGE_DIR="/app/server/storage" `
mintplexlabs/anythingllm;

Navigated to localhost:3001 in browser.

Originally created by @AndreasSlette on GitHub (Mar 21, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/947 ### How are you running AnythingLLM? Docker (local) ### What happened? Container starts fine, but when navigating to localhost:3001 it throws an error and the container stops. Log: 2024-03-21 14:21:38 /app/server/node_modules/bcrypt/bcrypt.js:166 2024-03-21 14:21:38 throw new Error('data and hash arguments required'); 2024-03-21 14:21:38 ^ 2024-03-21 14:21:38 2024-03-21 14:21:38 Error: data and hash arguments required 2024-03-21 14:21:38 at Object.compareSync (/app/server/node_modules/bcrypt/bcrypt.js:166:15) 2024-03-21 14:21:38 at validatedRequest (/app/server/utils/middleware/validatedRequest.js:41:15) 2024-03-21 14:21:38 2024-03-21 14:21:38 Node.js v18.19.1 ### Are there known steps to reproduce? ### Started the container and mounted local folder: > $env:STORAGE_LOCATION="$HOME\Documents\anythingllm"; ` > If(!(Test-Path $env:STORAGE_LOCATION)) {New-Item $env:STORAGE_LOCATION -ItemType Directory}; ` > If(!(Test-Path "$env:STORAGE_LOCATION\.env")) {New-Item "$env:STORAGE_LOCATION\.env" -ItemType File}; ` > docker run -d -p 3001:3001 ` > --cap-add SYS_ADMIN ` > -v "$env:STORAGE_LOCATION`:/app/server/storage" ` > -v "$env:STORAGE_LOCATION\.env:/app/server/.env" ` > -e STORAGE_DIR="/app/server/storage" ` > mintplexlabs/anythingllm; ### Navigated to localhost:3001 in browser.
yindo added the bugDocker labels 2026-02-22 18:20:15 -05:00
yindo closed this issue 2026-02-22 18:20:15 -05:00
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 21, 2024):

I think there may be a bug in that snippet. If you open $HOME\Documents\anythingllm in there should be a .env file in it. Does that file exist? That error seems to be related to it trying to match a hashed password (assumes the system is in password-protected mode) and it is null.

@timothycarambat commented on GitHub (Mar 21, 2024): I think there may be a bug in that snippet. If you open `$HOME\Documents\anythingllm` in there should be a `.env` file in it. Does that file exist? That error seems to be related to it trying to match a hashed password (assumes the system is in password-protected mode) and it is null.
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@AndreasSlette commented on GitHub (Mar 22, 2024):

Yes, there is an .env file. I followed the setup documented here: https://github.com/Mintplex-Labs/anything-llm/blob/master/docker/HOW_TO_USE_DOCKER.md.
The content of the .env file (replaced token values with 'xxxx'):

# Auto-dump ENV from system call on 12:08:28 GMT+0000 (Coordinated Universal Time)
LLM_PROVIDER='openai'
OPEN_AI_KEY='xxxxx'
OPEN_MODEL_PREF='gpt-3.5-turbo'
LMSTUDIO_BASE_PATH='http://host.docker.internal:1234/v1'
LMSTUDIO_MODEL_TOKEN_LIMIT='2048'
EMBEDDING_ENGINE='native'
VECTOR_DB='lancedb'
AUTH_TOKEN='xxxxx'
JWT_SECRET='xxxxx'
STORAGE_DIR='/app/server/storage'

All the fields have value. Any suggestions to changes i can try?

@AndreasSlette commented on GitHub (Mar 22, 2024): Yes, there is an .env file. I followed the setup documented here: https://github.com/Mintplex-Labs/anything-llm/blob/master/docker/HOW_TO_USE_DOCKER.md. The content of the .env file (replaced token values with 'xxxx'): > `#` Auto-dump ENV from system call on 12:08:28 GMT+0000 (Coordinated Universal Time) > LLM_PROVIDER='openai' > OPEN_AI_KEY='xxxxx' > OPEN_MODEL_PREF='gpt-3.5-turbo' > LMSTUDIO_BASE_PATH='http://host.docker.internal:1234/v1' > LMSTUDIO_MODEL_TOKEN_LIMIT='2048' > EMBEDDING_ENGINE='native' > VECTOR_DB='lancedb' > AUTH_TOKEN='xxxxx' > JWT_SECRET='xxxxx' > STORAGE_DIR='/app/server/storage' All the fields have value. Any suggestions to changes i can try?
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 22, 2024):

Related to this PR #956
To solve this in the meantime. Start the container and go to your interface in the browser. Open browser inspector -> Application -> LocalStorage -> localhost:3000 and remove all keys started with anythingllm_

TLDR; session expired and the app is crashing trying to compare a hash with null. That PR fixes that and will be merged Monday. I would merge today, but it has to do with auth so id rather be around and available when i merge it.

@timothycarambat commented on GitHub (Mar 22, 2024): Related to this PR #956 To solve this in the meantime. Start the container and go to your interface in the browser. Open browser inspector -> Application -> LocalStorage -> localhost:3000 and remove all keys started with `anythingllm_` TLDR; session expired and the app is crashing trying to compare a hash with `null`. That PR fixes that and will be merged Monday. I would merge today, but it has to do with auth so id rather be around and available when i merge it.
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 22, 2024):

If the above fix does not work, remove the AUTH_TOKEN and JWT_SECRET envs and boot and see if the crash persists

@timothycarambat commented on GitHub (Mar 22, 2024): If the above fix does not work, remove the `AUTH_TOKEN` and `JWT_SECRET` envs and boot and see if the crash persists
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@Sabst commented on GitHub (Aug 21, 2025):

Can you reopen? The problem is still there with 1.8.5
To reproduce, the steps are in my case:

  • Deploy and log into the app
  • Do not logout
  • Redeploy the application
  • Login from the same browser (and even the display of the home page) is not possible anymore and the server crashes (as above: "Error: data and hash arguments required")

To fix the problem, as said above, LocalStorage has to be cleaned-up

@Sabst commented on GitHub (Aug 21, 2025): Can you reopen? The problem is still there with 1.8.5 To reproduce, the steps are in my case: * Deploy and log into the app * Do not logout * Redeploy the application * Login from the same browser (and even the display of the home page) is not possible anymore and the server crashes (as above: "Error: data and hash arguments required") To fix the problem, as said above, LocalStorage has to be cleaned-up
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Aug 22, 2025):

This step:

Redeploy the application

Resulting in Error: data and hash arguments required sounds like you are running the container without persistent storage. The default recommended command would prevent this from occurring. Let me know if this is indeed the same command you are using because I cannot replicate this behavior

@timothycarambat commented on GitHub (Aug 22, 2025): This step: > Redeploy the application Resulting in Error: data and hash arguments required sounds like you are running the container without persistent storage. The default [recommended command](https://docs.anythingllm.com/installation-docker/quickstart) would prevent this from occurring. Let me know if this is indeed the same command you are using because I cannot replicate this behavior
yindo commented 2026-02-22 18:20:16 -05:00
Author
Owner
Copy Link
Copy Source

@Sabst commented on GitHub (Aug 24, 2025):

My deployment environment is Terraform'ed (full k8s multi-host cluster and apps available in a few minutes).
No persistent storage (apart from the backups) survive redeployment. Consider this as a routine disaster recovery simulation.
But I do not think the problem is related to persistent storage though.

I had to investigate a bit more and I think I understand the problem better now.

There are several points:

  1. I see that the server API entrypoints have a try/catch, as they should... but not validatedRequest (this is certainly true for most of the middleware functions) !
    I tested and the problem goes away when this function has a try/catch (and I get the expected 401 error).
    That's the main problem IMO

  2. My deployment is using the community helm chart and I missed the point about declaring SIG_* variables. As they have a default (random) value, the problem of not defining them was ignored.
    That explains why my second deployment was crashing as the encryption keys changed (not in your case as you have fixed values)

  3. There is probably a use for the SIG_* random default values but if something is mandatory, this should be enforced (and disallow a deployment with unsupported values). To be considered...

I hope this helps.

Thank you for your work :)
Stephane

@Sabst commented on GitHub (Aug 24, 2025): My deployment environment is Terraform'ed (full k8s multi-host cluster and apps available in a few minutes). No persistent storage (apart from the backups) survive redeployment. Consider this as a routine disaster recovery simulation. But I do not think the problem is related to persistent storage though. I had to investigate a bit more and I think I understand the problem better now. There are several points: 1. I see that the server API entrypoints have a try/catch, as they should... but not validatedRequest (this is certainly true for most of the middleware functions) ! I tested and the problem goes away when this function has a try/catch (and I get the expected 401 error). That's the main problem IMO 2. My deployment is using the community helm chart and I missed the point about declaring SIG_* variables. As they have a default (random) value, the problem of not defining them was ignored. That explains why my second deployment was crashing as the encryption keys changed (not in your case as you have fixed values) 3. There is probably a use for the SIG_* random default values but if something is mandatory, this should be enforced (and disallow a deployment with unsupported values). To be considered... I hope this helps. Thank you for your work :) Stephane
yindo changed title from [BUG]: Crash when navigating to localhost. to [GH-ISSUE #947] [BUG]: Crash when navigating to localhost. 2026-06-05 14:36:05 -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 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#574
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?