- Podman - Podman List Archives

Re: Podman restore container failed
by Anton Novikov (A) 29 Oct '25

29 Oct '25

Sorry about replying to an old thread. I've had this problem when using criu, and fixed it by changing the permissions recorded in the files.img file in the checkpoint dir, before restoring from it. You can use "crit show" to decode the file to json format and replace "mode": 16749 with "mode": 16877, before encoding the json back to .img format using "crit encode". Writing about this workaround in case anyone finds this thread while searching for the error message.

1 0

add capability to existing rootful container?
by lejeczek 22 Oct '25

22 Oct '25

Hi guys. As per the subject - is this possible (tampering included) ? many thanks, L.

1 0

Podman Community Meeting is coming! Tues, Oct 7, 2025, 11:00 a.m. EDT (UTC-4)
by Tom Sweeney 02 Oct '25

02 Oct '25

Hey All, The Podman Community Meeting is next Tues, Oct 7, 2025, at 11:00 am EDT (UTC-4). Currently, our agenda is wide open. Feel free to send suggestions for topics, or add your own to: https://hackmd.io/fc1zraYdS0-klJ2KJcfC7w. The conference link in the agenda, free to attend! The Podman Community Meeting is next Tues, Oct 7, 2025, at 11:00 am EDT (UTC-4). Currently, our agenda is wide open. Feel free to send suggestions for topics, or add your own to: https://hackmd.io/fc1zraYdS0-klJ2KJcfC7w. The conference link in the agenda, free to attend! t

1 0

Podman v5.6.2 Released
by container.tools.ci＠gmail.com 30 Sep '25

30 Sep '25

Hi all, Podman v5.6.2 is now available. You may view the full details at https://github.com/containers/podman/releases/tag/v5.6.2 Release Notes: -------------- ### Bugfixes - Fixed a bug where stopping the `podman machine start` command with SIGPIPE could result in machine state being stuck as "Starting" ([#26949](https://github.com/containers/podman/issues/26949)). - Fixed a bug where `podman build` would fail with a permissions error when building Containerfiles using a non-root user and cache mounts ([#27044](https://github.com/containers/podman/issues/27044)). ### Misc - Updated Buildah to v1.41.5

1 0

Podman v5.6.1 Released
by container.tools.ci＠gmail.com 04 Sep '25

04 Sep '25

Hi all, Podman v5.6.1 is now available. You may view the full details at https://github.com/containers/podman/releases/tag/v5.6.1 Release Notes: -------------- ### Security - This release addresses CVE-2025-9566, where Kubernetes YAML run by `podman play kube` containing `ConfigMap` and `Secret` volumes can use crafted symlinks to overwrite content on the host. ### Bugfixes - Fixed a bug where network creation and removal events were displayed incorrectly when the `journald` events driver was in use. - Fixed a bug where the `--security-opt seccomp=unconfined` option was broken on Windows ([#26855](https://github.com/containers/podman/issues/26855)). - Fixed a bug where containers created with a name longer than 64 characters, no explicit hostname, the the `container_name_as_hostname` option in `containers.conf` set to `true` would fail to start. - Fixed a bug where Podman would fail to start containers when runc 1.3.0 or later was used as the OCI runtime ([#26938](https://github.com/containers/podman/issues/26938)). ### Misc - Adjusted the systemd-tmpfiles script to recursively remove temporary files directories placed in `/tmp`, ensuring proper operation of Podman after a reboot if `/tmp` is not a tmpfs. - Updated Buildah to v1.41.4 - Updated the containers/storage to v1.59.1 - Updated the containers/common library to v0.64.2

1 0

Podman Community Cabal Meeting! Tuesday September 2, 11:00 a.m. EDT (UTC-4)
by Tom Sweeney 26 Aug '25

26 Aug '25

Hey All! A week and a few minutes from now, on Sept 2, 2025, at 11:00 am EDT (UTC-4), the Podman Cabal Meeting will be going on with updates on CNCF, Mono Repo, and Podman 6.0 plans. Please note we're moving to Zoom! Topics and the new conference link in the Agenda: https://hackmd.io/gQCfskDuRLm7iOsWgH2yrg?both Hope to see you there! t

1 0

When Privileged Doesn't work (and other woes)
by Jim Melton 21 Aug '25

21 Aug '25

This is a long convoluted tail. I’ve spent hours searching the interwebs and trying various things. If anyone can offer any insights at all, I would appreciate it. The goal is to create an Atlassian Bamboo Agent running in a container (base image <https://hub.docker.com/r/atlassian/bamboo-agent-base/>, source <https://bitbucket.org/atlassian-docker/docker-bamboo-agent-base/src/master/…>). My purpose in this agent is to enable NVIDIA CUDA jobs to run on a server with a GPU. I’m running on RHEL 8.8, podman 4.9. This machine is using cgroups v1 (more on that later), and runc. I’m assuming that this agent container will run podman commands as part of various build jobs (but I don’t have insight into how build jobs are managed). I’ve never run podman in a container before. I did find Dan Walsh’s blog <https://www.redhat.com/en/blog/podman-inside-container> and drew upon it heavily. Starting from the Atlassian Dockerfile.ubi, and a UBI9 base image, I added Dan’s steps from creating podman-stable and created my image, bamboo-agent. I don’t think the details of the Containerfile are important at this time. Normally, I expose the GPU to my containers with the --device nvidia.com/gpu=all flag. It appears the easiest way to run containers in containers is to run the outer container with --privileged, but when paired with the NVIDIA CDI, the container fails to run. It appears that there is a device /dev/dri/card1 that is not world-readable (for reasons) so it can’t be mounted in the container. Since I can’t use --privileged, I tried to find the “Goldilocks” solution. Starting here: /usr/bin/podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable --cap-add=sys_admin,perfmon --group-add keep-groups --mount type=bind,src=/home/jmelton/projects/bamboo/work,dst=/usr/src/project --workdir /usr/src/project --log-driver k8s-file --log-opt path=/home/jmelton/projects/bamboo/log/bamboo-agent.20250820120312.log --network host -v podman_containers:/var/lib/containers,rw -v bambooAgentVolume:/var/atlassian/application-data/bamboo-agent --hostname=agent-cuda-12_3 -it --name=bamboo-agent bamboo-agent:latest bash My outer container is rootless, running as me. In my (outer) container, I’m only going to run rootful containers. I might be naive, but since the outer container is rootless, my “rootful” inner containers are still in user-space. If I try to (for example) use the podman user in the podman-stable image, I end up with files in my home directory that I don’t own and can’t delete. In this running, container, if I try to run anything, [root@agent-cuda-12_3 project]# podman run --rm -it alpine ls / WARN[0000] Using cgroups-v1 which is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version. Set environment variable `PODMAN_IGNORE_CGROUPSV1_WARNING` to hide this warning. Trying to pull docker.io/alpine:latest... Getting image source signatures Copying blob 9824c27679d3 done | Copying config 9234e8fb04 done | Writing manifest to image destination Error: mounting storage for container ba508c13fcdde1a5cd40de68aad8c62cedecb86d7001d79190b1a3205cae114c: creating overlay mount to /var/lib/containers/storage/overlay/1bd977c57d4226fd4146762e90974f6cd7aed84a9a94716087fa63a205340e5c/merged, mount_data="lowerdir=/var/lib/containers/storage/overlay/l/7EYYG6BVMHUWP3XB5NMRWSYZFL,upperdir=/var/lib/containers/storage/overlay/1bd977c57d4226fd4146762e90974f6cd7aed84a9a94716087fa63a205340e5c/diff,workdir=/var/lib/containers/storage/overlay/1bd977c57d4226fd4146762e90974f6cd7aed84a9a94716087fa63a205340e5c/work,nodev,fsync=0,volatile": using mount program /usr/bin/fuse-overlayfs: unknown argument ignored: lazytime fuse: device not found, try 'modprobe fuse' first fuse-overlayfs: cannot mount: No such file or directory Well, that was annoying. But after a bit of mucking about and searching various posts, I come up with running the outer container like this: /usr/bin/podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable --cap-add=sys_admin,perfmon --group-add keep-groups --mount type=bind,src=/home/jmelton/projects/bamboo/work,dst=/usr/src/project --workdir /usr/src/project --log-driver k8s-file --log-opt path=/home/jmelton/projects/bamboo/log/bamboo-agent.20250820133608.log --network host --device /dev/fuse -v podman_containers:/var/lib/containers,rw -v bambooAgentVolume:/var/atlassian/application-data/bamboo-agent --hostname=agent-cuda-12_3 -it --name=bamboo-agent bamboo-agent bash Close, but no cigar: [root@agent-cuda-12_3 project]# podman run --rm -it alpine ls / Trying to pull docker.io/alpine:latest... Getting image source signatures Copying blob 9824c27679d3 done | Copying config 9234e8fb04 done | Writing manifest to image destination Error: OCI runtime error: crun: mount_setattr `/sys`: Function not implemented [root@agent-cuda-12_3 project]# exit [jmelton@gpuserver1 bamboo]$ Error: OCI runtime error: crun: mount_setattr `/sys`: Function not implemented -bash: /sys: Is a directory bash: Error:: command not found… Ultimately, I discovered that if I ran the inner container like this: [root@agent-cuda-12_3 project]# podman run -v /sys:/sys -it busybox echo hello Trying to pull docker.io/busybox:latest... Getting image source signatures Copying blob 80bfbb8a41a2 done | Copying config 0ed463b26d done | Writing manifest to image destination hello It works. Note that since the /sys in the inner container belongs to the outer container, the security risk it low. So, how can I configure podman to always mount that when I run a container? After some frustrating dialogue with ChatGPT, one would think that /etc/containers/mounts.conf would do the trick. Unfortunately, it doesn’t. My guess is that those mounts happen too late for crun but it’s all idle speculation. The best I could coax out of ChatGPT was a wrapper script to insert the -v /sys:/sys to the podman invocation. I would love to find a podman-native solution. My head is sufficiently flattened from beating it against the mount wall, that I give up looking for the perfect solution, and move on to creating a Quadlet service to run my agent. Whoops, Quadlet requires cgroups v2. Ok, edit /etc/default/grub: GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/rhel_gpuserver1-swap rd.lvm.lv=rhel_gpuserver1/root rd.lvm.lv=rhel_gpuserver1/swap rhgb quiet \ rd.driver.blacklist=nouveau \ systemd.unified_cgroup_hierarchy=1" sudo grub2-mkconfig -o /boot/grub2/grub.cfg reboot Then all hell breaks loose. /usr/bin/podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable --cap-add=sys_admin,perfmon --group-add keep-groups --mount type=bind,src=/home/jmelton/projects/bamboo/work,dst=/usr/src/project --workdir /usr/src/project --log-driver k8s-file --log-opt path=/home/jmelton/projects/bamboo/log/bamboo-agent.20250820174923.log --network host --cap-add chown --device /dev/fuse --security-opt 'unmask=/sys/*' -v podman_containers:/var/lib/containers,rw -v bambooAgentVolume:/var/atlassian/application-data/bamboo-agent --hostname=agent-cuda-12_3 -dt --name=bamboo-agent bamboo-agent Error: runc: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: openat2 /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/user.slice/libpod-047db35e8dc99bee6681f9042215c7760c6ec6fb7a295a5bdb779a17b5711fb7.scope/pids.max: no such file or directory: OCI runtime attempted to invoke a command that was not found ChatGPT suggests updating podman, so I do, to 4.9.4, which is the latest appstream I find. Unfortunately, things continue to go downhill: /usr/bin/podman run --rm=true --device nvidia.com/gpu=all --security-opt=label=disable --cap-add=sys_admin,perfmon --network=host --workdir=/usr/src/project --mount type=bind,source=/home/jmelton/projects/lbe/muse-gpu,destination=/usr/src/project --mount type=bind,source=/home/data,dst=/data,ro=true -it artifactory.iss.snc:80/docker/lbe/dev ./build.bash Error: OCI runtime error: runc: runc create failed: unable to start container process: unable to apply cgroup configuration: unable to start unit "libpod-15c84f640fb7343c120c39c468775ebf873a9033ba5e8ed4dcf4bba295700be2.scope" (properties [{Name:Description Value:"libcontainer container 15c84f640fb7343c120c39c468775ebf873a9033ba5e8ed4dcf4bba295700be2"} {Name:Slice Value:"user.slice"} {Name:Delegate Value:true} {Name:PIDs Value:@au [70881]} {Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true} {Name:IOAccounting Value:true} {Name:TasksAccounting Value:true} {Name:DefaultDependencies Value:false}]): Interactive authentication required. What in the world does it mean “Interactive authentication required”? I do find indications of an error similar to this showing up on Fedora 37, and theoretically it was fixed by some change to systemd. I’ll try anything at this point, but I only get to 239-82, which is quite a bit older than when the issue purportedly appeared. By now, even ChatGPT is grasping at straws. It says switch to crun. There doesn’t appear to be a downside, so I install crun-1.14.3-2, and edit /usr/share/containers/containers.conf to switch the runtime. Verified: $ podman info --format '{{.Host.OCIRuntime}}' {crun crun-1.14.3-2.module+el8.10.0+23250+94af2c8e.x86_64 /usr/bin/crun crun version 1.14.3 commit: 1961d211ba98f532ea52d2e80f4c20359f241a98 rundir: /run/user/1001/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL} My results of the most trivial invocation are different, but not better: $ podman run --rm busybox ls Error: OCI runtime error: crun: sd-bus call: Process org.freedesktop.systemd1 exited with status 1: Input/output error At this point, I reverted to cgroup v1 so other users could continue working, but I’m completely baffled. While I know lots of people do “podman in podman”, has anyone else tried to do “podman with CUDA in podman”? I have a RHEL9 machine that natively runs cgroups v2 that I will try on tomorrow, but I have run out of avenues to pursue. — “God can't give us peace and happiness apart from Himself because there is no such thing.” ― C.S. Lewis Jim Melton http://blogs.melton.space/pharisee/

1 0

Podman v5.6.0 Released
by container.tools.ci＠gmail.com 15 Aug '25

15 Aug '25

Hi all, Podman v5.6.0 is now available. You may view the full details at https://github.com/containers/podman/releases/tag/v5.6.0 Release Notes: -------------- ### Features - A new set of commands for managing Quadlets has been added as `podman quadlet install` (install a new Quadlet for the current user), `podman quadlet list` (list installed Quadlets), `podman quadlet print` (print the contents of a Quadlet file), and `podman quadlet rm` (remove a Quadlet). These commands are presently not available with the remote Podman client - we expect support for this to arrive in a future release. - Quadlet `.container` units can now specify environment variables without values in the `Environment=` key, retrieving the value from the host when the container is started ([#26247](https://github.com/containers/podman/issues/26247)). - Quadlet `.pod` units now support two new keys, `Label=` (to set labels on the created pod) and `ExitPolicy=` (to set exit policy for the created pod) ([#25961](https://github.com/containers/podman/issues/25961) and [#25596](https://github.com/containers/podman/issues/25596)). - Quadlet `.image` units now support a new key, `Policy=`, to set pull policy for the image (e.g. pull always, pull only if newer version available) ([#26446](https://github.com/containers/podman/issues/26446)). - Quadlet `.network` units now support a new key, `InterfaceName=`, to specify the name of the network interface created. - The `podman machine init` command now supports a new option, `--swap`, enabling swap in the created virtual machine and setting it to a given size (in megabytes) ([#15980](https://github.com/containers/podman/issues/15980)). - The `--mount` option to `podman create` and `podman run` now supports `dest=` as a valid alias for `destination=`. - The `podman kube play` command can now restrict container execution to specific CPU cores and specific memory nodes using the `io.podman.annotations.cpuset/$ctrname` and `io.podman.annotations.memory-nodes/$ctrname` annotations ([#26172](https://github.com/containers/podman/issues/26172)). - The `podman kube play` command now supports the `lifecycle.stopSignal` field in Pod YAML, allowing the signal used to stop containers to be specified ([#25389](https://github.com/containers/podman/issues/25389)). - The `podman artifact` suite of commands for interacting with OCI artifacts is now available in the remote Podman client and the bindings for the REST API. - The `podman volume import` and `podman volume export` commands are now available in the remote Podman client ([#26049](https://github.com/containers/podman/issues/26409)). - The `--build-context` option to `podman build` is now supported by the remote Podman client ([#23433](https://github.com/containers/podman/issues/23433)). - The `podman volume create` command now accepts two new options, `--uid` and `--gid`, to set the UID and GID the volume will be created with. - The `podman secret create` command now has a new option, `--ignore`, causing the command to succeed even if a secret with the given name already exists. - The `podman pull` command now has a new option, `--policy`, to configure pull policy. - The `--mount type=artifact` option to `podman create`, `podman run`, and `podman pod create` now allows the filename of the artifact in the container to be set using the `name=` option (e.g. `podman run --mount type=artifact,name=$NAME,...`). - The `--tmpfs` option to `podman create` and `podman run` now allows a new option, `noatime`, to be passed (e.g. `podman run --tmpfs /run:noatime ...`) ([#26102](https://github.com/containers/podman/issues/26102)). - The `podman update` command now has a new option, `--latest`, to update the latest container instead of specifying a specific container ([#26380](https://github.com/containers/podman/issues/26380)). - A new command, `podman buildx inspect`, has been added to improve Docker compatibility ([#13014](https://github.com/containers/podman/issues/13014)). ### Changes - In preparation for a planned removal of the BoltDB database in Podman 6.0, a warning has been added for installations still using BoltDB. These warnings are presently not visible by default, which will happen in Podman 5.7. - The `podman artifact` suite of commands for interacting with OCI artifacts is now considered stable. - For users running `podman machine` VMs using the `libkrun` provider on an M3 or newer host running macOS 15+, nested virtualization is enabled by default. - When creating `podman machine` VMs on Windows using the WSL v2 provider, images are now pulled as artifacts from `quay.io/podman/machine-os`, matching the behavior of other VM providers. - Signal forwarding done by the `--sig-proxy` option to `podman run` and `podman attach` is now more robust to races and no longer forwards the `SIGSTOP` signal. - The `podman system check --quick` command now skips checking layer digests. - Podman on Windows using the WSLv2 provider now prefers the WSL executable in `C:\Program Files\Windows Subsystem for Linux\wsl.exe` over the one in `WindowsApps`, avoiding common “access denied” issues ([#25787](https://github.com/containers/podman/issues/25787)). - The `--mount type=artifact` option to `podman create`, `podman run`, and `podman pod create` now mounts artifacts containing a only a single blob as a file at the given destination path if the path does not exist in the image. - The `podman volume export` command now refuses to export to `STDOUT` if it is a TTY ([#26506](https://github.com/containers/podman/issues/26506)). - When generating Quadlet units with options known to be problematic when used with Podman, such as `User=`, `Group=`, and `DynamicUser=` in the `[Service]` section of a unit, Quadlet will now warn the user of the potential incompatibility ([#26543](https://github.com/containers/podman/issues/26543)). ### Bugfixes - Fixed a bug where the `--security-opt unmask=` option to `podman create` and `podman run` did not allow comma-separated lists of paths to be passed, instead only allowing a single path. - Fixed a bug where stopping a Podman container could unintentionally kill non-Podman processes if the PID of an exec session started inside the container was reused for a new process while the container was running ([#25104](https://github.com/containers/podman/issues/25104)). - Fixed a bug where `podman machine init` could fail if run in a Podman container ([#25950](https://github.com/containers/podman/issues/25950)). - Fixed a bug where `podman machine` VMs would sometimes receive incorrect timezone information. - Fixed a bug where `podman machine` VMs created with a custom username would not have lingering enabled. - Fixed a bug where the `podman machine init` command on Windows when using the WSL 2 provider did not reliably determine if WSL was installed ([#25523](https://github.com/containers/podman/issues/25523)). - Fixed a bug where the name of Quadlet `.pod` units that did not specify the `PodName=` key was set incorrectly ([#26062](https://github.com/containers/podman/issues/26062)). - Fixed a bug where Quadlet `.container` units joining a pod specified in a `.pod` unit would fail as the pod name was set incorrectly when creating the container ([#26105](https://github.com/containers/podman/issues/26105)). - Fixed a bug where Quadlet would not generate `RequiresMountsFor` when mounting a `.volume` unit with `Type=bind` set into a container ([#26125](https://github.com/containers/podman/issues/26125)). - Fixed a bug where Quadlet dropin files were not correctly overwritten by new dropin files with the same name further along the hierarchy if the two dropin files did not share a parent directory ([#26555](https://github.com/containers/podman/issues/26555)). - Fixed a bug where Quadlet would sometimes not print warnings when failing to parse units ([#26542](https://github.com/containers/podman/issues/26542)). - Fixed a bug where Quadlet `.pod` files did not include the last `Environment=` key in the `[Service]` section in the generated systemd service ([#26521](https://github.com/containers/podman/issues/26521)). - Fixed a bug where starting a container with already-running dependencies would fail. - Fixed a bug where OCI hooks in a directory specified with `--hooks-dir` would fail to run when containers were restarted ([#17935](https://github.com/containers/podman/issues/17935)). - Fixed a bug where the `--mount` option to `podman create` and `podman run` required the `type=` option to be specified, instead of defaulting to `volume` when it was not present ([#26101](https://github.com/containers/podman/issues/26101)). - Fixed a bug where the `podman kube play` command would fail on Windows when specifying an absolute path to YAML files ([#26350](https://github.com/containers/podman/issues/26350)). - Fixed a bug where the `--security-opt seccomp=` option to `podman create`, `podman run`, and `podman pod create` could error on Windows when given a path to a Seccomp profile ([#26558](https://github.com/containers/podman/issues/26558)). - Fixed a bug where the `--blkio-weight-device`, `--device-read-bps`, `--device-write-bps`, `--device-read-iops`, and `--device-write-iops` options to `podman create` and `podman run` incorrectly accepted non-block devices. - Fixed a bug where the `podman build` command handled the `--ignorefile` option differently from the `buildah bud` command ([#25746](https://github.com/containers/podman/issues/25746)). - Fixed a bug where the `podman rm -f` command could return an error when trying to remove a running container whose `conmon` process had been killed ([#26640](https://github.com/containers/podman/issues/26640)). - Fixed a bug where the `podman inspect` command did not correctly display log size for containers when `log_size_max` was set in containers.conf. ### API - A full set of API endpoints for interacting with artifacts has been added, including inspecting artifacts (`GET /libpod/artifacts/{name}/json`), listing all artifacts (`GET /libpod/artifacts/json`), pulling an artifact (`POST /libpod/artifacts/pull`), removing an artifact (`DELETE /libpod/artifacts/{name}`), adding an artifact (or appending to an existing artifact) from a tar file in the request body (`POST /libpod/artifacts/add`), pushing an artifact to a registry (`/libpod/artifacts/{name}/push`), and retrieving the contents of an artifact (`GET /libpod/artifacts/{name}/extract`). - The Compat Create endpoint for Containers now accepts a new parameter, `HostConfig.CgroupnsMode`, to specify the cgroup namespace mode of the created container. - The Compat Create endpoint for Containers now respects the `base_hosts_file` option in `containers.conf`. - The Compat System Info endpoint now returns a new field, `DefaultAddressPools`. - The Compat System DF endpoint has removed the deprecated `BuilderSize` field. - The Compat Ping endpoint now sets `Builder-Version` to `1` to match Docker installs that do not include BuildKit. - The Compat List endpoint for Images now returns the `shared-size` field unconditionally, even if the `shared-size` query parameter was not set to true. If not requested through query parameter, it is set to `-1`. This improves Docker API compatibility. - The Compat Inspect endpoint for Images now no longer returns the deprecated `VirtualSize` field when Docker API version 1.44 and up is requested. - Fixed a bug where the Compat Delete API for Containers would remove running containers when the `FORCE` parameter was set to true; Docker only removes stopped containers ([#25871](https://github.com/containers/podman/issues/25871)). - Fixed a bug where the Compat List and Compat Inspect endpoints for Containers returned container status using Podman statuses instead of converting to Docker-compatible statuses ([#17728](https://github.com/containers/podman/issues/17728)). - Fixed a bug where healthchecks that exceeded their timeout were not properly terminated; they now receive SIGTERM, then SIGKILL after a delay, if their timeout is exceeded ([#26086](https://github.com/containers/podman/pull/26086)). - Fixed a bug where `application/json` responses would be HTML escaped, mutating some responses (e.g. `<missing>` becoming `\u003cmissing\u003e` in image history responses) ([#17769](https://github.com/containers/podman/issues/17769)). ### Misc - Quadlet now no longer uses container/pod ID files when stopping containers, but instead passes the name of the container/pod directly to `podman stop`/`podman pod stop`. - When building Podman via Makefile, it will now attempt to dynamically link sqlite3 if the library and header are installed locally. This and other optimizations should result in a significant reduction in binary size relative to Podman 5.5.x. Packagers can use the `libsqlite3` build tag to force this behavior when not using the Makefile to build. - Updated Buildah to v1.41.3 - Updated the containers/common library to v0.64.1 - Updated the containers/storage library to v1.59.1 - Updated the containers/image library to v5.36.1

1 0

Windows 10 in a podman container
by Matthias Apitz 12 Aug '25

12 Aug '25

Hello, We produce software, written in Java and JS which runs in the library in tomcat and the enduser later manages it with a browser. Automated tests of this part of software are driven by Jenkins jobs which trigger in some Windows 10 machine the automated launch of a browser and some piece of software carries out the "use" of the software in the browser as a human being would do it, based on a scripting language. So far the picture, now to podman. The problem is, that the software which allows this scripting of the "use" is only available for Windows 10. And with the EOL of Windows 10 we're asked to decommission this machine. So the question is: Does podman allows the setup and use of Windows 10 and are there any containers to download and start from with the FROM ... statement in the Dockerfile? Thanks in advance matthias -- Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023) I, Matthias, I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.

3 2

# in environment ?
by lejeczek 09 Aug '25

09 Aug '25

Hi guys. Do you use # in your envs? I wonder if it's just me having issues with those. For a test, to reproduce the issue, 'ghost' web solution would be easy & quick: -> $ podman run -dt ...................... --env database__client=mysql --env database__connection__host=11.1.0.1 --env database__connection__user=ghostadm --env database__connection__password='xyz#admghost' --env database__connection__database=ghost_xyz --env url=https://ghost.xyz So far all I've tried with 'database__connection__password' failed, quoting &| escaping. I often use # - does anybody have a way to make it work? many thanks, L.

3 3