Check Existing Issues

• I have searched for any existing and/or related issues.
• I have searched for any existing and/or related discussions.
• I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

0.6.30

Ollama Version (if applicable)

No response

Operating System

Mac

Browser (if applicable)

No response

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of both Open WebUI and Ollama.
• I have included the browser console logs.
• I have included the Docker container logs.
• I have provided every relevant configuration, setting, and environment variable used in my setup.
• I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
• I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
• Start with the initial platform/version/OS and dependencies used,
• Specify exact install/launch/configure commands,
• List URLs visited, user input (incl. example values/emails/passwords if needed),
• Describe all options and toggles enabled or changed,
• Include any files or environmental changes,
• Identify the expected and actual result at each stage,
• Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

All files added to a Knowledge Base with restricted group access should be retrievable when accessed by authorized users.

Actual Behavior

Some files within the same Knowledge Base cannot be accessed, even though group permissions are correctly configured.
Upon debugging, inaccessible files have collection_name values in the form of file-{uuid}, while accessible files correctly use the Knowledge Base’s ID as their collection name.

Steps to Reproduce

⚠️ Note: This issue occurs intermittently and may not always be reproducible.

1. Create a Knowledge Base with restricted access (specific user group).

2. Upload multiple files to the Knowledge Base using the UI

3. Observe that some files are accessible, while others intermittently return “not found” or permission errors, even though access configuration is correct.

4. Check the database entries for the affected files — their collection_name values are file-{uuid} instead of the Knowledge Base ID.

5. Attempt to retrieve these files through the /api/v1/knowledge/{id}/file endpoint.

6. Only files with a collection_name that exactly matches the Knowledge Base ID are accessible.

Logs & Screenshots

• The issue does not affect all users.

• Admin users can access all files in the Knowledge Base without any errors.

• For non-admin users with proper group permissions, the issue occurs only for specific files, not for all files in the same Knowledge Base.

• When affected, those users see “Not found” or a permission-related error when trying to open the file, even though they have valid access rights.

Additional Information

From reviewing the codebase and runtime behavior, my current hypothesis (not yet confirmed) is as follows:

Files are uploaded first via POST /api/v1/files/, followed by a separate call to /api/v1/knowledge/{id}/file/add to associate them with a Knowledge Base.

The upload endpoint initiates vector database operations asynchronously in a background task.

If the Knowledge Base association (knowledge.add) completes before the background task finishes, the async job may overwrite the collection_name field with the default file-{uuid} format.

As a result, when the Knowledge Base later checks access permissions, it compares the file’s collection_name (which still has the file- prefix) against the Knowledge Base ID. This mismatch likely causes the file to appear inaccessible despite correct group permissions.

This is still a hypothesis based on observation and code tracing, and the exact sequence or locking behavior may differ depending on task timing.