Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Mage docker container doesn't start with bind mounts on Windows #454

Open
arminus opened this issue Mar 20, 2024 · 5 comments
Open
Labels
bug bug community community Effort - Medium Effort - Medium Frequency - EveryTime Frequency - EveryTime Priority - Now Priority - Now Reach - Most Reach - Most Severity - S2 Severity - S2

Comments

@arminus
Copy link

arminus commented Mar 20, 2024

Describe the bug

2024-03-20 14:42:22 [2024-03-20 13:42:22.500] [warning] auth_module_create_missing_role flag is deprecated. It not possible to create roles through the module anymore.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] auth_module_create_missing_user flag is deprecated. It not possible to create users through the module anymore.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] auth_module_manage_roles flag is deprecated. It not possible to create roles through the module anymore.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] storage_parallel_index_recovery flag is deprecated. Check storage_mode_parallel_schema_recovery for more details.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] auth_module_create_missing_role flag is deprecated. It not possible to create roles through the module anymore.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] auth_module_create_missing_user flag is deprecated. It not possible to create users through the module anymore.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] auth_module_manage_roles flag is deprecated. It not possible to create roles through the module anymore.
2024-03-20 14:42:22 [2024-03-20 13:42:22.504] [warning] storage_parallel_index_recovery flag is deprecated. Check storage_mode_parallel_schema_recovery for more details.
2024-03-20 14:42:22 You are running Memgraph v2.15.0
2024-03-20 14:42:22 To get started with Memgraph, visit https://memgr.ph/start

then it just exits with status 139 according to docker desktop.

To Reproduce
Steps to reproduce the behavior:

version: "3"
 
services:
  memgraph:
    image: memgraph/memgraph-mage:latest
    container_name: memgraph-mage
    volumes:
      - ./mg_lib:/var/lib/memgraph
      - ./mg_log:/var/log/memgraph
      - ./mg_etc:/etc/memgraph
    ports:
      - "7687:7687"
      - "7444:7444"
    command: ["--log-level=TRACE"]
 
  lab:
    image: memgraph/lab:latest
    container_name: memgraph-lab
    ports:
      - "3000:3000"
    depends_on:
      - memgraph
    environment:
      - QUICK_CONNECT_MG_HOST=memgraph
      - QUICK_CONNECT_MG_PORT=7687

Run this compose on Windows 10 with docker desktop 4.26.1, directories ./mg_lib, ./mg_log and ./mg_etc have been created before running docker compose up

Expected behavior
Mage should start like it does when the compose defines volumes instead of bind mounts.

Screenshots
2024-03-20_144904

@arminus arminus added the bug bug label Mar 20, 2024
@matea16
Copy link

matea16 commented Mar 20, 2024

Hi @arminus, thank you for reporting this issue. We are aware that the bind mounts are not working as expected. We've recently had a similar discussion on another issue related to this and there were a few possible solutions mentioned, such as changing the file ownership and permissions, changing the default location of a docker data directory with the --data-root property and using named volumes instead of bind mounts. Let me know if any of the solutions help in your case

@arminus
Copy link
Author

arminus commented Mar 21, 2024

Sorry, didn't find memgraph/memgraph#1734 - I can confirm that the compose file given in memgraph/memgraph#1734 (comment) works for me in a sense that the volumes are created where I want them, but they are still not bind mounts (which is kind of our policy for docker data)

Since so far, I'm testing Memgraph on Windows only, file ownership and permissions shouldn't normally be the cause. I'm using docker for a variety of purposes and bind mounts haven't been an issue for any so far, in particular not with Neo4J where I'm coming from in this case. (experience is different on Linux of course).

@matea16 matea16 added Severity - S3 Severity - S3 Effort - Unknown Effort - Unknown Frequency - EveryTime Frequency - EveryTime Reach - Some Reach - Some labels Mar 22, 2024
@matea16
Copy link

matea16 commented Mar 22, 2024

We intend to work on improving the overall user experience with docker-compose soon so any feedback is valuable. I'll keep you updated on the topic. Is this currently a blocker for you?

@arminus
Copy link
Author

arminus commented Mar 23, 2024

No, this is not a blocker - just "unusual" behavior

@gvolfing gvolfing added Effort - High Effort - High Effort - Medium Effort - Medium and removed Effort - Unknown Effort - Unknown Effort - High Effort - High labels May 14, 2024
@hal-eisen-MG hal-eisen-MG added the Priority - Later Priority - Later label May 19, 2024
@gitbuda gitbuda removed their assignment Jul 11, 2024
@antejavor antejavor added Reach - Most Reach - Most and removed Reach - Some Reach - Some labels Aug 20, 2024
@antejavor
Copy link

antejavor commented Aug 20, 2024

@antejavor antejavor added Severity - S2 Severity - S2 and removed Severity - S3 Severity - S3 labels Aug 20, 2024
@hal-eisen-MG hal-eisen-MG added Priority - Now Priority - Now and removed Priority - Later Priority - Later labels Aug 25, 2024
@katarinasupe katarinasupe added the community community label Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug bug community community Effort - Medium Effort - Medium Frequency - EveryTime Frequency - EveryTime Priority - Now Priority - Now Reach - Most Reach - Most Severity - S2 Severity - S2
Projects
Development

No branches or pull requests

7 participants