cli icon indicating copy to clipboard operation
cli copied to clipboard

Mounts denied for /socket_mnt/.../docker.sock with Docker Desktop when running supabase start

Open Skirja opened this issue 9 months ago • 2 comments

Describe the bug When running supabase start on Fedora with Docker Desktop, the process fails with a "Mounts denied" error specifically for the Docker Desktop socket path (/socket_mnt/home//.docker/desktop/docker.sock). This occurs even though Docker Desktop's file sharing is configured to share the parent directory (/home//.docker/desktop), and basic Docker operations (like docker run hello-world and mounting regular files from the same directory) work correctly. The issue seems to be specific to Docker Desktop denying the mount of its own socket when requested by Supabase CLI.

To Reproduce Steps to reproduce the behavior:

  1. Initialize a new Supabase project: supabase init (accept defaults).
  2. Attempt to start the Supabase services: supabase start.
  3. Observe the process, which proceeds through database migrations and seeding.
  4. See error: failed to start docker container: Error response from daemon: Mounts denied: The path /socket_mnt/home/skirja/.docker/desktop/docker.sock is not shared from the host and is not known to Docker

Expected behavior supabase start should successfully start all local Supabase services without any "Mounts denied" errors, allowing for local development.

System information Rerun the failing command with --create-ticket flag.

  • Ticket ID: 8d5d10aac33249ab92b8d2aa1eb050d5
  • Version of OS: Fedora Linux 42 (Workstation Edition)
  • Version of CLI: 2.23.4
  • Version of Docker: Docker version 28.1.1, build 4eba377

Image

Image

Skirja avatar May 21 '25 08:05 Skirja

Maybe not the best solution, but adding the root directory (/) worked for me on Ubuntu 24.04.2 LTS x86_64.

zacwalls avatar May 26 '25 22:05 zacwalls

A slightly more secure solution is to mkdir /socket_mnt then add that to the file share.

Worked on Linux Mint 22.1

Thanks for the inspiration @zacwalls

Melochaotic avatar May 30 '25 23:05 Melochaotic

Complementing the above: socket_mnt is created at /, so you’ll need sudo to create that folder and set its group to docker to avoid permission issues.

sudo mkdir /socket_mnt
sudo chown $USER:docker /socket_mnt

btzo avatar Jul 07 '25 17:07 btzo

Complementing the above: socket_mnt is created at /, so you’ll need sudo to create that folder and set its group to docker to avoid permission issues.

sudo mkdir /socket_mnt sudo chown $USER:docker /socket_mnt

I tried this and it didn't work. I'm on Ubuntu 24. I had to also give it root directory permissions with /. Not entirely happy about that, though.

threehappypenguins avatar Jul 10 '25 18:07 threehappypenguins

I found another effective method to run the Supabase stack locally.

For Debian-based distributions:

  1. Remove any existing Docker installation and the ~/.docker directory (used by Docker Desktop):

    sudo apt remove docker* containerd runc
    rm -rf ~/.docker
    
  2. Install QEMU and virtualization tools:

    sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager virtinst
    
  3. Install Docker Engine and related packages:

    sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    
  4. Add your user to the Docker group (to avoid using sudo with Docker):

    sudo usermod -aG docker $USER
    newgrp docker
    
  5. Initialize and start Supabase:

    npx supabase init
    npx supabase start
    

Now, your Supabase stack should start successfully.


For RPM-based distributions (e.g., Fedora, RHEL, CentOS):

  1. Remove any existing Docker installation and the ~/.docker directory.

  2. Install virtualization tools:

    sudo dnf groupinstall "Virtualization"
    
  3. Add your user to the Docker group (to avoid using sudo with Docker):

    sudo usermod -aG docker $USER
    newgrp docker
    
  4. Continue with Supabase setup:

    npx supabase init
    npx supabase start
    

harshsoni-harsh avatar Jul 13 '25 05:07 harshsoni-harsh

Turning off analytics in your supabase/config.toml also bypasses the error:

[analytics]
enabled = false
port = 54327
# Configure one of the supported backends: `postgres`, `bigquery`.
backend = "postgres"

alexhooley avatar Jul 14 '25 14:07 alexhooley

Complementing the above: socket_mnt is created at /, so you’ll need sudo to create that folder and set its group to docker to avoid permission issues. sudo mkdir /socket_mnt sudo chown $USER:docker /socket_mnt

I tried this and it didn't work. I'm on Ubuntu 24. I had to also give it root directory permissions with /. Not entirely happy about that, though.

This worked for me in 24 after adding the entry into the resources -> file sharing -> virtual file shares section in docker desktop settings

coderatchet avatar Sep 15 '25 10:09 coderatchet

Turning off analytics in your supabase/config.toml also bypasses the error:

[analytics] enabled = false port = 54327

Configure one of the supported backends: postgres, bigquery.

backend = "postgres"

It worked, thank you very much, but you now that part of the config file is very important?

vqc1909a avatar Jan 07 '26 09:01 vqc1909a

Turning off analytics in your supabase/config.toml also bypasses the error: [analytics] enabled = false port = 54327

Configure one of the supported backends: postgres, bigquery.

backend = "postgres"

It worked, thank you very much, but you now that part of the config file is very important?

From my understanding, it will switch off the logging features on your local Supabase. You won't be able to view anything in the "Logs" tab:

Image

alexhooley avatar Jan 07 '26 10:01 alexhooley

Turning off analytics in your supabase/config.toml also bypasses the error: [analytics] enabled = false port = 54327

Configure one of the supported backends: postgres, bigquery.

backend = "postgres"

It worked, thank you very much, but you now that part of the config file is very important?

From my understanding, it will switch off the logging features on your local Supabase. You won't be able to view anything in the "Logs" tab:

Image

GREAT, but when I want to change of supabase database branch, i got this error "error diffing schema: error running container: exit 1:
[sql_e12dd29]: Executing query failed: connect ECONNREFUSED 2600:1f18:2e13:9d37:c4a:ad24:c335:8bf1:5432 main worker has been destroyed

Try rerunning the command with --debug to troubleshoot the error.", I thought ubuntu would be great to develop, but i see it was an error, when i was developing in archlinux i didn't get any of this errors, i think i will come back

vqc1909a avatar Jan 07 '26 10:01 vqc1909a

I found another effective method to run the Supabase stack locally.

For Debian-based distributions:

  1. Remove any existing Docker installation and the ~/.docker directory (used by Docker Desktop): sudo apt remove docker* containerd runc rm -rf ~/.docker
  2. Install QEMU and virtualization tools: sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager virtinst
  3. Install Docker Engine and related packages: sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
  4. Add your user to the Docker group (to avoid using sudo with Docker): sudo usermod -aG docker $USER newgrp docker
  5. Initialize and start Supabase: npx supabase init npx supabase start

Now, your Supabase stack should start successfully.

For RPM-based distributions (e.g., Fedora, RHEL, CentOS):

  1. Remove any existing Docker installation and the ~/.docker directory.
  2. Install virtualization tools: sudo dnf groupinstall "Virtualization"
  3. Add your user to the Docker group (to avoid using sudo with Docker): sudo usermod -aG docker $USER newgrp docker
  4. Continue with Supabase setup: npx supabase init npx supabase start

You are my savior bro, thank you very much, I was thinking to use arch linux but this worked, so you would say the error is docker desktop, right?, because it only happens if you install docker desktop, even right now installing docker desktop in ubuntu

vqc1909a avatar Jan 07 '26 18:01 vqc1909a

is there a way to customize or override the docker compose file that supabase CLI uses on start so we can define the bind mount for the docker socket?

TheRyanBurke avatar Jan 19 '26 17:01 TheRyanBurke

I'm able to get supabase CLI started with the creation, directory ownership, and file sharing mapping steps for /socket_mnt as described above. However, the vector container never successfully starts. Logs from the vector container:

supabase_vector_recess-fastback       | 2026-01-19 10:59:32.023 | 2026-01-19T17:59:32.023631Z  INFO vector::app: Internal log rate limit configured. internal_log_rate_secs=10
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.023 | 2026-01-19T17:59:32.023748Z  INFO vector::app: Log level is enabled. level="vector=info,codec=info,vrl=info,file_source=info,tower_limit=trace,rdkafka=info,buffers=info,lapin=info,kube=info"
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.023 | 2026-01-19T17:59:32.023824Z  INFO vector::app: Loading configs. paths=["/etc/vector/vector.yaml"]
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.056 | 2026-01-19T17:59:32.056204Z  WARN vector::config::loading: Transform "router._unmatched" has no consumers
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.056 | 2026-01-19T17:59:32.056442Z  INFO source{component_kind="source" component_id=docker_host component_type=docker_logs component_name=docker_host}: vector::sources::docker_logs: Capturing logs from now on. now=2026-01-19T17:59:32.056400654+00:00
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.056 | 2026-01-19T17:59:32.056492Z  INFO source{component_kind="source" component_id=docker_host component_type=docker_logs component_name=docker_host}: vector::sources::docker_logs: Listening to docker log events.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208365Z  INFO vector::topology::running: Running healthchecks.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208427Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208446Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208451Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208454Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208486Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208489Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208492Z  INFO vector::topology::builder: Healthcheck passed.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208774Z ERROR source{component_kind="source" component_id=docker_host component_type=docker_logs component_name=docker_host}: vector::sources::docker_logs: Listing currently running containers failed. error=error trying to connect: Connection refused (os error 111)
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.208 | 2026-01-19T17:59:32.208796Z  INFO vector: Vector has started. debug="false" version="0.28.1" arch="x86_64" revision="ff15924 2023-03-06"
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.218 | 2026-01-19T17:59:32.218523Z  INFO vector::internal_events::api: API server running. address=0.0.0.0:9001 playground=http://0.0.0.0:9001/playground
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.218 | 2026-01-19T17:59:32.218555Z  INFO vector::app: All sources have finished.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.218 | 2026-01-19T17:59:32.218566Z  INFO vector: Vector has stopped.
supabase_vector_recess-fastback       | 2026-01-19 10:59:32.220 | 2026-01-19T17:59:32.220618Z  INFO vector::topology::running: Shutting down... Waiting on running components. remaining_components="logflare_auth, logflare_rest, logflare_functions, logflare_kong, logflare_realtime, logflare_storage, logflare_db" time_remaining="59 seconds left"

As a workaround, I am using --ignore-health-checks and monitoring logs through Docker Desktop.

TheRyanBurke avatar Jan 19 '26 18:01 TheRyanBurke

The workarounds described above don't address the issue. The problem is that the socket path for 'vector' is incorrectly specified with this setup. It's trying to directly bind to the userspace docker.sock, which is unsupported (see https://github.com/docker/for-mac/issues/6545#issuecomment-1295599122). I opened a PR that fixes this.

unlair avatar Feb 02 '26 22:02 unlair