Podman: In MacOS, latest version(1.5.1) of podman can't pull images.

Created on 25 Aug 2019  Â·  24Comments  Â·  Source: containers/podman

/kind bug

Description
In MacOS, latest version(1.5.1) of podman can't pull images.

Steps to reproduce the issue:

  1. In MacOS console, run "brew cask instal podman"

  2. do a pull to see the issue

3.

Describe the results you received:
here is the result:
bogon:Downloads test$ podman pull quay.io/openshift-release-dev/ocp-release@sha256:c28afba66cc09233f7dfa49177423e124d939cf5b0cd60d71bbb918edb0ed739
Error: could not get runtime: dial unix /run/podman/io.podman: connect: no such file or directory

Describe the results you expected:
I can pull images by podman

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

Output of podman version:

bogon:Downloads test$ podman version
Client:
Version:            1.5.1
RemoteAPI Version:  1
Go Version:         go1.12.2
OS/Arch:            darwin/amd64

Service:
Error: could not get runtime: dial unix /run/podman/io.podman: connect: no such file or directory

Output of podman info --debug:

bogon:Downloads test$ podman info --debug
Error: could not get runtime: dial unix /run/podman/io.podman: connect: no such file or directory
kinbug remote

Most helpful comment

Personally I find this disappointing. MacOS is a primary dev environment in many organizations and podman is being advertised as a painless transition from docker CLI.

Having developer from only having to install Docker for MacOS to having install podman (via brew) and managing your own VM with remote connection is a terrible developer experience and will limit the adoption rate of this tool.

I strongly urge you guys review as IMO this is not a good product direction to continue.

All 24 comments

@gaord curious if you were following any instructions for this?

@baude not quite. Just new to podman from docker. Any ideas?

the way that the mac client works is that it needs a vm running Linux and Podman to connect to ... you then, using a configuration file, can point to that VM and interact with it.

The Mac client defaulting to a local endpoint sounds like a bug, though

no it isnt ... but the error could be better

Hi, do we have a workaround or a way to fix?

@ashley-cui PTAL

@rhatdan I think it is working correctly; the error message looks like it's telling the user that it's not connected to a remote host. I can see if I can try to edit the error message to have better information?

@ashley-cui Please tell @gaord how to set it up, or point him to documentation on how to do it.

@rhatdan Is it beneficial to add a documentation on where we are currently on the mac client? Since the explanation will be pretty long anyway, should we start something like a mac_client.md, or a mac section or remote_client.md, or some sort of blog post regarding where we are and how to use it?

Here's a brief write up: @gaord

Hi! So in order to use the the podman client on mac, currently, you have to have a linux machine running somewhere. It could be a vm or another physical machine.
In order to connect to it, you can use environment variables, flags, or the podman-remote.conf file.

To connect using flags, you can use podman --remote-host linux-ip --username root
Take a look at podman-remote.conf.5.md on how to use the conf file.

Your linux IP can be determined using ip addr

It’s probably the best if you use --username root. To do you this you may need to edit your /etc/ssh/sshd_config in your linux machine:
PermitRootLogin yes

In order to avoid ‘logging in’ every time you run a podman command, you may need to edit your /etc/ssh/sshd_config in your linux machine as follows:

PasswordAuthentication no 
PermitRootLogin without-password

You may also need to scp ssh keys from your mac to your linux host (from Mac ~/.ssh/id.pub in /root/.ssh/authorized_keys)

In order to connect, make sure your linux machine has podman installed on it, and run

sudo systemctl start io.podman.socket
sudo systemctl enable io.podman.socket

Then, you can use podman as you usually do, with the podman-remote.conf file populated or use it with flags: podman --remote-host linux-ip --username root COMMAND

A small addendum, but I would strongly recommend use SSH key authentication, as opposed to allowing passwordless root login - much safer

@ashley-cui Lets make a mac_client.md

Thanks all. that makes sense for me. -Ben

Hi team Podman,

Sorry for a question and bother.
I'm a newcomer and fans of Podman.

I got a same problem of issue above, so I read the discussions above and setup a Fedora28 VM which already installed Podman, then follow the instructions(https://podman.io/blogs/2019/01/16/podman-varlink.html) to setup socket activation of Podman.

then I back to my MackOS to install the Podman client(followed the instructions in the newest mac_client.md which just updated in these days), but I got another error regarding

# podman --remote-host 192.168.22.21 --username podmanuser images
varlink: '/usr/bin/podman --log-level=error varlink \$VARLINK_ADDRESS' is not a valid command.
Try 'varlink --help' for more information
Error: unable to get images: unexpected EOF

would you mind to let me know if there's something I missed for setup Podman and Podman client?
take your time, Thanks so much

I think you might need to use root for now. @jwhonce PTAL

@jdjgya i believe you might be missing the varlink command itself which I'm not certain is supported on f28. Can you use f29 and install one of the varlink packages that provides /usr/bin/varlink.

@jdjgya if that does not work with the latest podman and f29, please open a new issue and we'll help you out.

You should really move to f30 since f29 is getting close to it's end of life.

We talked about 'how' but not 'why'. Why we can't run podman on OSX without having a linux VM? Is there any plan to get it working without VM?
This is kind of a dealbreaker for us.

The lack of a proper OCI-compliant container runtime makes launching containers on OS X impossible without a VM being involved. There's a large amount of additional work that will need to be done if that hurdle is overcome - porting things like fuse-overlayfs and Conmon will be major efforts all their own - but without the ability to launch containers, there's no point.

Podman is a tool for running, building, manageing LINUX containers. Not MAC containers. In order to run a Linux Container you need a Linux kernel. On Windows they have added WSL to make people think that linux containers are running natively. But really under the covers they are just running a builtin VM.

Bottom line, unless MAC decided to build and support OCI based containers with an OCI based image, then you need a VM.

Personally I find this disappointing. MacOS is a primary dev environment in many organizations and podman is being advertised as a painless transition from docker CLI.

Having developer from only having to install Docker for MacOS to having install podman (via brew) and managing your own VM with remote connection is a terrible developer experience and will limit the adoption rate of this tool.

I strongly urge you guys review as IMO this is not a good product direction to continue.

Docker requires the same VM, it is not doing anything with MAC Containers. There is not difference. From a usability point of view, Boot2Docker and DockerMachine is better. Although opensource teams are working on Boot2Podman and we hope to get better integration with CRC (Code Ready Containers) for OpenShift integration. We continue to work on MAC and Windows support and are always looking for contributors to help accelerate the movement.

Was this page helpful?
0 / 5 - 0 ratings