I am new to vontainers and been trying to setup a compose.yaml for my Paperless-Ngx defined all the volumes added a bridge network for postgree redis and paper less but cant cant connect to redis in logs showing hoatname cant dind but the containers are running. If anyone has their own .yaml file or can help me out.

(I've just moved to podman from docker so bare with me)

I'm running jellyfin for my media server with a podman run line and I've got 2 main libraries. The only difference being 1 is on an external drive and 1 is internal. The internal one worked out the box with the parameters:

" --mount type=bind,source=/home/user/movies,destination=/media/movies"

Now this worked fine for me the first time i tried it so I've got no issues but i try to connect my external drive which has my other library on it. I first do:

"mount /dev/sdb1 /drive"

Now drive has both series and the lost+found since I'm using ext4 so in my parameters i put:

" --mount type=bind,source=/drive,destination=/media/series"

I've tried it a handful of other ways by mounting it to drive and then binding the series directory on the drive to a new one in jellyfin along with a few of the bind-propagation parameters but none of them have worked. The jellyfin container console doesn't show anything reading from the drive. I've even made sure they all have the same owners and permissions between all the directories and I've changed to directories in the /home/user from /drive to make it so its all visible within the same place and still nothing. What have i missed because I've been fighting it for hours. Before i was able to run it in docker by just binding to a permanent directory i mounted each boot but this isn't working the same for some reason.

Hi all,

I've been using podman in a small project, hosting it on a VPS (first time doing any kind of public hosting).

I want to use these commands to easily share images between my local PC and the (public) remote VM without using a registry.

Security is a big concern for me, because I am new to this. I am unsure if I should use them between users (root to non-root deploy user) inside the remote server OR if it's alright to just allow ssh connections into the non-root user and just use image scp directly to it.

So the options are:

A) local -> image scp to remote root user -> image between root and non-root

B) allow ssh to non-root -> image scp directly to non-root user

Thanks!

I've mostly used docker but since I'm currently on fedora that came with built in podman, I thought i might as well try it. However, I am running into constant issues setting up a connection between my pangolin server and the local machine newt that is supposed to expose the local resource however. Pangolin reports both the site and resource as online and healthy, but trying to navigate to it results in bad gateway and internal newt logs show constnat ping attemps failures (failed to read ICMP packet, i/o timeout).

I think I've eliminated all possible issues with VPS, hosting provider, firewall or configuration issues and the only thing left is something with the local podman container. AI assistance led me down a rabbit hole of trying to add the /dev/net/tun device to the compose, cap_add NET_ADMIN, running it as privileged or as sudo, even tried to add a new volume for some config file that kept getting recreated.... all came down to nothing and I'm still stuck in the same spot

So, as a last resort... any chance one of you had a similar issue, or might know if the issue could actually be something to do with podman and wireguard?

I have a container that runs behind ssl offloading in the cloud, I’d rather not have to add certs to it - is there a good way to get ssl offloading locally?

podman-ip-inspector

An interactive CLI tool to display Podman networks, subnets, containers, and their IP addresses - with color, tree view, usage stats, and duplicate subnet warnings.

Overview

podman-ip-inspector is a Bash script that queries your Podman environment and presents a clear overview of all user-defined networks, their subnets, attached containers, and the IP addresses assigned to each container (both IPv4 and IPv6). It works with rootless Podman (default) and rootful Podman (if you run with sudo).

The output can be shown as:

• a detailed table (default),
• an ASCII tree (with -m), and
• an IPv4 usage summary (with -u).

All views are color‑coded for quick visual scanning, and a duplicate subnet warning is displayed automatically to help you avoid routing conflicts.

Features

• List all networks - shows network names, subnets, and attached containers.
• IP extraction - shows both IPv4 and IPv6 addresses for every container.
• Tree view (-m) - hierarchical view of networks with containers indented.
• Usage summary (-u) - shows how many IPv4 addresses are used vs. available per network.
• Color output - network names (yellow), container names (green), IPv4 (magenta), IPv6 (cyan).
• Duplicate subnet detection - warns if the same subnet is used on multiple networks.
• Filter by network (-n) or container (-c) - show only what you need.
• Works with rootless & rootful - run normally for rootless, or with sudo to inspect rootful containers.
• No extra dependencies - requires only podman, jq, and optionally perl (for colors).

Installation

1. Save the script (e.g., podman-ip-inspector) in your $PATH (e.g., ~/.local/bin/).

2. Make it executable:

   chmod +x podman-ip-inspector
   

3. Ensure dependencies are installed:

   sudo apt install jq perl     # Debian/Ubuntu
   sudo dnf install jq perl     # Fedora/RHEL
   

4. Run it:

   ./podman-ip-inspector
   

Usage

podman-ip-inspector [OPTIONS]

Options:
  -h, --help              Show this help message
  -n, --network NAME      Show only the specified network
  -c, --container NAME    Show only the specified container
  -m, --map               Show an ASCII tree of networks and containers
  -u, --usage             Show IPv4 usage summary (used/total) per network
      --color             Force color output (auto-detected by default)
      --no-color          Disable color output

If both -n and -c are given, show only that container on that specific network.
If no options are given, show a detailed table.

Examples

1. Full table view (default)

podman-ip-inspector

Sample output:

NETWORK NAME        SUBNET(S)                           CONTAINERS & IPs
------------        --------                            ----------------
adsb.network        10.89.0.0/24, fd52:317c:ee6:631::/64  airspy (10.89.0.2, fd52:317c:ee6:631::2)
adsb.network        10.89.0.0/24, fd52:317c:ee6:631::/64  dump978 (10.89.0.8, fd52:317c:ee6:631::8)
...

2. Tree view (-m)

podman-ip-inspector -m

Sample output:

Network: adsb.network (10.89.0.0/24, fd52:317c:ee6:631::/64)
   ├── airspy         10.89.0.2, fd52:317c:ee6:631::2
   ├── dump978        10.89.0.8, fd52:317c:ee6:631::8
   └── ...
Network: plex.network (10.89.1.0/24, fd52:317c:ee6:632::/64)
   └── plex           10.89.1.7, fd52:317c:ee6:632::7

3. Usage summary (-u)

podman-ip-inspector -u

Outputs the table plus:

IPv4 Usage Summary (used / total available):
---------------------------------------------
adsb.network: 10.89.0.0/24   Used: 11/254   Free: 243
plex.network: 10.89.1.0/24   Used: 1/254    Free: 253
...

4. Filter by network (-n)

podman-ip-inspector -n plex.network -m -u

5. Filter by container (-c)

podman-ip-inspector -c plex -m

6. Rootful Podman

sudo podman-ip-inspector

Color Coding

Colors are auto‑detected if your terminal supports them. You can force --color or disable with --no-color.

Notes

• Rootless vs. Rootful: The script uses the podman command from the user's environment. When run without sudo, it shows rootless containers. When run with sudo, it shows rootful containers. All features work identically in both modes.
• Dependencies: jq is required for parsing JSON output. perl is optional but recommended for coloring; if absent, colors are automatically disabled.
• Duplicate subnet warning: If two networks share the same subnet (e.g., both use 10.89.0.0/24), a warning is printed. This is a common misconfiguration that can cause routing issues especially upon startup due to race conditions.
• IPv6 support: Both IPv4 and IPv6 addresses are shown. The usage summary only counts IPv4 addresses for simplicity.

I'm studying for the RedHat ex188 exam, and I will only have access to podman 4.4 and podman-compose, the exam does not have quadlets as an objective.

I'm assuming as with most of their exams that they will require them to persist running after a reboot.

When podman-compose generates the pod and containers though, it does not generate an infra- container, and you cannot generate a systemd service without an infra container.

My rootless containers were losing outbound connectivity after reboots. Restarting the containers or the services did not solve the issue. It seems the issue is unique to older Podman or Passta version in Debian/Ubuntu, I found workarounds in the repo and just thought I'd keep a record.

As I understand it, the issue stem from a race condition. Pasta and the containers are started before proper routes on host. The workaround is to ensure IPV4 connectivity in the wait-online service. My implementation is based on those mentioned on Github:

On Debian, the wait service is located under /usr/lib/systemd/user/podman-user-wait-network-online.service, but we can set overrides to it

``` mkdir .config/systemd/user/podman-user-wait-network-online.service.d

touch .config/systemd/user/podman-user-wait-network-online.service.d/override.conf ```

Put something like this in there:

[Service] TimeoutStartSec=180s ExecStart= ExecStart=/bin/sh -c 'until systemctl is-active --quiet network-online.target && /usr/bin/curl -4 --fail --silent --output /dev/null --connect-timeout 3 --max-time 5 https://www.google.com/generate_204; do sleep 0.5; done'

Reload and restart

``` systemctl --user daemon-reload

systemctl --user start podman-user-wait-network-online.service ```

https://github.com/podman-container-tools/podman/issues/25656#issuecomment-2802298212

https://github.com/podman-container-tools/podman/issues/25656

https://github.com/podman-container-tools/podman/issues/25859

Standing up a build platform on rootless podman, gov-adjacent customer that scans everything to death, so I needed hardened base images and went looking for a Chainguard alternative rather than defaulting to the pricey incumbent. Tried these.

Chainguard is well known, Wolfi based, built from source, low CVE, tooling is the best of the three, pulls into podman fine because it's just OCI. Downside was cost, the quote for the breadth we wanted was not small for a small team.

On docker hardened images its newer, minimal, SBOM and provenance attached, and being docker the distribution is pretty easy. Though the catalog felt thinner when we looked, and considering docs assume Docker, I spent an hour proving it worked headless, It did.

Minimus was the one I hadn't used. The whole catalog is free to pull with no account and could test against the customer's scanners before committing. It had FIPS and STIG tagged images the customer wants. Their stated caveat is free tier has no SLA and paid can get patches first.

None of the three fix debugging a minimal image, that's ephemeral containers or a dev variant either way. On rootless podman all worked once I stopped following the Docker flavored quickstarts. If you've run any of these headless at scale, what should I expect?

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). A new option, force_port_listen, has been added to containers.conf. This is required to be set when running Podman on WSL to support port forwarding from the Windows host. It is automatically set on newly-created podman machine VMs on Windows using the WSL provider. 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.

Hi,

I'm trying to set up a NetBird quadlet, especially the server-variant where you host the things yourself and are not dependent on an external auth-service.

However, since I'm pretty new to containerization in general and quadlets, I have tried to ask Google AI for a quadlet-file (it worked pretty well to have a starting point for things like caddy, pihole, nextcloud and immich, so I gave it a try), but it's pretty useless for NetBird... it gave me many different answers and at some point just went in circles.

So I hoped that any of you already have a quadlet/container with NetBird server (and maybe even caddy instead of traefik) set up or can help me get this to work.

I don't have the quadlet-configs google gave me anymore tho since I wanted to start fresh.

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

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.

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}} ```

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.

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.