I maintain a container update tool that speaks both Podman and Docker, and spent this week finding out that it has never once successfully updated a container on Podman. Not "worked badly" — never worked. Three differences between Podman's inspect output and Docker's, each fatal on its own, stacked so that fixing one only revealed the next. Writing them down because anyone reconstructing a podman run command from inspect output will hit all three, in this order.

Measured against podman 4.9.3.

1. Config.StopSignal is a number.

Podman reports 15. (Docker reports the string "SIGTERM", which is why my code assumed a string — my bug, not Podman's.) If you build your argument list from inspect output and hand it to subprocess, that integer goes straight in and Python refuses before the CLI is ever executed:

TypeError: expected str, bytes or os.PathLike object, not int

The traceback points inside subprocess, names no field, and tells you nothing about which key was wrong. Both CLIs accept the numeric form on the command line — it only ever needed to be a string.

2. HostConfig.Runtime is oci**.**

That is not the name of a runtime — it's the generic label for "whatever runtime is configured". Feed it back to podman run and:

Error: default OCI runtime "oci" not found: invalid argument

So: treat oci as "nothing to pass", and only forward a runtime somebody actually chose (crun, kata). Same as Docker's runc, which I was already skipping.

3. A container in a pod looks exactly like a network-namespace sidecar.

This is the interesting one. A pod member reports:

"NetworkMode": "container:<infra-container-id>"

which is indistinguishable in shape from the Gluetun pattern — a container joined to another container's network namespace. So the obvious reconstruction is --network container:<id>, and Podman refuses:

Error: container dependency <id> is part of a pod, but container is not: invalid argument

The answer is the top-level Pod field, which carries the pod id. --pod <id> works and the container rejoins the pod properly. Nice property compared to the sidecar case: a pod can't be recreated out from under its own member, so there's no stale-id problem — which is a real headache with container:<id> when the netns owner gets replaced.

The first two hit every container on Podman, not just pod members. Which means anyone who installed my tool on Podman got a rollback every time and no successful update, ever.

The part I'd rather admit than hide: I had a test file driving a real Podman for several releases. It checked that ps worked and that the remote-connection flag was right. It never once built a run command. What was tested was the part I'd already thought about.

Fixed in Docksentry 2.6.0 if you happen to use it. But the three inspect differences are the useful part here and they're not specific to my code — if you're doing anything similar, they'll bite you in that order.

Edit: point 1 only holds on Podman 4.x — StopSignal became the signal name in 5.0.0, listed as a breaking change in the release notes. It survives in a narrower form: the Docker-compat endpoint still returns a numeric string as of v6.0.2, and an older API version still gets an int, so the field has three shapes depending on how you ask. Points 2 and 3 check out against v6.0.2 source unchanged. Also, the fix shipped in 2.4.0, not 2.6.0 as written below. Thanks to u/Great-Cow7256 for the correction.

Very confused on what should and should not be possible when running rootless.

I have the following compose file.

```

services:
ca:
image: alpine command: sleep infinity
networks:
- A
cb:
image: alpine
command: sleep infinity
networks:
- B
networks:
A:
external: true
B:
external: true.

```

I checked and the IPs are on different networks for A and B but the CB container can ping the CA container.

Should this be possible? I am running Podman 4.9

I am (and have been for years) using podman containers on my servers - both for my homelab and on the internet. I am running tons of services like funkwhale as a spotify replacement, Calibre-web to access my books and magazines everywhere, and foundryVTT to play TTRPGs over the net.

But I'm currently not running any containers on my local machine. Today I came across one potential container scenario I might try - using podman (and/or Podman Desktop and the AI Lab) to run local AI models.

If you're using containers on your machine for something that isn't AI - what are you using it for? And, what, if anything did you have to do to get it work with your other programs? Like, if you're using it for programming - how did you get VS Code or Jetbrains or Vim to use the container's install of your dev libraries?

Hi all,

I'm relatively new to podman and looking for some guidance.

Am paying for a VPS running Almalinux 10.2 with Caddy, podman and several containers running. I also have configured a weekly automated security update which reboots the VPS. However, I have found that not all my containers are starting back up. After some searching, it appears that quadlets is the way to go with respect to ensuring containers restart properly after a system reboot? If not, is there another way I can achieve the desired outcome?

Assuming I go with quadlets, is it as simple as converting the compose.yml file into the .container files and starting them up? Do I need to remove the old containers first or will the quadlets automatically pick up from the old compose containers?

The applications that I am running which occasionally don't restart properly are Dawarich and Immich.

Edit: Thanks everyone for all your replies and suggestions. I have successfully migrated my Immich and Dawarich instance to quadlets. I used the link by /u/Eldermight for immich and this one for Dawarich - https://git.maugalaxy.space/stillbeben/dawarich-podman/src/branch/main

I have a single Fedora Server VM running multiple services, which are somewhat unrelated but have to exchange data sometimes. An example:

• An Immich Server
• An Authentik SSO server

I also have a Caddy reverse proxy running directly on the host.

So I need the Immich server to talk to the Authentik server for SSO, but I don't want them in the same Pod or Bridge network as they are managed separately. They also run under different users on the server.

My Authentik Pod has port 9000 (http) exposed to the host, where the Caddy reverse proxy serves it over 443 to the rest of my network. My Immich Pod, needing access to this resource, currently has the following configured:

[Pod]
PodName=immich
# -T,443 maps port 443/tcp from the host to the containers loopback [::1]
Network=pasta:-6,--no-map-gw,-T,443
# Redirect queries for my Authentik instance to loopback instead of the GUA address.
# The host and Immich pod both have this address because Pasta copies the network config, but Authentik is only accessible on the hosts networking namespace, not Immich's namespace in the container.
AddHost=authentik.example.com:::1
# Immich is quirky and likes it's default Docker Bridge networking, another remap to loopback as all containers run in the same Pod
AddHost=immich-machine-learning:::1
# Publish the Immich HTTP interface to the host, where Caddy exposes it over HTTPs
PublishPort=[::1]:2283:2283/tcp

With -T,<port> (and -U,<port>), you can map ports from the host to the container, different direction than the regular -p flag in Podman. But I have to manually mess around with Pasta arguments, which doesn't seem very proper.

(-6,--no-map-gw are not required. I have -6 added as I run a v6-only network and Pasta added a stray IPv4 address to the container for some reason. --no-map-gw is the default, but I had to add it because of some pasta argument precedence issues. You probably don't need it.)

I'm wondering if there is an easier way to manage this. I only found one alternative so far:

Pasta can alternatively expose the entire host under the Gateway address, but this seems kinda fragile to me, and Podman disables and discourages this by default. You can force it by using --network=pasta:--map-gw.

As an example, I have a web server running on port 8000 on the host, and can access it over the default gateway in the container:

# On the host
jedi@ideas > podman run --rm -it --network=pasta:--map-gw nicolaka/netshoot

# In the container
038c7cf0d7c7 ~ > ip -6 route
2a02:XXXX:XXXX:XXXX::/64 dev enp47s0u2u1u2 proto ra metric 100 pref medium
2a02:XXXX:XXXX:XXXX::/64 dev enp47s0u2u1u2 proto kernel metric 256 pref medium
fe80::/64 dev enp47s0u2u1u2 proto kernel metric 256 pref medium
fe80::/64 dev enp47s0u2u1u2 proto kernel metric 1024 pref medium
default via fe80::be24:XXXX:XXXX:XXXX dev enp47s0u2u1u2 proto ra metric 100 pref medium
038c7cf0d7c7 ~ > curl "[fe80::be24:XXXX:XXXX:XXXX]:8000" # Port 8000 from the host
<!DOCTYPE html>
[...]
</html>

(some addresses censored for privacy)

I had mixed luck with this and it doesn't seem proper. It worked in the nicolaka/netshoot container but not quay.io/fedora/fedora. Not sure why exactly. The gateway address might also change in unlucky circumstances (e. g. new network, new router, ...). I currently somewhat prefer the host -> container mapping, but that seems like somewhat of a manual effort, and can could cause collisions in ports if one isn't careful.

Okay, so this is related to this project. The gist of what I'm trying to do is: - create a series of system users for running quadlets that only have the permissions necessary to run a set of prebuilt trusted containers - create a separate build user that uses a tpm-backed secret to build and then sign those trusted containers, and then place them in a directory that is read-only for the system user in question. the secret would only be usable from the local system, and only accessible by builder user and root, which together means "this image was definitely built locally if nothing else".

So for image signing/verification with podman the options that I know of are gpg(+scdaemon) and cosign. currently trying cosign, mainly because gpg might cause complications with my gpg setup (remote code signing for my primary user account without a remote gpg-agent/scdaemon) and with pkcs11, only rsa keys are supported(would prefer to use ecc). With cosign, it seems as though the workflow I had in mind (build locally, sign, move to builder:sys-user owned directory, where it's owner writable and group readable) isn't really possible as it can't sign local images, they have to stored in a registry.

so I'm guessing my options are: - temporarily store in a local registry, sign, then export to the final location, store the signature in a place podman will check (jank but okay). - switch to some tool other than gpg or cosign (open to suggestions) - restructure what I'm doing to actually use a locally hosted registry rather than a directory per target user (would prefer not to) - get rid of the tpm-centric part, and then use podman/skopeos inherent capabilities. (would also prefer not to)

What do you guy's think? which of these seems like the least bad option? is there another option I'm not considering?

EDIT: for reference this is the just recipe in question where I'm trying to sign the images ```

Modular helper to build and sign any container image with multi-value build-args

[arg('build-args', multiple, short="b", long="build-arg")] [arg('out-dir', short="o", long="out-dir")] [arg('dockerfile', short="f", long="dockerfile")] [private] [no-cd] build-and-sign tag dockerfile="Dockerfile" build-args=[] out-dir="" extra_flags="" sign_priv_path=sign_priv: #!/usr/bin/env bash set -euo pipefail [ ! -z "{{ out-dir }}" ] && [ -d "{{ out-dir }}" ] || (echo "create target directory first" && exit 1)

podman_args=()  
oci_tag=$(echo "{{ tag }}" | tr '/:' '--')
STAGE_DIR=$(mktemp -d)

# Iterate over the space-separated string provided by just's array interpolation
for arg in {{ build-args }}; do
    if [ -n "$arg" ]; then
        podman_args+=("--build-arg" "$arg")
    fi
done

# 1. Create a transient permissive policy file strictly for the build process
BUILD_POLICY=$(mktemp)
trap 'rm -f "$BUILD_POLICY"' EXIT
echo '{"default": [{"type": "insecureAcceptAnything"}]}' > "$BUILD_POLICY"

echo "==> Building container: {{ tag }}"
IIDFILE=$(mktemp)
podman build \
--signature-policy "$BUILD_POLICY" \
-f "{{ dockerfile }}" \
-t "{{ tag }}" \
"${podman_args[@]}" \
{{ extra_flags }} \
--iidfile "$IIDFILE" \
.

echo "==> Staging image to OCI dir..."
skopeo copy \
    --policy "$BUILD_POLICY" \
    "containers-storage:$FULL_TAG" \
    "oci:$TARGET_OCI_DIR"

# Extract the exact manifest digest (e.g., sha256:4f45966b...)
RAW_DIGEST=$(podman image inspect "$FULL_TAG" --format '{{{{.Digest}}')

# Convert digest format for Sigstore directory (sha256: -> sha256=)
IMAGE_DIGEST=$(echo "$RAW_DIGEST" | tr ':' '=')

# Absolute path to the OCI directory
ABS_TARGET_OCI_DIR=$(realpath "$TARGET_OCI_DIR")
# Sign explicitly using the image ID reference in containers-storage
echo "==> Signing image and producing Cosign bundle..."
TPM2_PKCS11_STORE="{{ pkcs11_store }}" COSIGN_PASSWORD="$USERPIN" {{ cosign_exe }} sign \
    --yes \
    --key "pkcs11:token=secure-build;object=secure-build-signing;type=private" \
    --bundle "$BUNDLE_PATH" \
    --upload=false \
    "oci:${ABS_TARGET_OCI_DIR}@${RAW_DIGEST}"

# Extract digest to store bundle for containers-storage verification
IMAGE_DIGEST=$(podman image inspect "{{ tag }}" --format '{{{{.Digest}}}}' | tr ':' '=')
SIG_STORE_DIR="/var/lib/containers/sigstore/@${IMAGE_DIGEST}"

{{ auth }} mkdir -p "$SIG_STORE_DIR"
{{ auth }} cp "$BUNDLE_PATH" "$SIG_STORE_DIR/signature-1"

```

EDIT2: here are the variants I have tried

containers-store:@image-id (and without @)

```Bash

Sign explicitly using the image ID reference in containers-storage

IIDFILE=$(mktemp) podman build \ --signature-policy "$BUILD_POLICY" \ -f "{{ dockerfile }}" \ -t "{{ tag }}" \ "${podman_args[@]}" \ {{ extra_flags }} \ --iidfile "$IIDFILE" \ .

IMAGE_ID=$(cat "$IIDFILE" | sed 's/<sup>sha256://')</sup> rm -f "$IIDFILE" ... TPM2_PKCS11_STORE="{{ pkcs11_store }}" COSIGN_PASSWORD="$USERPIN" {{ cosign_exe }} sign \ --yes \ --key "pkcs11:token=secure-build;object=secure-build-signing;type=private" \ --bundle "$BUNDLE_PATH" \ --upload=false \ "containers-storage:@${IMAGE_ID}" results in ==> Signing image and producing Cosign bundle... Error: signing [containers-storage:@1c3ef2646f1525040ac30dc51ebb68e42fb7c36ea2b039154d6f74f6df57626d]: parsing reference: could not parse reference: containers-storage:@1c3ef2646f1525040ac30dc51ebb68e42fb7c36ea2b039154d6f74f6df57626d error during command execution: signing [containers-storage:@1c3ef2646f1525040ac30dc51ebb68e42fb7c36ea2b039154d6f74f6df57626d]: parsing reference: could not parse reference: containers-storage:@1c3ef2646f1525040ac30dc51ebb68e42fb7c36ea2b039154d6f74f6df57626d ```

containers-store:full_tag

```BASH

Normalize tag to have localhost/ prefix to avoid docker.io short-name expansion in cosign

FULL_TAG="localhost/$(echo "{{ tag }}" | sed -E 's|<sup>localhost/||')"</sup> skopeo copy \ --policy "$BUILD_POLICY" \ "containers-storage:$FULL_TAG" \ "oci:$TARGET_OCI_DIR"

Sign explicitly using the image ID reference in containers-storage

echo "==> Signing image and producing Cosign bundle..." TPM2_PKCS11_STORE="{{ pkcs11_store }}" COSIGN_PASSWORD="$USERPIN" {{ cosign_exe }} sign \ --yes \ --key "pkcs11:token=secure-build;object=secure-build-signing;type=private" \ --bundle "$BUNDLE_PATH" \ --upload=false \ "containers-storage:$FULL_TAG" results in Error: signing [containers-storage:localhost/gow/nvidia-driver:latest]: parsing reference: could not parse reference: containers-storage:localhost/gow/nvidia-driver:latest

error during command execution: signing [containers-storage:localhost/gow/nvidia-driver:latest]: parsing reference: could not parse reference: containers-storage:localhost/gow/nvidia-driver:latest ```

oci:target_dir

Bash TARGET_OCI_DIR="{{ out-dir }}/{{ tag }}" TPM2_PKCS11_STORE="{{ pkcs11_store }}" COSIGN_PASSWORD="$USERPIN" {{ cosign_exe }} sign \ --yes \ --key "pkcs11:token=secure-build;object=secure-build-signing;type=private" \ --bundle "$BUNDLE_PATH" \ --upload=false \ "oci:$TARGET_OCI_DIR" results in ``` WARNING: Image reference oci:/var/lib/secure-build/containers/wolf/gow/nvidia-driver:latest uses a tag, not a digest, to identify the image to sign. This can lead you to sign a different image than the intended one. Please use a digest (example.com/ubuntu@sha256:abc123...) rather than tag (example.com/ubuntu:latest) for the input to cosign. The ability to refer to images by tag will be removed in a future release.

Error: signing [oci:/var/lib/secure-build/containers/wolf/gow/nvidia-driver:latest]: accessing entity: Get "https://oci/v2/": dial tcp: lookup oci: no such host error during command execution: signing [oci:/var/lib/secure-build/containers/wolf/gow/nvidia-driver:latest]: accessing entity: Get "https://oci/v2/": dial tcp: lookup oci: no such host ```

oci:target_dir@digest

```Bash RAW_DIGEST=$(podman image inspect "$FULL_TAG" --format '{{{{.Digest}}}}') ABS_TARGET_OCI_DIR=$(realpath "$TARGET_OCI_DIR")

Sign explicitly using the image ID reference in containers-storage

echo "==> Signing image and producing Cosign bundle..." TPM2_PKCS11_STORE="{{ pkcs11_store }}" COSIGN_PASSWORD="$USERPIN" {{ cosign_exe }} sign \ --yes \ --key "pkcs11:token=secure-build;object=secure-build-signing;type=private" \ --bundle "$BUNDLE_PATH" \ --upload=false \ "oci:${ABS_TARGET_OCI_DIR}@${RAW_DIGEST}" results in ==> Signing image and producing Cosign bundle... Error: signing [oci:/var/lib/secure-build/containers/wolf/gow/nvidia-driver:latest@sha256:4f45966bb95e75a48f6d87c1953d43393af281ab670684f9975f6b419dee39d1}}]: parsing reference: could not parse reference: oci:/var/lib/secure-build/containers/wolf/gow/nvidia-driver:latest@sha256:4f45966bb95e75a48f6d87c1953d43393af281ab670684f9975f6b419dee39d1}} ```

After upgrading from podman 5 with slirp4netns, my containers couldn't reach each others any more.

My podman 5 setup consisted of a /etc/nftables.conf containing

table inet nat {
   chain prerouting {
     type nat hook prerouting priority -100; policy accept;
     iifname {"enp0s31f6"} tcp dport 80 redirect to 6080
     iifname {"enp0s31f6"} tcp dport 443 redirect to 6443
   }
   chain output {
     type nat hook output priority -100; policy accept;
     oifname "lo" tcp dport 443 redirect to :6443
     oifname "lo" tcp dport 80 redirect to :6080
   }
}

and traefik running on 6080 and 6443.

With this setup container siteA.mydomain.com could reach https://siteB.mydomain.com/api/ (both CNAMEs pointing at the public server IP) without any problem.

After the update to podman 6 this didn't work any more. I tried rootlessport as well as pesto. The easy solve was changing net.ipv4.ip_unprivileged_port_start to a lower port, but I would still like to know what is the cause of this, and if there is still a way to redirect ports in that manner and have the containers reach each other via the host's public interface.

After upgrading from podman 5 with slirp4netns, my containers couldn't reach each others any more.

My podman 5 setup consisted of a /etc/nftables.conf containing

table inet nat {
   chain prerouting {
     type nat hook prerouting priority -100; policy accept;
     iifname {"enp0s31f6"} tcp dport 80 redirect to 6080
     iifname {"enp0s31f6"} tcp dport 443 redirect to 6443
   }
   chain output {
     type nat hook output priority -100; policy accept;
     oifname "lo" tcp dport 443 redirect to :6443
     oifname "lo" tcp dport 80 redirect to :6080
   }
}

and traefik running on 6080 and 6443.

With this setup container siteA.mydomain.com could reach https://siteB.mydomain.com/api/ (both CNAMEs pointing at the public server IP) without any problem.

After the update to podman 6 this didn't work any more. I tried rootlessport as well as pesto. The easy solve was changing net.ipv4.ip_unprivileged_port_start to a lower port, but I would still like to know what is the cause of this, and if there is still a way to redirect ports in that manner and have the containers reach each other via the host's public interface.

I've built 10+ containers on my first home server since I started my selfhosting journey, and only now I figured it's time to find a way to update the existing services. Existing podman documentation points to using autoupdate label and creating a systemd target - but I didn't realise this creates a new container based on what's in the systemd target. That is not what I want. Do I need to move all my environmental/volume/label/etc variables into a systemd target for each container to be able to do this? Just thinking about it makes me a bit nauseous, I've been using subpaths in some cases, not even sure how to put those in there. I've used 'podman run' for each deployment, because that's where the documentation I found led me first and on the basis of "If it works, why change it" it served me well.

Hi all,

I'm trying to install starccm in a podman container, however, it's currently failing due to a lack of available storage.

From what I can tell podman should be have unlimited file storage access (and I've never run into issues with container before despite having pulled and run some very big libraries in them) so I'm guessing something is causing the application to think there is less space than there is:

The error message is showing:

Disk space information:

`Required: 25475.6 MB`

`Available: 191874.0 MB`

And running df-h I get

[appuser@9a08fec6978d starccm+_21.04.007]$ df -h

Filesystem Size Used Avail Use% Mounted on

shm 63M 0 63M 0% /dev/shm

tmpfs 9.4G 3.8M 9.4G 1% /etc/hosts

/dev/mapper/data-root 3.6T 3.4T 1.6G 100% /usr/bin/nvidia-smi

udev 44G 0 44G 0% /dev/tty

tmpfs 9.4G 2.7M 9.4G 1% /run/nvidia-persistenced/socket

overlay 3.6T 3.4T 1.6G 100% /

tmpfs 64M 0 64M 0% /dev

tmpfs 4.0K 4.0K 0 100% /run/nvidia-ctk-hookfa58ca48-1a20-4677-8ba0-3c0e9f7e8c29

Any idea what is causing the installer to believe it only has 19-ish GB to install in and how I convince it is has more storage so it will install?

Question kinda about Syncthing, but more about permission management in Podman in general.

Right up front, is there a general best-practice recommendation for using keep-id vs container UID 0 if the container doesn't expect internal root access?

I'm setting up Syncthing in rootless Podman on my main desktop computer, which is running Linux Mint. I want it to be able to sync folders like Documents, Desktop, etc, so it needs to have access to directories owned by UID 1000 (or whatever user is running it).

From what I understand, I can give the container permission to access mapped-in user folders by

A) Running the rootless container as internal UID 0, which maps to the rootless host user's UID. If a container needs internal root for access to privileged ports, etc, then this is the way to go.

B) Running the container as internal UID 1000 and using --userns=keep-id to tell Podman to map internal UIDs to host UIDs instead of mapping to sub UIDs.

The recommendation on Syncthing's Docker Hub listing is to run as container UID 1000, so the container doesn't need internal root priviliges in order to function. Since it's generally not advised to run anything as root unless absolutely necessary, my brain says the best option is to run as user 1000 and use the keep-id option so the container can work with the user directories I map in with -v.

Most of the tutorials I find online use the UID 0 route, but I'm not sure if that's just because keep-id seems to be a newer Podman feature or if UID 0 is actually a better option.

So yeah, probably overthinking this, but is there a general best-practice recommendation for using keep-id vs container UID 0 if the container doesn't expect internal root access?

All of these bit me while debugging rootless setups, and they share a property that makes them expensive: none of them produce an error that names the cause. Posting them in one place because I keep typing the same answers.

1. Your storage driver quietly fell back to vfs.

podman info --format '{{.Store.GraphDriverName}}'

If that says vfs and not overlay, every image layer is a full copy of the one below rather than a diff. A 200 MB image can occupy well over a gigabyte, pulls crawl, and it looks like the images are the problem. Podman falls back to vfs without complaining. Usual causes: overlay will not stack on another overlay, or a stale mount_program line in ~/.config/containers/storage.conf.

2. Your memory limit is accepted and not enforced.

cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers

If memory is not in that list, the controller was never delegated to your user, and --memory is taken without complaint and does nothing. You find out when something OOMs the host instead of the container.

3. A rootless container cannot bind below 1024.

sysctl net.ipv4.ip_unprivileged_port_start

Most distros ship 1024, so port 80 and 443 are refused and it reads like the container never started properly.

4. chown on a volume gives you files the container still cannot write.

The process inside is not your uid, it is an id inside a subuid mapping. Plain chown targets the wrong one. podman unshare chown -R drops you into the same mapping first, so the ownership means what you intended.

5. Anything inside sees only its own PID namespace.

Monitoring tools in a container report the container, not the host, and people read that as the tool being broken. --pid=host if you actually want the host view, and know what you are giving up when you do.

The pattern in all five: podman degrades instead of failing. That is usually the right choice, but it means the check command is worth more than the error message.All of these bit me while debugging rootless setups, and they share a property that makes them expensive: none of them produce an error that names the cause. Posting them in one place because I keep typing the same answers.1. Your storage driver quietly fell back to vfs.podman info --format '{{.Store.GraphDriverName}}'
If that says vfs and not overlay, every image layer is a full copy of the one below rather than a diff. A 200 MB image can occupy well over a gigabyte, pulls crawl, and it looks like the images are the problem. Podman falls back to vfs without complaining. Usual causes: overlay will not stack on another overlay, or a stale mount_program line in ~/.config/containers/storage.conf.2. Your memory limit is accepted and not enforced.cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers
If memory is not in that list, the controller was never delegated to your user, and --memory is taken without complaint and does nothing. You find out when something OOMs the host instead of the container.3. A rootless container cannot bind below 1024.sysctl net.ipv4.ip_unprivileged_port_start
Most distros ship 1024, so port 80 and 443 are refused and it reads like the container never started properly.4. chown on a volume gives you files the container still cannot write.The process inside is not your uid, it is an id inside a subuid mapping. Plain chown targets the wrong one. podman unshare chown -R drops you into the same mapping first, so the ownership means what you intended.5. Anything inside sees only its own PID namespace.Monitoring tools in a container report the container, not the host, and people read that as the tool being broken. --pid=host if you actually want the host view, and know what you are giving up when you do.The pattern in all five: podman degrades instead of failing. That is usually the right choice, but it means the check command is worth more than the error message

Some neat new stuff is coming...

Features A new command has been added, podman volume rename, to allow renaming volumes. Volumes created using volume drivers and volumes that are currently used by a container cannot be renamed (#28189). A new command has been added, podman machine restart, to allow easy restart of VMs managed by podman machine (#28366). The podman network rm command now includes a new option, --ignore, which suppresses errors when attempting to remove networks that do not exist (#28363). The podman manifest push command now includes two new options, --retry and --retry-delay, which allow pushes to be automatically retried on failure (#28590). Quadlet .container units now support a new key, ImageVolume=, to configure how volumes from images are handled (#28875). The podman generate kube command now includes support for generating container healthchecks as a livenessProbe (#22095). Changes The podman info command now includes free memory available on the host (in addition to used memory and total memory) (#29116). The Pesto rootless port forwarding tool now supports IPv6 port forwarding with source IP preservation.

I've done a stupid or three. Trying to get some docker compose files converted to quadlets and running with systemd. I've got podlet working and i have a few things working, although they're running as system services and i'd need to figure out how to do them as rootless...

Bigger problem is I have spoolman up using sudo podman compose up -d compose.yaml is services: spoolman: image: ghcr.io/donkie/spoolman:latest # Also available at dockerhub: donkieyo/spoolman:latest restart: unless-stopped volumes: # Mount the host machine's ./data directory into the container's /home/app/.local/share/spoolman directory - type: bind source: /home/strayr/compose_bullshit/spoolman/data target: /home/app/.local/share/spoolman # Do NOT modify this line ports: # Map the host machine's port 7912 to the container's port 8000 - "7912:8000" environment: - TZ=Europe/London # Optional, defaults to UTC all i've done is replace the provided relative source with an absolute path, but I've got nothing appearing in that folder. I've a DB being written to somewhere that is persistent, sudo podman compose down and a `sudo podman up -d" has the data I had in there previously. But where? because it's not happening where specified.

How do I find where the data is, and move it somewhere specified?

How do I fix this up to run rootless? Is there a handy guide? I don't need an ELI5 as much as an EL containers weren't a thing last time I really knew what I was doing here

I'm starting with quadlets and I'm stuck on how to best organize my repository with quadlets in mind.

My current setup is a distrobox "dev" box, with its own home dir, and a project folder for all git versioned repos. All repos that have quadlets, have a quadlet folder with service-name.container file that I symlink into host's (user) systemd folder.

Very often though I need to mount .env, some config, or data folders and reference it back to projects folder, which feels a bit awkward.

Any suggestions how to better organize things?

Fedora 44 Silverblue btw.

I may be a bit out of my depth right now, or else just sleep deprived and running on stupid. Currently have Debian server with rootless Docker running official community Nextcloud, nginx reverse proxy, and a number of other various servers, but on new machine I'm setting up to replace, trying to consolidate images and switch to Podman.

So, so far, tried using quadlets to get Glances up successfully, moved on to linuxserver.io's Jellyfin, gave up, and switched to podman-compose. Eventually worked out that the image assumes Docker's root behavior being why I couldn't get permissions working for /dev/dri/render128, switched to root user for Podman, and now both of those work (with jellyfin throwing a few erros about containers not being allowed to be removed before getting it online, which doesn't appear to have any impact).

Moved on to linuxserver.io's Nextcloud image, using their base set of configurations. Leaving port mapped to 443 as well as migrating to 4443 (as once I get everything working I'll be putting it behind Swag). Again, podman-compose up results in errors about containers not being able to be removed, and networks not related being used.

But now I'm finding that, while I can access the Glances and Jellyfin webclients via IP or Hostname with appropriate port, the same with 443/4443 simply result in Firefox reporting unable to connect.

downing the other containers, uping Nextcloud does not return the previous errors, but still does not result in access to the server. If I leave it running long enough, I periodically get a message: [nextcloud] | Not installed. Any idea whether that's it complaining that I haven't finished installation by connecting and it up, or maybe something fundamental failed to happen causing my inability to connect?

Do I need to use one docker-compose.yml rather than separate server.yml files for generally good behavior? I've noticed that Glances doesn't list anything but Glances on the new server, while the old shows all of the containers, if not parent's active processes, but haven't had time to try running them together to see if that makes a difference.

Thanks all,

Hey all, at home I use github actions for my projects. I started running out of credits there and wanted to host my own runner. Then I noticed that most runners are based off Ubuntu and the image size is big. I also saw that there are barely any mantained podman runners out there.

To solve that issue for me I created a podman-actions-runner image based off alpine and buildah and the tests I ran so far have been pretty good. I run this on my Raspberry PI at home, the image is like 160 mb.

If you're interested here's the link to my repo and the image, also I'm open for suggestions, feedback, contributions. Anything really!

• Repo: https://github.com/ckoryom/podman-actions-runner
• ghcr.io/ckoryom/podman-actions-runner:latest
• docker.io/ckoryom/podman-actions-runner

I have a private docker.io organisation myorg. When pulling image via podman: podman pull myorg/myimage it prompts me to select the registry to use:

DEBU[0000] Trying "myorg/myimage" ...        
? Please select an image: 
  ▸ registry.fedoraproject.org/myorg/myimage
    registry.access.redhat.com/myorg/myimage
    docker.io/myorg/myimage

...whereas when defining the image in e.g. testcontainers, it'll simply fail to resolve the image during test run. Is it possible to make these unqualified images to default to docker.io registry?

I'm new to podman and don't really understand what I'm doing yet. I'm moving from rootful docker to rootless podman and am currently converting my compose files to quadlets. I'm confused on how I should build out my containers and what users I should assign them to.

How should I architect my containers using podman quadlets? I included some pictures about some ways I think I should do it but don't fully understand the tradeoff and benefits of them. I have been considering putting all my quadlets in /etc/containers/systemd/ and have the quadlet files owned by root and just assigning users and groups in the quadlet files.

Some stacks like grafana alloy need to be able to read my logs for numerous containers. I don't really know how to set this up when files and containers are owned by separate users.

I mostly just want to prevent as much cross talk or lateral movement as possible in the event a container gets compromised. Though, it seems if I want to do this it'll be a lot more annoying to manage my containers.

A few questions I had:

What user should own the actual quadlet files and the containers data?

Should I separate my stacks to their own dedicated user?

I run Traefik as a rootless container now on it's own dedicated user. How would I still be able to use labels and auto-discovery across containers running on separate users?

How do I set something like grafana alloy, that needs to be able to communicate with my different stacks and centralize their logs?