Precreate and chown snapshots and storage dirs

[ilkecan]

... in unprivileged mode to avoid Docker named volumes being owned by the root user.

All Submissions:

• Contributions should target the dev branch. Did you create your branch from dev?
• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Currently, with this docker-compose.yaml file:

---
version: "3.8"

name: test

services:
  qdrant:
    image: qdrant/qdrant:v1.6.1-unprivileged
    volumes:
      - qdrant:/qdrant/storage/

volumes:
  qdrant:

docker compose up fails:

...
test-qdrant-1  | 2023-11-02T20:24:57.189168Z  INFO storage::content_manager::consensus::persistent: Initializing new raft state at ./storage/raft_state.json
test-qdrant-1  | Error: Service internal error: Failed to write file: Permission denied (os error 13) at path "/qdrant/./storage/.atomicwriteZEuaWn"
test-qdrant-1 exited with code 1

If we change the container command to ls -al we see that the target of the Docker named volume is owned by the root user:

Attaching to test-qdrant-1
test-qdrant-1  | total 57248
test-qdrant-1  | drwxr-xr-x 1 qdrant qdrant     4096 Nov  2 20:26 .
test-qdrant-1  | drwxr-xr-x 1 root   root       4096 Nov  2 20:26 ..
test-qdrant-1  | drwxr-xr-x 1 qdrant qdrant     4096 Oct  9 09:45 config
test-qdrant-1  | -rwxrwxr-x 1 qdrant qdrant     1840 Sep  6 22:21 entrypoint.sh
test-qdrant-1  | -rwxr-xr-x 1 qdrant qdrant 58590208 Oct 11 15:39 qdrant
test-qdrant-1  | drwxr-xr-x 1 qdrant qdrant     4096 Oct 11 15:39 static
test-qdrant-1  | drwxr-xr-x 2 root   root       4096 Nov  2 20:24 storage
test-qdrant-1 exited with code 0

A similar error is received when the volume targets snapshots directory instead.

After some research, it seems the only way to fix this is to run chown inside the container. It works even if we run chown before the volume is mounted. Currently chown is already run in here:

qdrant/Dockerfile

Line 127 in 50f3ef1

chown -R "$USER_ID:$USER_ID" "$APP"; \

But since snapshots and storage directories don't exist at that point, they are not currently affected by it. The solution is to precreate those directories before that line, and this PR does that.

[generall]

Those directories are not absolute and can depend on the configuration, I am afraid we can't just hard-code them in docker

[timvisee]

Those directories are not absolute and can depend on the configuration, I am afraid we can't just hard-code them in docker

Even if the user would define custom ones, I don't think it would hurt if these two are created by default in the image.

[bashofmann]

The root issue is that docker compose does not allow you to configure permissions when mounting a named volume. Instead it inherits the permissions of the existing directory, or mounts it as root if no directory exists.

There is a issue from 2016 about this docker/compose#3270.

I guess it does not hurt to have the default locations present in the image. Most users won't change these, and if they do, and run in docker-compose, they need to work around this somehow. For example by building their own image or just not using docker-compose.