docker socket helper should also setup local socket path on macOS

[benoitf]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Docker Desktop on macOS seems to move to a "local/non root" installation path for the docker.sock file.
https://docs.docker.com/desktop/release-notes/
docker/for-mac#6529

Steps to reproduce the issue:

1. podman machine start

Describe the results you received:

if podman-mac-helper has been installed, it will install /var/run/docker.sock

Describe the results you expected:

To have socket in /var/run/docker.sock

and to the new local path $HOME/.docker/run/docker.sock (if for some reason the mac helper was not granted root privileges it should add the socket in the home directory)

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)

Output of podman info:

(paste your output here)

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

(paste your output here)

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes/No

Additional environment details (AWS, VirtualBox, physical, etc.):

[benoitf]

Hello,
In this issue it's to add socket into the HOME folder so there is no need of root permissions. Podman machine can set it up even without an helper

It's to add an extra binding in the home folder. Tooling will probably use this local/per user location as well. ( In addition to the historical /var/run/docker.sock requiring admin privileges on macOS

[n1hility]

sorry that was posted to the wrong issue fixing

[n1hility]

So I am on the fence on this one, and am wondering if this is the right thing for us to do. The current behavior of Docker Desktop is that all tools use a default context which points to /var/run/docker.sock, which is also where docker client libraries are also hard coded to look. There was a version that switched the active context to a home directory location but it was immediately pulled back. So a user should not normally need this socket to be replaced.

If podman replaces this socket, there is no ability to run docker desktop in parallel with podman, which may not be common but could be useful in cases where you want to move data.

Another approach we could do is add a podman context for users to use via docker context create and switch to it. Although this might introduce issues for users like the ones that lead to them rolling back that default change.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

I think podman desktop should tell Podman to listen on this socket by default and then turn it off in the case where users want to install both docker and podman at the same time.

The question is which is going to be more common, users blowing up trying to talk to /var/run/docker.sock or installing docker and podman at the same time on a MAC.

podman desktop could easily figure this out and tell podman to do the right thing. or setup a link to do the right thing.

[benoitf]

IMHO istening to sockets is the job of podman-mac-helper
So of course, from Podman Desktop we can manage the helper but helper should handle the different use-cases. Install globally at /var/run, in home folder or both. (Up to the user to choose how to configure it)

Also people expect to have tooling working even when podman desktop not being launched

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[ThomasVitale]

It would be great if Podman could handle the new socket location and get a working setup on macOS without additional manual configuration

[n1hility]

Ok so I see how this is happening. The context configuration is preserved across versions and not changed. So if you started with either 4.13.0, or you started with a config in recent versions with the symlink option deselected (advanced instead of recommended options), then your context config would have been created, preferring the home location. While I don't believe we should modify ~/.docker/run/docker.sock, we could switch the docker default context if the mac helper was installed, implying this was the user's intention. I'll draw up a PR for this soon.

[n1hility]

/assign

[flouthoc]

@n1hility A small question, shouldn't podman-mac-helper detect the docker version and work with socket at /Users/<username>/.docker/run/docker.sock instead of silently switching docker's default context ?

[vyasgun]

@n1hility can I take up this issue if it hasn't been addressed yet?

[n1hility]

sorry everyone for the delay was away on vacation recently and missed some github notifications (catching up)

@flouthoc good question, the problem is that nearly everything that speaks Docker (all docker language bindings for python, js, java, etc) expects /var/run/docker.sock (or a named pipe named docker_engine on windows). It's pretty much just the docker CLI that knows how to talk to the recently introduced user dir docker.sock

[benoitf]

I think podman machine, should register a docker context 'podman' and switch to this context if the current context is not reachable

It's how Docker Desktop does (and others)

[n1hility]

IMO listening on an address that isn't in use is one thing, but reconfiguring another programs client when the user hasn't requested it and without prompting them to is a bit aggressive. Today we are cautious with Podman Desktop and we prompt the user if they would like compatibility mode. Shouldn't we be consistent and only reconfigure clients when they ask?

It's how Docker Desktop does (and others)

The only way I am aware of that docker changes this (aside from the past broken version) is if they explicitly disable /var/run/docker.sock support as part of install.