Bug 1768954 - podman is not working, compains about sd-bus call
Summary: podman is not working, compains about sd-bus call
Alias: None
Product: Fedora
Classification: Fedora
Component: podman
Version: 31
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matthew Heon
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-11-05 16:23 UTC by Nuno Dias
Modified: 2019-11-07 15:57 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-11-07 15:57:40 UTC
Type: Bug

Attachments (Terms of Use)

Description Nuno Dias 2019-11-05 16:23:29 UTC
Description of problem:
When running this simple example as rootless 

podman run -dt -p 8080:8080/tcp -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \
                  -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \
                  -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \
                  registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd

following the page https://podman.io/getting-started/
I get this error
Error: sd-bus call: Permission denied: OCI runtime permission denied error

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1. Run the example as normal user

Actual results:
podman does nothing

Expected results:
a container running

Additional info:

Comment 1 Daniel Walsh 2019-11-05 20:01:44 UTC
Could you try to remove libpod.conf from homedir.

rm -f ~/.config/containers/libpod.conf

And then try again.

Comment 2 Matthew Heon 2019-11-05 20:17:09 UTC
I think this might also be an older version of `crun`.

Also, we really ought to update the tutorial, F27 is very out of date now.

Comment 3 Nuno Dias 2019-11-06 10:38:07 UTC
removing libpod.conf does not solve the problem, this is the first time I'm running podman, and yes Is using crun, and I removed runc package from the system.

Comment 4 Ed Santiago 2019-11-06 13:04:47 UTC
[ This looks like some sort of dbus problem; I'm adding Giuseppe to the CC list, he's our dbus expert. ]

Can you try running podman with '--cgroup-manager=cgroupfs'?

    $ podman --cgroup-manager=cgroupfs run ...

It might also be helpful to know your version of crun, and some important envariables:

    $ rpm -q crun
    $ env | grep XDG

Comment 5 Nuno Dias 2019-11-06 13:56:11 UTC
with --cgroup-manager=cgroupfs works

$ rpm -q crun
$ env | grep XDG

Comment 6 Giuseppe Scrivano 2019-11-06 14:56:35 UTC
what is the version of systemd you are using?

and could you also show the output for "printenv DBUS_SESSION_BUS_ADDRESS"?

Comment 7 Nuno Dias 2019-11-06 15:13:17 UTC
$ rpm -q systemd


Comment 8 Giuseppe Scrivano 2019-11-06 16:05:35 UTC
have you created the session using su -l?

Does /run/user/1000/bus exist?

Comment 9 Nuno Dias 2019-11-06 16:45:03 UTC
No, I ssh to the machine

/run/user/1000/bus doesn't exist

Comment 10 Giuseppe Scrivano 2019-11-06 17:01:53 UTC
looks like a problem with the systemd session, what is the output for "systemctl --user status dbus-broker.service" ?

Comment 11 Nuno Dias 2019-11-07 09:57:07 UTC
# systemctl --user status dbus-broker.service
Failed to connect to bus: No such file or directory

Comment 12 Giuseppe Scrivano 2019-11-07 12:24:53 UTC
so the issue is systemd not running correctly.  We need to find out why that happens.

Do you see any relevant error in `journalctl --user`?

Do you ssh into the machine as the unprivileged user or as root?

Comment 13 Nuno Dias 2019-11-07 13:21:11 UTC
This message is in journalctl
systemd[3723]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

and then
conmon 05405a27e98deb63f4d0 <error>: Failed to create container: exit status 1

I think this is because of the previous message

I ssh as a regular user

Comment 14 Giuseppe Scrivano 2019-11-07 13:54:47 UTC
not sure how to debug this further, few things to check:

sudo systemctl restart user@1000
sudo systemctl status user@1000

Have you done any change to the pam configuration?

In particular, does your /etc/pam.d/systemd-user look different than what I have here:

$ cat /etc/pam.d/systemd-user 
# This file is part of systemd.
# Used by systemd --user instances.

account required pam_unix.so
session required pam_selinux.so close
session required pam_selinux.so nottys open
session required pam_loginuid.so
session optional pam_keyinit.so force revoke
session optional pam_systemd.so

Comment 15 Nuno Dias 2019-11-07 15:03:16 UTC
So, if I remove sss from /etc/nsswitch.conf it works
I'm not using sssd to authenticate, my user is in /etc/passwd and /etc/shadow

Comment 16 Nuno Dias 2019-11-07 15:03:53 UTC
systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; vendor pres>
   Active: inactive (dead)

Comment 17 Giuseppe Scrivano 2019-11-07 15:20:33 UTC
does removing sss also fix Podman?

Comment 18 Nuno Dias 2019-11-07 15:57:40 UTC
yes, I have several sss in /etc/pam.d/* I think this was set in a previous test I made, and because this is an machine that I upgraded, something was mess.

Removing sss from /etc/nsswitch.conf or clean up /etc/pam.d/* solves the problem with podman

Note You need to log in before you can comment on or make changes to this bug.