-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
docker socket helper should also setup local socket path on macOS #16548
Comments
Hello, 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 |
sorry that was posted to the wrong issue fixing |
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 |
A friendly reminder that this issue had no activity for 30 days. |
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. |
IMHO istening to sockets is the job of podman-mac-helper Also people expect to have tooling working even when podman desktop not being launched |
A friendly reminder that this issue had no activity for 30 days. |
A friendly reminder that this issue had no activity for 30 days. |
It would be great if Podman could handle the new socket location and get a working setup on macOS without additional manual configuration |
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. |
/assign |
@n1hility A small question, shouldn't |
@n1hility can I take up this issue if it hasn't been addressed yet? |
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 |
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) |
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?
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. |
Hello everyone! Writing this just to save someone time and thinking, this is not a bug report as I was using old Podman version I've just installed Podman Desktop 1.7.1 on my macOS, and it didn't create any symlinks for the docker socket. I've tried So I've created two of them manually, and then all worked wonderfully:
P.S. I didn't save the values of the previous symlinks, unfortunately |
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:
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
:Output of
podman info
:Package info (e.g. output of
rpm -q podman
orapt list podman
orbrew info podman
):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.):
The text was updated successfully, but these errors were encountered: