container/podman
container/podman
1
0
Fork 0
mirror of https://github.com/containers/podman synced 2024-10-21 09:45:32 +00:00
Code Issues Packages Projects Releases Wiki Activity
podman/troubleshooting.md
OpenShift Merge Robot a4cc7bca60
Merge pull request #1802 from mheon/troubleshooting_rootless 
Update troubleshooting guide to deal with rootless path
2018-11-12 10:34:13 -08:00

4.6 KiB
Raw Blame History

PODMAN logo

Troubleshooting

A list of common issues and solutions for Podman

1) Variety of issues - Validate Version

A large number of issues reported against Podman are often found to already be fixed in more current versions of the project. Before reporting an issue, please verify the version you are running with podman version and compare it to the lastest release documented on the top of Podman's README.md.

If they differ, please update your version of PODMAN to the latest possible and retry your command before reporting the issue.

2) No such image or Bare keys cannot contain ':'

When doing a podman pull or podman build command and a "common" image can not be pulled, it is likely that the /etc/containers/registries.conf file is either not installed or possibly misconfigured.

Symptom

$ sudo podman build -f Dockerfile
STEP 1: FROM alpine
error building: error creating build container: no such image "alpine" in registry: image not known

or

$ sudo podman pull fedora
error pulling image "fedora": unable to pull fedora: error getting default registries to try: Near line 9 (last key parsed ''): Bare keys cannot contain ':'.

Solution

  • Verify that the /etc/containers/registries.conf file exists. If not, verify that the skopeo-containers package is installed.
  • Verify that the entries in the [registries.search] section of the /etc/containers/registries.conf file are valid and reachable.
    • i.e. registries = ['registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com']

3) http: server gave HTTP response to HTTPS client

When doing a Podman command such as build, commit, pull, or push to a registry, tls verification is turned on by default. If authentication is not used with those commands, this error can occur.

Symptom

$ sudo podman push alpine docker://localhost:5000/myalpine:latest
Getting image source signatures
Get https://localhost:5000/v2/: http: server gave HTTP response to HTTPS client

Solution

By default tls verification is turned on when communicating to registries from Podman. If the registry does not require authentication the Podman commands such as build, commit, pull and push will fail unless tls verification is turned off using the --tls-verify option. NOTE: It is not at all recommended to communicate with a registry and not use tls verification.

  • Turn off tls verification by passing false to the tls-verification option.
  • I.e. podman push --tls-verify=false alpine docker://localhost:5000/myalpine:latest

4) Rootless: could not get runtime - database configuration mismatch

In Podman release 0.11.1, a default path for rootless containers was changed, potentially causing rootless Podman to be unable to function. The new default path is not a problem for new installations, but existing installations will need to work around it with the following fix.

Symptom

$ podman info
could not get runtime: database run root /run/user/1000/run does not match our run root /run/user/1000: database configuration mismatch

Solution

To work around the new default path, we can manually set the path Podman is expecting in a configuration file.

First, we need to make a new local configuration file for rootless Podman.

  • mkdir -p ~/.config/containers
  • cp /usr/share/containers/libpod.conf ~/.config/containers

Next, edit the new local configuration file (~/.config/containers/libpod.conf) with your favorite editor. Comment out the line starting with cgroup_manager by adding a # character at the beginning of the line, and change the path in the line starting with tmp_dir to point to the first path in the error message Podman gave (in this case, /run/user/1000/run).

4) rootless containers cannot ping hosts

When using the ping command from a non-root container, the command may fail because of a lack of privileges.

Symptom

$ podman run --rm fedora ping -W10 -c1 redhat.com
PING redhat.com (209.132.183.105): 56 data bytes

--- redhat.com ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

Solution

It is most likely necessary to enable unprivileged pings on the host. Be sure the UID of the user is part of the range in the /proc/sys/net/ipv4/ping_group_range file.

To change its value you can use something like: sysctl -w "net.ipv4.ping_group_range=0 2000000".

To make the change persistent, you'll need to add a file in /etc/sysctl.d that contains net.ipv4.ping_group_range=0 $MAX_UID.