I'm on Ubuntu, and I've recently encountered an issue when trying to use rootless podman with the docker-credential-gcloud helper installed via snap.
This works fine when using the official google-cloud-sdk apt packages, and it used to work with snap packages until last October.
Here's what I see now:
$ podman pull gcr.io/private/image
Trying to pull gcr.io/private/image...
2021/02/01 13:19:17.474248 cmd_run.go:994: WARNING: cannot create user data directory: cannot create "/root/snap/google-cloud-sdk/166": mkdir /root/snap: permission denied
cannot create user data directory: /root/snap/google-cloud-sdk/166: Permission denied
error getting credentials - err: exit status 1, out: ``
Error: unable to pull gcr.io/private/image: Error initializing source docker://gcr.io/private/image:latest: error getting username and password: error getting credentials - err: exit status 1, out: ``
So it looks like the credential helper is being executed as root now. I'm not sure in which component the problem lies, or where I should file an issue.
Any pointers would be appreciated.
Sent with ProtonMail Secure Email.
Just a quick note that the next Podman Community Meeting is coming
up a week from this coming Tuesday. It will be Tuesday June 1, 2021 at
11:00 a.m. EDT (UTC-4). We're overloaded with topics this time and
will be talking about Podman and TYE, Podman v3.2.0 updates, Podman in
Kubernetes and Podman Machine updates. The full agenda with the link to
the video conference is here
(https://podman.io/community/meeting/agenda/). Check out the link to
WorldTImeBuddy at the top of the web page for the agenda for an easy
time converter for your local time. As usual, no charge to attend!
Also, I just posted the meeting notes from the May 2021 meeting.
They include links to the slides on Sysbox runtime, a link to the video
recording and my bad attempt at taking notes during the meeting.
As a quick note, given the number of people that we've heard from
who will be on vacation in early July, we have decided to not hold the
meeting that month. Our following meeting will be Tuesday August 3rd,
also at 11:00 a.m. EDT (UTC-4).
Not sure whether it is a right place o ask, but still. I am trying to run docker registry
in rootless podman. I have created a 'register' user and started the registry with the
podman run --privileged -d --name registry -p 5000:5000 -v /srv/registry:/var/lib/registry --restart=always registry:latest
(/srv/registry belongs to 'registry' user, so should be visible in rootless container
as belonging to root).
So far so good, I test the register with podman search and it returns expected results.
But as soon as I exit the ssh session in which I started the container, container
terminates, not immediately but in half minute or so. There;s no diagnostic about
the reason in podman logs, nor in /var/syslog, nor in dmesg output. Just in case
I tried to start it with nohup - same result. I also tried to start it as a service
using the following file:
ExecStart=/usr/bin/podman start registry
ExecStop=/usr/bin/podman stop -t 60 registry
And it still terminates in about half a minute after service startup.
How can I find at least some indication about why this happens?
\ / | |
(OvO) | Михаил Иванов |
(^^^) | |
\^/ | E-mail: ivans(a)isle.spb.ru |
^ ^ | |
Trying "regular" podman generated systemd service unit with
systemd fails with also what I could have fiddled into it so
I wonder - if a rootless container, created and managed by a
non-root user can be given to systemd(system's, not user's)
for complete management?
many thanks, L.
Putting the list back in the loop. I think you accidentally replied to me
On Wed, May 26, 2021 at 5:17 PM Thierry Parmentelat <
> Hi Valentin
> thanks for your feedback, I’m answering inline
> > Podman is not meant to run K8s. Podman targets single-node machines and
> focuses on servers and developer machines. It does not implement Container
> Runtime Interface (CRI) that K8s uses to communicate with the container
> runtime. CRI-O is dedicated to exactly that use-case.
> yeah, I got that
> so let me rephrase; the fact that I mentioned minikube - that is just a
> first step for me a beginner here - seems to have been misleading
> my ultimate goal is to deploy a k8s cluster on a handful of bare-metal
> fedora boxes, running podman instead of docker
> but I was surprised to see **almost no mention** of podman in the k8s
> documentation, where docker appears a zillion of times along with, in
> shorter supply, rkt
As mentioned before, Podman is not meant to be running underneath
Kubernetes. That is CRI-O's job.
Docker and rkt are mentioned for historical reasons. Both have been used
underneath Kubernetes for a longer period of time. rkt has been
discontinued a long time ago and also Docker is not supported underneath
> I understand that the podman team is not in charge of that documentation,
> I’m just saying this suggests podman cannot be used in this way, which I’m
> pretty certain it is, right ?
Podman cannot be used underneath Kubernetes.
> > If you see specific bugs, opening an issue upstream would be great. For
> questions, the mailing list works well, GitHub issues or the #podman
> channel on Freenode IRC (and Libera Chat).
> thanks for pointing out irc, I’ll try to join you guys there
Great, see you over there :)
I thought I'd send out an early reminder for the upcoming Podman
Community Meeting next Tuesday as I and several other maintainers based
in the US have Monday off. So we'll be meeting next Tuesday June 1,
2021 at 11:00 a.m. EDT (UTC-4) in this BlueJeans room:
https://bluejeans.com/796412039. We'll be talking about Podman and TYE,
Podman v3.2.0 update, Podman in Kubernetes, Podman machine update, and
an open forum for questions/answers. As always, free to attend!
The agenda is here for more details:
https://podman.io/community/meeting/agenda/ and we hope to see many of
I have been trying to get podman to work with systemd.
I have a pod with 4 containers inside, along with the pause container, and
I have generated systemd unit files using the command 'podman generate
If I place the generated files into the /etc/systemd/user/ directory, then
they run as expected, using the 'systemctl --user enable --now' command.
If I place them into the /etc/systemd/system directory they do not run.
This is as I expected, since the files are all in the standard user's home
directory, as are the volume mounts.
However, although I want them to run in the context of a standard user, I
am concerned that if some hacker breaks out into my system then because the
command to stop and start systemd unit user files will be available to
them, then they can stop the running pod as a standard user, and my server
and django site will be down. It's as simple as 'systemctl --user stop
I discussed the issue briefly with velix on the irc podman chat, he
suggested I use system groups. However, no matter how I configure my pod
and container unit files, and whether or not I use 'loginctl enable-linger'
I cannot get the pod to start.
I have read that it is possible to start podman-containers having placed
the unit files inside the /etc/systemd/system directory, which would mean
that any command to stop the pod would be followed by the systemd bringing
them back up, and the systemctl command to manipulate the pod wouldn't be
available to the standard user.
So, what is the most secure way of starting the containers, in such a way,
if possible, that should some influence gain unprivileged access, they
cannot stop the pod.
James Stewart Miller Bsc(hons) Psych.
I recently came across a message on the kubernetes discourse here
and I thought it would make sense to chime in here
in essence in that post we share our surprise to see so little reference to podman in the k8s documentation
as a first step imho it would drastically help to at least know what combinations of fedora/k8s/cri-o are expected to work properly
on my side I’ve just started playing with this combo:
* plain fedora33
* with its vanilla podman 3.1.2
* cri-o 1.20 - through
dnf module enable cri-o:1.20
dnf install cri-o
systemctl enable crio —now
* and minikube for now, that I trigger using this
minikube start --driver=podman --container-runtime=cri-o
which kind-of works, but this is very early stage, and I’m facing a few glitches so I’d really like to find a place where I can share my findings
so, a rather open question as you can see :)
any insight, either general or specific, or pointer to a doc that we would have overlooked, or clue on the right place to discuss all this, would be very much appreciated
— thanks !
Recently the community discovered that the Podman
Whatis?(https://podman.io/whatis.html) page had badly lagged behind the
reality of Podman. For example, the page talked about the
soon-to-be-released REST API (released a few months ago), and other
upcoming features that were already in play. Additionally, over the
past few months, inquiries have been made over the availability of
several documents: specific "how-to's", a user guide, rootless container
tutorials, networking tutorials, and a few issues have been lodged
against various parts of the existing documentation.
The maintainers of Podman have recognized that the documentation for the
project is not at the level it should be, even though we have made our
best effort to do so. At this point, we are hoping to get help from the
community. The level of help that we would like to get is varied. At
the top of the list would be creating issues
(https://github.com/containers/podman/issues) for any missing or
incorrect documentation. If someone in the community likes going
through man pages and making sure they're formatted consistently, we'd
love their help. If you ever wanted a big documentation project that
you could stamp your name on, then the Podman Users Guide might be a
great way to increase your documentation chops. Any help that you would
be willing to offer to better Podman's documentation would be gratefully
Also, if you or someone you know is not terribly technical yet wants to
contribute to an Open Source project, this might be a great opportunity
to get your foot in the door. We'd be more than happy to walk someone
through the git submission processes in exchange for documentation
improvements for the project. Or if they're more comfortable sending in
something via email, we'd be happy to deal with the git side of things.
So if you have documentation improvement ideas or suggestions, please
add a comment to the discussion here
(https://github.com/containers/podman/discussions/10336), or send an
email to the Podman mailing list
Paraphrasing Richard Branson: No idea is too small, and all sorts of
ideas have the potential to change the project as we know it for the better.
We have an absolutely terrific and growing Podman community. Hopefully,
this effort will garner more contributors and create better
documentation for Podman. Thanks for your attention, and feel free to
contact me if you have any questions.