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 #5152] [BUG]: ENOENT: /collector/hotdir when STORAGE_DIR is not /app/server/storage #4939

New Issue
Closed
opened 2026-06-05 14:51:00 -04:00 by yindo · 4 comments
yindo commented 2026-06-05 14:51:00 -04:00
Owner
Copy Link
Copy Source

Originally created by @AndreasRamsli on GitHub (Mar 5, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5152

How are you running AnythingLLM?

Docker (remote machine)

What happened?

When running the Docker image with STORAGE_DIR set to any path other than the default /app/server/storage (e.g. /workspace as forced by RunPod), all document uploads fail with:
ENOENT: no such file or directory, open '/collector/hotdir/'

Root cause: The collector hardcodes hotdir as a path relative to its own binary (/app/collector/../../hotdir → /collector/hotdir), but this directory is never created in the Docker image. When STORAGE_DIR=/app/server/storage it works by coincidence due to path alignment. With any other STORAGE_DIR it fails.

Fix: Add to the Dockerfile:
RUN mkdir -p /collector/hotdir && chown -R anythingllm:anythingllm /collector

Are there known steps to reproduce?

No response

Originally created by @AndreasRamsli on GitHub (Mar 5, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5152 ### How are you running AnythingLLM? Docker (remote machine) ### What happened? When running the Docker image with STORAGE_DIR set to any path other than the default /app/server/storage (e.g. /workspace as forced by RunPod), all document uploads fail with: ENOENT: no such file or directory, open '/collector/hotdir/<filename>' Root cause: The collector hardcodes hotdir as a path relative to its own binary (/app/collector/../../hotdir → /collector/hotdir), but this directory is never created in the Docker image. When STORAGE_DIR=/app/server/storage it works by coincidence due to path alignment. With any other STORAGE_DIR it fails. Fix: Add to the Dockerfile: RUN mkdir -p /collector/hotdir && chown -R anythingllm:anythingllm /collector ### Are there known steps to reproduce? _No response_
yindo added the bugDocker labels 2026-06-05 14:51:00 -04:00
yindo closed this issue 2026-06-05 14:51:00 -04:00
yindo commented 2026-06-05 14:51:01 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 5, 2026):

Adding that in the Dockerfile would only make it during build, it would still be missing during runtime.

In interim you can
mkdir -p /workspace/hotdir && ln -s /workspace/hotdir /collector/hotdir

which should work in that env. Otherwise the solution is really just to have multer create the directory if it does not exist for ENVs like this so that it always exists before write.

<!-- gh-comment-id:4007727075 --> @timothycarambat commented on GitHub (Mar 5, 2026): Adding that in the Dockerfile would only make it during build, it would still be missing during runtime. In interim you can `mkdir -p /workspace/hotdir && ln -s /workspace/hotdir /collector/hotdir` which should work in that env. Otherwise the solution is really just to have multer create the directory if it does not exist for ENVs like this so that it always exists before write.
yindo commented 2026-06-05 14:51:01 -04:00
Author
Owner
Copy Link
Copy Source

@JiwaniZakir commented on GitHub (Mar 13, 2026):

The path resolution issue makes sense — the collector binary resolves hotdir relative to itself at /app/collector/, which lands at /collector/hotdir instead of following STORAGE_DIR. I can fix this in the Dockerfile, though I'm wondering if the better long-term fix is also patching the collector's path resolution to respect STORAGE_DIR so it doesn't break again if the binary location changes — do you know if the hotdir path is set in the collector's Go/Node source or just derived from the binary's location?

<!-- gh-comment-id:4054281634 --> @JiwaniZakir commented on GitHub (Mar 13, 2026): The path resolution issue makes sense — the collector binary resolves `hotdir` relative to itself at `/app/collector/`, which lands at `/collector/hotdir` instead of following `STORAGE_DIR`. I can fix this in the Dockerfile, though I'm wondering if the better long-term fix is also patching the collector's path resolution to respect `STORAGE_DIR` so it doesn't break again if the binary location changes — do you know if the hotdir path is set in the collector's Go/Node source or just derived from the binary's location?
yindo commented 2026-06-05 14:51:01 -04:00
Author
Owner
Copy Link
Copy Source

@JiwaniZakir commented on GitHub (Mar 13, 2026):

Stepping back from this one — my fix for the hotdir path resolution didn't pass the project's quality gates. Unassigning myself so someone else can take it.

<!-- gh-comment-id:4054470712 --> @JiwaniZakir commented on GitHub (Mar 13, 2026): Stepping back from this one — my fix for the hotdir path resolution didn't pass the project's quality gates. Unassigning myself so someone else can take it.
yindo commented 2026-06-05 14:51:01 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 13, 2026):

Okay, so i just realized this is an easy fix it appears.

On runpod I made a new pod.
image: mintplexlabs/anythingllm

Applied the following:
Image

Everything works, chats embedding, and all other functionality and data is persisted on restarts

<!-- gh-comment-id:4058068009 --> @timothycarambat commented on GitHub (Mar 13, 2026): Okay, so i just realized this is an easy fix it appears. On runpod I made a new pod. image: `mintplexlabs/anythingllm` Applied the following: <img width="807" height="406" alt="Image" src="https://github.com/user-attachments/assets/42fc1535-b9d9-4954-a784-c996b1533990" /> Everything works, chats embedding, and all other functionality and data is persisted on restarts
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#4939
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?