17 Known Issues

Ensure you read the known issues using Podman and related utilities.

Quadlets Fail For An Unprivileged User

Quadlets fail to run on Oracle Linux 8 without root permissions. While trying to start a Quadlet service, you might see the following error message:

Error: mkdir /sys/fs/cgroup/blkio/user.slice/runtime: permission denied

Or, if you're using crun as the runtime, you might see the following error message: 

Error: OCI runtime error: crun: the requested cgroup controller `pids` is not available"

Because of this problem, Podman Shell isn't available for Oracle Linux 8.

(Bug 36076771)

Podman Build Command Fails With "Operation Not Permitted" When Unprivileged Users Try to Establish Volumes

Oracle Linux 8 hosts running UEK 6 Update 3 or the Red Hat Compatible Kernel (RHCK) can't mount or umount volumes on rootless Podman containers. Typically, trying to do so causes this error message:

...
error running container: from /usr/bin/runc creating container for [/bin/sh -c touch /tmp/myfile1]: 
time="2024-02-06T00:22:07Z" level=warning msg="unable to get oom kill count" error="no directory 
specified for memory.oom_control" time="2024-02-06T00:22:07Z" level=error msg="runc create failed: 
unable to start container process: error during container init: error mounting 
\"/home/podman_user/.local/share/containers/storage/overlay-containers/2f80607e49897c5a2a8020bfbc520ddf2ee48157722fe2e207b3491ada5df0c9/userdata/overlay/1738053957/merge\" 
to rootfs at \"/data\": 
mount /home/podman_user/.local/share/containers/storage/overlay-containers/2f80607e49897c5a2a8020bfbc520ddf2ee48157722fe2e207b3491ada5df0c9/userdata/overlay/1738053957/merge:
/data (via /proc/self/fd/7), 
data: lowerdir=/home/podman_user/.local/share/containers/storage/overlay/fe866d78514c04dd5df86d3ff2fff3288c675a52874f114c36f7d94aa1666bd6/merged/data,
upperdir=/home/podman_user/.local/share/containers/storage/overlay-containers/2f80607e49897c5a2a8020bfbc520ddf2ee48157722fe2e207b3491ada5df0c9/userdata/overlay/1738053957/upper,
workdir=/home/podman_user/.local/share/containers/storage/overlay-containers/2f80607e49897c5a2a8020bfbc520ddf2ee48157722fe2e207b3491ada5df0c9/userdata/overlay/1738053957/work,
userxattr,context=\"system_u:object_r:container_file_t:s0:c10,c760\": operation not permitted"
...

If that functionality is required, upgrade the Oracle Linux 8 host to boot from the UEK7. For more information, see the Unbreakable Enterprise Kernel documentation.

(Bug 36250501)

Container Storage is Not Accessible to an Unprivileged User

Container storage might fail to mount for an unprivileged user in some Oracle Linux 8 environments. Typically this displays in the following way: 

$ podman run --name c_uidmap --uidmap 0:10000:10000
localhost:5555/os/oraclelinux:7 true
Error: error creating container storage: error creating an ID-mapped copy of
layer "a8c980a5275b9ef8dc35f68daacc8fc82e463cd25adeb84ccda98b58ce84f122":
exit status 1: error during chown: error mapping container ID pair
idtools.IDPair{UID:10000, GID:10000} for
"usr/lib64/python2.7/SimpleXMLRPCServer.pyo" to host: Container ID 10000
cannot be mapped to a host ID

The issue can be resolved by updating the container mount options to include the index=off parameter. Edit /etc/containers/storage.conf to make this change, for example: 

mountopt = "nodev,metacopy=on,index=off"

(Bug 34161379)

X509 Certificate Relies on Legacy Common Name Field

With the release of Podman version 3.0, included with Oracle Linux 8.4, Podman commands that require TLS verification for certificates that don't include a proper Subject Alternative Name (SAN) return the following error: 

x509: certificate relies on legacy Common Name field, use SANs or
temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

This issue is the result of a newer version of the Go compiler used to build Podman. The issue occurs when working with local or private image registries that use self-signed certificates.

You can either update certificates to use a proper SAN or set the GODEBUG environment variable x509ignoreCN=0 in the environment where you intend to run Podman. For example add the following line to $HOME/.bashrc file to continue using self-signed certificates where a SAN isn't set: 

export GODEBUG=x509ignoreCN=0

(Bug 32821677)

Executing Podman Attach --latest Causes Panic if No Containers Are Available

If you run the podman attach --latest command and no containers exist in an environment, a runtime error similar to the following occurs: 

sudo podman  attach --latest
panic: runtime error: index out of range
...

Note that this error no longer occurs as soon as containers exist in the environment. Running the command when no containers exist is meaningless.

(Bug 29882537)

Requirements for Using the Default Podman Detach Key Sequence

On Oracle Linux 8 hosts, the default key sequence that you use to detach a container (CTRL+P, CTRL+Q) requires a console that can handle detachment (pseudo-tty), and an input channel for passing control signals (stdin). Otherwise, you can't create a container, attach it with the podman attach -l command, and then quit, or detach the container by using the default key sequence, as documented in the podman-attach(1) manual page.

To ensure that you can use the default CTRL+P, CTRL+Q key sequence to detach a container, use either of the following methods to create a container. In both cases ensure that you use the -t option so that a pseudo-tty is created:

  • Create a container in the background: 

    sudo podman run --rm -dt container-registry.oracle.com/os/oraclelinux:8-slim top -b

    You can then use the podman attach -l command to attach the container and the CTRL+P, CTRL+Q key sequence to detach the container.

  • Create a container interactively: 

    sudo podman run --rm -it container-registry.oracle.com/os/oraclelinux:8-slim top -b

    The interactive method creates the container and automatically attaches it. You can then use the CTRL+P, CTRL+Q key sequence to detach the container.

    For more information, see the podman(1) and podman-attach(1) manual pages.

(Bug 29882852)

Authentication Error Occurs Pulling an Image Using an Incorrect Name

If you try to pull an image by running the podman pull image-name command, but you don't specify the correct or full name of the image, an authentication error occurs.

For example, the following error is displayed because oracle:ol8-slim was specified as the name of the image instead of oraclelinux:ol8-slim, which is the correct name for the image: 

podman pull oracle:ol8-slim

Displays output similar to:

Trying to pull registry.redhat.io/oracle:latest...Failed
Trying to pull quay.io/oracle:latest...Failed
Trying to pull docker.io/oracle:latest...Failed
error pulling image "oracle:ol8-slim": unable to pull oracle:ol8-slim: 3 errors
occurred:

* Error determining manifest MIME type for
docker://registry.redhat.io/oracle:ol8-slim: unable to retrieve auth token:
invalid username/password
* Error determining manifest MIME type for docker://quay.io/oracle:ol8-slim:
Error reading manifest latest in quay.io/oracle: error parsing HTTP 404
response body: invalid character '<' looking for beginning of value:
"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>404 Not
Found</title>\n<h1>Not Found</h1>\n<p>The requested URL was not found on the
server.  If you entered the URL manually please check your spelling and try
again.</p>\n"
* Error determining manifest MIME type for docker://oracle:ol8-slim: Error
reading manifest latest in docker.io/library/oracle: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

To prevent this error from occurring, always specify the correct image name with the podman pull command.

(Bug 29894231)

The Latest Tag Is Missing From the oraclelinux Image on Docker Hub

Trying to search for or pull the oraclelinux image from Docker Hub fail with a manifest unknown error because the latest tag doesn't exist: 

podman pull docker://docker.io/library/oraclelinux:latest
Trying to pull repository docker.io/library/oraclelinux ...
manifest for oraclelinux:latest not found: manifest unknown: manifest unknown
manifest for oraclelinux:latest not found: manifest unknown: manifest unknown

This issue also affects the Skopeo utility, which expects the latest tag to be present by default: 

skopeo inspect docker://docker.io/library/oraclelinux
FATA[0001] Error parsing image name "docker://docker.io/library/oraclelinux": 
Error reading manifest latest in docker.io/library/oraclelinux: 
manifest unknown: manifest unknown

The latest tag was removed from the Oracle Linux official images in June 2020 to reduce customer confusion. Downstream images using oraclelinux:latest or no tag should be updated to oraclelinux:8 for future builds. Note that we recommend using the -slim variants for the smallest possible image size.

For more information, see Oracle Linux Container Image Tagging Conventions.

(Bug 31524440)

Podman Pod Create Fails on Oracle Linux 9 For An Unprivileged User With IMA Enabled

On systems, such as Oracle Linux 9, where Integrity Measurement Architecture (IMA) is enabled and enforcing, running podman pod create as an unprivileged user can fail with an error similar to: 

...
RemoveOptions:copier.RemoveOptions{All:false}}: copier: put: error setting
extended attributes on "/catatonit": error setting value of extended
attribute "security.ima" on "/catatonit": operation not permitted

This issue occurs when the rpm-plugin-ima package is installed before the podman or podman-catatonit packages. In the case where the rpm-plugin-ima package is installed the catatonit binary, used by Podman to provide init services to containers, is an IMA signed file and unprivileged users don't have permissions to set security extended attributes (xattrs) on the file system.

To work around the issue, uninstall rpm-plugin-ima and reinstall the podman package. Note that on fresh installations of Oracle Linux 9.2 and later, the rpm-plugin-ima package isn't installed by default and the issue is unlikely to appear. Also, from Podman version 4.4 onwards, the catatonit binary is included in the podman package and you don't need to install the podman-catatonit package.

(Bug 34578553)

Executing Podman Attach --latest Causes Panic if No Containers Are Available

If you run the podman attach --latest command and no containers exist in an environment, a runtime error similar to the following occurs: 

sudo podman  attach --latest
panic: runtime error: index out of range
...

Note that this error no longer occurs as soon as containers exist in the environment. Running the command when no containers exist is meaningless.

(Bug 29882537)