Open arminus opened 3 months ago
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
Sorry, didn't find https://github.com/memgraph/memgraph/issues/1734 - I can confirm that the compose file given in https://github.com/memgraph/memgraph/issues/1734#issuecomment-1952435168 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).
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?
No, this is not a blocker - just "unusual" behavior
Describe the bug
then it just exits with status 139 according to docker desktop.
To Reproduce Steps to reproduce the behavior:
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](https://github.com/memgraph/mage/assets/683680/df17f87a-cc28-4d40-b45e-cacd19b87ba2)