already accessed by another instance of Qdrant client

[morpheuskibbe]

Hey. I tried to upload a file in the 'context' section of the UI. it claims that

RuntimeError: Storage folder C:\Users\morph\AppData\Local\private-gpt\local_data\qdrant is already accessed by another instance of Qdrant client. If you require concurrent access, use Qdrant server instead.

Anyone have any idea why this might be? Im not running more than one of these things.

[charles-benedito]

yeah that error comes from qdrant in local mode, it keeps a lock file in that storage folder and refuses to open if another python process already has it. my guess is a previous private-gpt run or an ingest script still alive in the background, check task manager for leftover python processes and kill them

if nothing is running and it still complains theres propably a stale .lock in local_data/qdrant u can delete. the proper fix for concurrent access is pointing PGPT_QDRANT_URL at a qdrant server instead of the path setting, both are in settings.yaml

[widechaos]

This can also happen with two Qdrant client objects inside one Python process, so a second PrivateGPT process isn't required.

I checked with qdrant-client==1.17.1 on macOS using a temporary, empty storage directory: opening a second client on the same path raised this error. After closing the first client, opening another succeeded even though .lock was still present. I haven't reproduced your Windows upload failure.

The local client's locking code acquires an exclusive file lock; the file's presence alone doesn't mean there's a stale lock. Its close method releases that lock. I would leave .lock in place, especially while anything might still have the storage open.

If a clean restart of just your PrivateGPT instance still fails specifically when uploading, I'd check whether the upload path creates another local client for that directory. That is a possibility to investigate, not a confirmed diagnosis. Could you share your PrivateGPT version/commit, qdrant-client version, startup command, and the traceback around the client creation? Please omit credentials and private document contents.

[IlyaKhalafi]

If you try the Qdrant server workaround, make sure the embedded path is cleared too. In current PrivateGPT settings, setting PGPT_QDRANT_URL leaves the default local path set. The client rejects having both.

For a profile-based installation, create settings-qdrant-server.yaml in your settings folder.

qdrant:
  url: http://127.0.0.1:6333
  path: null
  prefer_grpc: false

This assumes a Qdrant server is already listening there. Append qdrant-server after your existing PGPT_PROFILES entries and restart PrivateGPT, preserving your model profiles. Later profiles override earlier ones.

I checked the unchanged settings and client-builder code with qdrant-client==1.17.1 against a local HTTP fixture. URL-only configuration failed; clearing the path let both sync and async clients reach the remote endpoint. That checks configuration routing, not your Windows upload failure or a full Qdrant server.

A new server also has its own collections. This configuration does not migrate your embedded index, so keep the old store and plan to re-ingest or migrate its data.

[ashswin-git]

That message comes from Qdrant's embedded/local mode (the default qdrant.path: local_data/qdrant). On first use it opens local_data\qdrant\.lock and takes an exclusive OS file lock on it. If that lock is already held, you get this RuntimeError. The OS releases the lock when the owning process exits. So in practice, some live process still has your Qdrant folder open, and it's often not a second window you can see.

Things to check, in order:

1. A leftover PrivateGPT / Python process. If a previous run was closed by shutting the terminal window or the IDE, or crashed, the python process can stay alive in the background and keep the lock. In PowerShell:

   Get-CimInstance Win32_Process -Filter "Name like 'python%'" |
     Select-Object ProcessId, CommandLine | Format-List

   Stop any that are running private_gpt (Stop-Process -Id <pid>), then start PrivateGPT once and try the upload again.

2. Ingesting from the CLI while the server is running. make ingest / scripts/ingest_folder.py opens the same local Qdrant folder, so it can't run at the same time as the server in local mode (see [QUESTION] Method of Document Ingestion into PrivateGPT: Runtime Parallel Ingestion vs. Stop-and-Start Requirement #2190). Either upload through the UI only, or stop the server while you ingest.

3. Stale .lock file. When no PrivateGPT/Python process is running, it's safe to delete C:\Users\<you>\AppData\Local\private-gpt\local_data\qdrant\.lock and start again. Only delete it when nothing is running.

4. If you need more than one process (UI + CLI ingest, several workers), use a Qdrant server instead of local mode. For example, docker run -p 6333:6333 -v qdrant_data:/qdrant/storage qdrant/qdrant, then add a settings.override.yaml next to your settings.yaml:

   qdrant:
     url: http://localhost:6333
     path: ""        # disable local mode; url and path can't both be set

   An empty env var falls back to the default path, so setting PGPT_QDRANT_PATH= alone isn't enough. That's why this goes in the override file. Note that the local data won't move over automatically, so you'll need to re-ingest.

If none of that applies (fresh reboot, one PrivateGPT process, error on the very first upload), please post the full traceback. In local mode QdrantClientBuilder.build_clients() creates a sync client, deletes .lock, then creates an async client on the same folder (clean_lock). On Windows you can't delete a file another handle still has open, so that step may behave differently than on Linux/macOS. The line the error is raised from would show whether that's what's happening.