Troubleshooting practice questions

A security engineer is troubleshooting why signature verification fails when pulling an image from a trusted registry. The policy file (/etc/containers/policy.json) specifies 'signedBy' using a GPG key, but the transport uses 'dir://'. Where must the public GPG key be imported for Podman to successfully verify the signature?

Trap 1: Into ~/.config/containers/policy.d/keys/

Podman reads signature verification keys from the GPG keyring configured in policy.json, not from a policy.d keys directory, which is not a recognised lookup path. A per-user policy.d location is tempting because policy.json itself lives under /etc/containers, suggesting sibling directories hold related configuration.

Trap 2: Into /etc/containers/certs.d/keys/

/etc/containers/certs.d/ holds registry TLS certificate authorities for transport trust, not GPG keys for image signature verification. It is tempting because both directories sit under /etc/containers and both concern trusting a registry, but certs.d governs TLS, not signedBy.

Trap 3: Into /var/lib/containers/sigstore/

/var/lib/containers/sigstore/ stores signature and identity data for sigstore-based verification, not the GPG public keys referenced by signedBy. It is tempting because sigstore is a genuine container-signing mechanism, and would be the correct location when policy.json uses sigstore rather than GPG signedBy.

A
Into the local GnuPG keyring using 'gpg --import'
For dir:// transports, Podman verifies signatures against keys in the local GnuPG keyring, so the public key must be imported there with gpg --import. Registry-scoped key files or policy entries alone do not satisfy verification for a directory transport.
B
Into ~/.config/containers/policy.d/keys/
Why it fails: Podman reads signature verification keys from the GPG keyring configured in policy.json, not from a policy.d keys directory, which is not a recognised lookup path. A per-user policy.d location is tempting because policy.json itself lives under /etc/containers, suggesting sibling directories hold related configuration.
C
Into /etc/containers/certs.d/keys/
Why it fails: /etc/containers/certs.d/ holds registry TLS certificate authorities for transport trust, not GPG keys for image signature verification. It is tempting because both directories sit under /etc/containers and both concern trusting a registry, but certs.d governs TLS, not signedBy.
D
Into /var/lib/containers/sigstore/
Why it fails: /var/lib/containers/sigstore/ stores signature and identity data for sigstore-based verification, not the GPG public keys referenced by signedBy. It is tempting because sigstore is a genuine container-signing mechanism, and would be the correct location when policy.json uses sigstore rather than GPG signedBy.

Question 2hardmultiple choice

An administrator is troubleshooting a container that fails its health check repeatedly. The container definition needs a health check that runs curl -f http://localhost/ || exit 1 every 30s, with a 5s timeout and 3 retries, starting after a 10s grace period. Which flag combination implements this correctly in podman run?

Trap 1: podman run --healthcheck="curl -f http://localhost/" --interval=30…

--healthcheck and --interval are not podman run flags; podman uses --health-cmd, --health-interval, --health-timeout, --health-retries and --health-start-period. It is tempting because the values match the stem, and this style would be correct for Docker Compose healthcheck keys rather than podman CLI flags.

Trap 2: podman run --health-probe="curl -f http://localhost/"…

--health-probe is not a podman run flag, and the command omits the || exit 1 exit-status logic plus the timeout and retries settings the stem requires. It is tempting because it names a health check, and it would suit a runtime where a single probe command with defaults is acceptable.

Trap 3: podman run --check-command="curl -f http://localhost/"…

--check-command and --check-period are not podman run options, so the health check never registers with the required interval, timeout or retries. It is tempting because the flag names sound like health-check configuration, and such syntax would be correct in a different orchestrator's manifest format.

A
podman run --healthcheck="curl -f http://localhost/" --interval=30 --timeout=5 --retries=3 webapp
Why it fails: --healthcheck and --interval are not podman run flags; podman uses --health-cmd, --health-interval, --health-timeout, --health-retries and --health-start-period. It is tempting because the values match the stem, and this style would be correct for Docker Compose healthcheck keys rather than podman CLI flags.
B
podman run --health-probe="curl -f http://localhost/" --health-delay=10s webapp
Why it fails: --health-probe is not a podman run flag, and the command omits the || exit 1 exit-status logic plus the timeout and retries settings the stem requires. It is tempting because it names a health check, and it would suit a runtime where a single probe command with defaults is acceptable.
C
podman run --health-cmd="curl -f http://localhost/ || exit 1" --health-interval=30s --health-timeout=5s --health-retries=3 --health-start-period=10s webapp
The `--health-start-period=10s` flag supplies the grace period before failures count, while `--health-interval=30s`, `--health-timeout=5s` and `--health-retries=3` map exactly to the stem's cadence, timeout and retry constraints. `--health-cmd` carries the curl command verbatim, so podman's health check matches the specified definition precisely.
D
podman run --check-command="curl -f http://localhost/" --check-period=30s webapp
Why it fails: --check-command and --check-period are not podman run options, so the health check never registers with the required interval, timeout or retries. It is tempting because the flag names sound like health-check configuration, and such syntax would be correct in a different orchestrator's manifest format.

Question 3hardmulti select

An administrator is troubleshooting container exit codes and low-level state details. Which TWO of the following inspect format expressions correctly extract container state attributes? (Choose TWO)

Trap 1: podman inspect --format='{{.Metadata.ExitCode}}' container_name

ExitCode sits under the top-level State object, not Metadata, so this path resolves to nothing and prints blank output. It is tempting because Metadata does exist in the inspect output and holds container creation details, but the exit code is a runtime state attribute reached via {{.State.ExitCode}}.

Trap 2: podman inspect --format='{{.Status.Running}}' container_name

Running is a boolean under State, not Status, so this expression yields no value and cannot report whether the container is active. It is tempting because Status appears in inspect output for other container runtimes, but Podman nests runtime state under State; the working form is {{.State.Running}}.

Trap 3: podman inspect --format='{{.Exit}}' container_name

The inspect JSON exposes the exit code under State.ExitCode, so .Exit matches no field and returns an empty result. It is tempting because the name reads naturally and the surrounding syntax is valid Go templating, but the correct expression for this attribute is {{.State.ExitCode}}.

A
podman inspect --format='{{.Metadata.ExitCode}}' container_name
Why it fails: ExitCode sits under the top-level State object, not Metadata, so this path resolves to nothing and prints blank output. It is tempting because Metadata does exist in the inspect output and holds container creation details, but the exit code is a runtime state attribute reached via {{.State.ExitCode}}.
B
podman inspect --format='{{.State.StartedAt}}' container_name
The template {{.State.StartedAt}} extracts the timestamp recording when the container last started, a low-level state attribute held in the inspect JSON's State object. This satisfies the requirement to pull container state details via a format expression.
C
podman inspect --format='{{.Status.Running}}' container_name
Why it fails: Running is a boolean under State, not Status, so this expression yields no value and cannot report whether the container is active. It is tempting because Status appears in inspect output for other container runtimes, but Podman nests runtime state under State; the working form is {{.State.Running}}.
D
podman inspect --format='{{.Exit}}' container_name
Why it fails: The inspect JSON exposes the exit code under State.ExitCode, so .Exit matches no field and returns an empty result. It is tempting because the name reads naturally and the surrounding syntax is valid Go templating, but the correct expression for this attribute is {{.State.ExitCode}}.
E
podman inspect --format='{{.State.ExitCode}}' container_name
The Go template expression {{.State.ExitCode}} reads the container's exit code integer from the inspect JSON, which is precisely the low-level state attribute needed to diagnose why a container terminated. Podman exposes this field under the State object.

Question 4hardmultiple choice

An administrator is troubleshooting container exit codes. A container exited with code 137. What does this specific exit code typically signify in container engines?

Trap 1: The container executed an invalid system call blocked by seccomp.

A seccomp-blocked syscall usually returns EPERM to the process, causing an application-level error rather than SIGKILL; 137 specifically denotes termination by signal 9. Seccomp filtering is relevant when hardening containers against specific syscalls, not for diagnosing memory-driven kills.

Trap 2: The container encountered an application-level syntax error.

Application syntax errors surface as non-zero exit codes from the interpreter itself, commonly 1 or 2, not 137. Code 137 reflects SIGKILL (128+9), so it indicates external termination such as memory exhaustion, not a fault within the application's own parsing.

Trap 3: The container startup script had a permission denied error.

Exit code 137 means the process was terminated by SIGKILL, typically the OOM killer or a docker stop timeout, not a permission failure. Permission denied produces exit code 126 or 127, so this option confuses an authorisation error with a signal-based termination.

A
The container was terminated forcefully by SIGKILL (often due to Out-Of-Memory).
Exit code 137 equals 128 plus signal 9, meaning the container received SIGKILL. The kernel's OOM killer commonly sends SIGKILL when a container exceeds its memory cgroup limit, so the process is terminated forcefully without cleanup.
B
The container executed an invalid system call blocked by seccomp.
Why it fails: A seccomp-blocked syscall usually returns EPERM to the process, causing an application-level error rather than SIGKILL; 137 specifically denotes termination by signal 9. Seccomp filtering is relevant when hardening containers against specific syscalls, not for diagnosing memory-driven kills.
C
The container encountered an application-level syntax error.
Why it fails: Application syntax errors surface as non-zero exit codes from the interpreter itself, commonly 1 or 2, not 137. Code 137 reflects SIGKILL (128+9), so it indicates external termination such as memory exhaustion, not a fault within the application's own parsing.
D
The container startup script had a permission denied error.
Why it fails: Exit code 137 means the process was terminated by SIGKILL, typically the OOM killer or a docker stop timeout, not a permission failure. Permission denied produces exit code 126 or 127, so this option confuses an authorisation error with a signal-based termination.

Question 5easymulti select

An administrator needs to view logs or attach to a running container to troubleshoot an issue. Which TWO commands can be used to interact with container output streams? (Choose TWO)

Trap 1: podman stream

podman stream does not exist as a Podman subcommand, so it cannot attach to or read container output streams. The name suggests live output, but attaching to a running container's streams is done with podman attach, and log retrieval with podman logs.

Trap 2: podman view-logs

podman view-logs is not a valid Podman subcommand, so it cannot retrieve container output. The plausible-sounding name mimics logging tools, yet the real command is podman logs, which reads the container's captured stdout and stderr.

Trap 3: podman output

podman output is not a Podman subcommand; no such command exists in the CLI. It is tempting because the name suggests retrieving container output, but the actual commands are podman logs for captured stdout/stderr and podman attach for live streams.

A
podman stream
Why it fails: podman stream does not exist as a Podman subcommand, so it cannot attach to or read container output streams. The name suggests live output, but attaching to a running container's streams is done with podman attach, and log retrieval with podman logs.
B
podman view-logs
Why it fails: podman view-logs is not a valid Podman subcommand, so it cannot retrieve container output. The plausible-sounding name mimics logging tools, yet the real command is podman logs, which reads the container's captured stdout and stderr.
C
podman attach
podman attach connects the terminal directly to a running container's standard input, output and error streams, letting the administrator watch live output and interact with the process. This satisfies the requirement to interact with container output streams for troubleshooting.
D
podman output
Why it fails: podman output is not a Podman subcommand; no such command exists in the CLI. It is tempting because the name suggests retrieving container output, but the actual commands are podman logs for captured stdout/stderr and podman attach for live streams.
E
podman logs
Reading a container's stdout/stderr without entering it, podman logs satisfies the requirement to view output streams for troubleshooting. Unlike podman attach, which connects to the running process's streams, logs replays captured output, letting the administrator inspect historical entries even after the container has restarted.

Question 6mediummulti select

An administrator is troubleshooting a misbehaving container and needs to examine its output logs and event history. Which TWO commands are appropriate for this task? (Choose TWO)

Trap 1: podman inspect-logs

`podman inspect-logs` is not a real Podman subcommand, so it cannot retrieve container output or events. It is tempting because `podman inspect` genuinely returns container metadata, and `podman logs` streams stdout/stderr, so the name looks like a plausible blend. `podman logs` and `podman events` are the actual commands required here.

Trap 2: podman history

podman history displays image layer build history, not a running container's output or events. It is tempting because it inspects container-related artefacts, and would be correct when auditing how an image was constructed from its Dockerfile instructions.

Trap 3: podman trace

podman trace records and displays system-call activity for a running process, not container stdout logs or lifecycle events. It is tempting because tracing sounds diagnostic, but examining output logs and event history requires podman logs and podman events, which read those specific sources.

A
podman inspect-logs
Why it fails: `podman inspect-logs` is not a real Podman subcommand, so it cannot retrieve container output or events. It is tempting because `podman inspect` genuinely returns container metadata, and `podman logs` streams stdout/stderr, so the name looks like a plausible blend. `podman logs` and `podman events` are the actual commands required here.
B
podman logs
podman logs retrieves a container's captured stdout and stderr, satisfying the stem's requirement to examine output logs. It reads the container's logging driver output, unlike podman events, which reports lifecycle actions rather than application output.
C
podman events
`podman events` streams real-time container lifecycle events — start, stop, die, health-status changes — with timestamps, satisfying the requirement to examine event history. It complements log inspection by revealing state transitions rather than stdout/stderr output, which is precisely the second capability the scenario demands.
D
podman history
Why it fails: podman history displays image layer build history, not a running container's output or events. It is tempting because it inspects container-related artefacts, and would be correct when auditing how an image was constructed from its Dockerfile instructions.
E
podman trace
Why it fails: podman trace records and displays system-call activity for a running process, not container stdout logs or lifecycle events. It is tempting because tracing sounds diagnostic, but examining output logs and event history requires podman logs and podman events, which read those specific sources.

Question 7easymultiple choice

You are troubleshooting a container that should have no network access whatsoever for security isolation. Which networking option should you apply?

Trap 1: --network isolated

Docker has no 'isolated' network driver; the value is rejected or falls back, so the container still gains connectivity. A driver of this name would be correct if Docker shipped such a mode, but none exists, so the container must join the none network instead.

Trap 2: --network bridge

The bridge driver attaches the container to Docker's default bridge network, giving it outbound connectivity and an IP address, so isolation fails. Bridge networking is correct when containers need to communicate with each other or reach external networks on a single host.

Trap 3: --network host

Host networking places the container directly in the host's network namespace, giving it full access to every host interface and port — the opposite of isolation. It is tempting because it removes NAT overhead and suits performance-sensitive workloads needing host-level throughput, but it cannot satisfy a no-network requirement.

A
--network isolated
Why it fails: Docker has no 'isolated' network driver; the value is rejected or falls back, so the container still gains connectivity. A driver of this name would be correct if Docker shipped such a mode, but none exists, so the container must join the none network instead.
B
--network bridge
Why it fails: The bridge driver attaches the container to Docker's default bridge network, giving it outbound connectivity and an IP address, so isolation fails. Bridge networking is correct when containers need to communicate with each other or reach external networks on a single host.
C
--network host
Why it fails: Host networking places the container directly in the host's network namespace, giving it full access to every host interface and port — the opposite of isolation. It is tempting because it removes NAT overhead and suits performance-sensitive workloads needing host-level throughput, but it cannot satisfy a no-network requirement.
D
--network none
The --network none option attaches the container to no network namespace at all, leaving only a loopback interface. This enforces complete isolation, satisfying the requirement for zero network access, unlike bridge or host modes which still permit connectivity.

Question 8hardmulti select

An administrator is troubleshooting process execution and live configuration updates on a running container. Which TWO commands allow interacting with processes or updating resource limits on the fly? (Choose TWO)

Trap 1: podman exec-top

podman exec-top is invalid.

Trap 2: podman adjust

podman adjust does not exist.

Trap 3: podman modify

podman modify is not a valid subcommand.

A
podman exec-top
Why it fails: podman exec-top is invalid.
B
podman adjust
Why it fails: podman adjust does not exist.
C
podman update
podman update modifies container resource limits like CPU shares on a running container.
D
podman modify
Why it fails: podman modify is not a valid subcommand.
E
podman top
podman top displays the running processes inside a container.

Question 9hardmultiple choice

An administrator is troubleshooting a rootless Podman container named payment_svc that fails to start with a permission-related error. The administrator wants to inspect the container's low-level configuration, including its mount points, namespace settings, and the exact command that was configured, without starting the container. Which command provides this information?

Trap 1: podman logs payment_svc

podman logs displays the standard output and standard error captured from the container's main process. Since payment_svc fails to start and never runs, there is little or no log output, and logs do not expose mount points, namespace configuration, or the configured command. It cannot provide the low-level inspection data required.

Trap 2: podman top payment_svc

podman top lists the running processes inside a container along with selected fields. It requires the container to be running, and payment_svc is not running because it fails to start. Even if it were running, top shows process information rather than configuration details like mounts or namespaces.

Trap 3: podman stats payment_svc

podman stats reports live resource usage such as CPU, memory, and network I/O for running containers. It does not reveal static configuration such as mount points, namespace settings, or the configured command, and it cannot produce meaningful output for a container that is not running. It is unrelated to inspecting configuration.

A
podman logs payment_svc
Why it fails: podman logs displays the standard output and standard error captured from the container's main process. Since payment_svc fails to start and never runs, there is little or no log output, and logs do not expose mount points, namespace configuration, or the configured command. It cannot provide the low-level inspection data required.
B
podman top payment_svc
Why it fails: podman top lists the running processes inside a container along with selected fields. It requires the container to be running, and payment_svc is not running because it fails to start. Even if it were running, top shows process information rather than configuration details like mounts or namespaces.
C
podman inspect payment_svc
podman inspect returns a detailed JSON document describing the container's configuration, including its mounts, namespaces, environment, entrypoint and command, network settings, and the stored state. It works on stopped containers, making it the correct tool to examine why a container fails before it ever starts.
D
podman stats payment_svc
Why it fails: podman stats reports live resource usage such as CPU, memory, and network I/O for running containers. It does not reveal static configuration such as mount points, namespace settings, or the configured command, and it cannot produce meaningful output for a container that is not running. It is unrelated to inspecting configuration.

Question 10hardmulti select

You are troubleshooting a Podman Compose deployment where containers on a user-defined network cannot resolve each other by service name, although they can reach each other by IP address. Which TWO conditions would explain the name resolution failure? (Choose two.)

Trap 1: Each service publishes its port to the host with 'ports:', which…

Publishing a port creates a host-side forward and does not remove or replace the DNS records for the container on its network. Containers on the same network still resolve each other by name even when ports are published. This condition would not cause name resolution to fail, so it does not explain the symptom.

Trap 2: The Compose file sets 'dns:' on each service to an external…

Overriding 'dns:' changes the resolvers used by the container, but aardvark-dns is still consulted for names on the container's attached network in typical Podman configurations. More importantly, the described symptom is a complete failure of service-name resolution on the network, which points to network attachment or the DNS service itself rather than an external resolver setting.

Trap 3: The containers are running with '--network none' but have static…

With no network attached, containers have no connectivity at all, so they could not reach each other by IP either. The scenario states IP connectivity works, which rules out this condition. Static hosts entries would also be a manual workaround rather than the cause of a DNS failure on a user-defined network.

A
Each service publishes its port to the host with 'ports:', which replaces the internal DNS records.
Why it fails: Publishing a port creates a host-side forward and does not remove or replace the DNS records for the container on its network. Containers on the same network still resolve each other by name even when ports are published. This condition would not cause name resolution to fail, so it does not explain the symptom.
B
The Compose file sets 'dns:' on each service to an external resolver that has no record of the service names.
Why it fails: Overriding 'dns:' changes the resolvers used by the container, but aardvark-dns is still consulted for names on the container's attached network in typical Podman configurations. More importantly, the described symptom is a complete failure of service-name resolution on the network, which points to network attachment or the DNS service itself rather than an external resolver setting.
C
The containers are running with '--network none' but have static /etc/hosts entries for each other.
Why it fails: With no network attached, containers have no connectivity at all, so they could not reach each other by IP either. The scenario states IP connectivity works, which rules out this condition. Static hosts entries would also be a manual workaround rather than the cause of a DNS failure on a user-defined network.
D
The containers were attached to the default bridge network instead of the Compose-created user-defined network.
Name resolution by service name is provided by aardvark-dns on user-defined networks. The default bridge network does not provide automatic service-name DNS for containers, so containers placed there can communicate by IP but cannot resolve each other's names. Ensuring the services are attached to the Compose-created network restores name resolution.
E
The aardvark-dns process responsible for answering queries on that network is not running or failed to start.
Podman relies on aardvark-dns to serve DNS records for containers on user-defined networks. If that process is stopped or crashed, containers can still reach each other by IP because the bridge forwarding works, but name lookups fail. Restarting or repairing the DNS service restores resolution without changing the container network configuration.

Question 11hardmultiple choice

An administrator is troubleshooting container startup failures and wants to inspect the exact entrypoint and command arguments configured for a container named app_run before it starts. Which inspect format expression retrieves this?

Trap 1: podman ps --format='{{.Command}}' app_run

Listing running containers shows only the command of an already-started container, and ps cannot report entrypoint plus arguments for a stopped container. It tempts because ps --format is the quick way to view a live container's command line, which would suffice if app_run were already running.

Trap 2: podman inspect --format='{{.State.Command}}' app_run

State.Command does not exist in Podman's inspect schema, so the template renders empty. It tempts because State holds runtime data such as Pid and Status, making it look like the natural place for command details, whereas Config carries Entrypoint and Cmd.

Trap 3: podman inspect --format='{{.Args}}' app_run

The .Args field holds only the command arguments, omitting the entrypoint, so it cannot reveal the full startup command. Inspecting both requires .Config.Entrypoint and .Config.Cmd. .Args is tempting because it sounds like the argument list, but it is not the container configuration field.

A
podman ps --format='{{.Command}}' app_run
Why it fails: Listing running containers shows only the command of an already-started container, and ps cannot report entrypoint plus arguments for a stopped container. It tempts because ps --format is the quick way to view a live container's command line, which would suffice if app_run were already running.
B
podman inspect --format='{{.State.Command}}' app_run
Why it fails: State.Command does not exist in Podman's inspect schema, so the template renders empty. It tempts because State holds runtime data such as Pid and Status, making it look like the natural place for command details, whereas Config carries Entrypoint and Cmd.
C
podman inspect --format='{{.Config.Entrypoint}} {{.Config.Cmd}}' app_run
The `--format` flag with Go template syntax extracts exactly the `Config.Entrypoint` and `Config.Cmd` fields from the container's image configuration, satisfying the requirement to inspect entrypoint and command arguments without starting the container. This targets the precise metadata fields rather than the full JSON output.
D
podman inspect --format='{{.Args}}' app_run
Why it fails: The .Args field holds only the command arguments, omitting the entrypoint, so it cannot reveal the full startup command. Inspecting both requires .Config.Entrypoint and .Config.Cmd. .Args is tempting because it sounds like the argument list, but it is not the container configuration field.

Question 12hardmultiple choice

An administrator is troubleshooting a rootless Podman container that fails to write to a bind-mounted host directory. The directory is owned by the user on the host, but inside the container, the process runs as UID 1000 and receives permission denied. Which action should the administrator take to resolve the issue?

Trap 1: Change the container's user to root by adding --user root to the…

In rootless mode, the root user inside the container is mapped to the host user running Podman, not to the actual host root. So even if the container runs as root, it still operates with the host user's privileges. The host directory is owned by the host user, so the container root should have access. However, if the container process runs as UID 1000, switching to root might resolve the immediate permission issue, but it is not the best practice and may not be desired. The :U option is more precise and maintains the intended user.

Trap 2: Add the :Z option to the mount to relabel the directory for SELinux.

The :Z option relabels the host directory with an SELinux context that allows container access. However, this scenario describes a permission denied error due to UID mismatch, not an SELinux denial. SELinux denials typically produce an 'Permission denied' error as well, but would be accompanied by an AVC denial in the audit log. Without evidence of SELinux, :Z does not address the ownership problem.

Trap 3: Run the container with --privileged to bypass user namespace…

The --privileged flag gives the container full access to host devices and capabilities, but it does not change the fundamental UID mapping in rootless mode. The container process would still run as UID 1000 inside the namespace, which maps to a non-privileged host UID. While --privileged can sometimes mask permission issues, it is not the correct fix and introduces significant security risks. It does not alter file ownership on the host.

A
Change the container's user to root by adding --user root to the podman run command.
Why it fails: In rootless mode, the root user inside the container is mapped to the host user running Podman, not to the actual host root. So even if the container runs as root, it still operates with the host user's privileges. The host directory is owned by the host user, so the container root should have access. However, if the container process runs as UID 1000, switching to root might resolve the immediate permission issue, but it is not the best practice and may not be desired. The :U option is more precise and maintains the intended user.
B
Add the :Z option to the mount to relabel the directory for SELinux.
Why it fails: The :Z option relabels the host directory with an SELinux context that allows container access. However, this scenario describes a permission denied error due to UID mismatch, not an SELinux denial. SELinux denials typically produce an 'Permission denied' error as well, but would be accompanied by an AVC denial in the audit log. Without evidence of SELinux, :Z does not address the ownership problem.
C
Run the container with --privileged to bypass user namespace restrictions.
Why it fails: The --privileged flag gives the container full access to host devices and capabilities, but it does not change the fundamental UID mapping in rootless mode. The container process would still run as UID 1000 inside the namespace, which maps to a non-privileged host UID. While --privileged can sometimes mask permission issues, it is not the correct fix and introduces significant security risks. It does not alter file ownership on the host.
D
Use the :U mount option to recursively change ownership of the host directory to match the container's user namespace mapping.
The :U option tells Podman to adjust the ownership of the host directory so that it matches the UID/GID mapping inside the container. In rootless mode, the container's UID 1000 corresponds to a different host UID (often in the high range) due to user namespace remapping. Using :U ensures the container process has write access by changing the host directory's ownership to the mapped UID. This is the recommended solution for permission issues with bind mounts in rootless containers.