Semantics of --transient-store with volumes are unclear and inconsistent

[turtleslow]

Issue Description

The volume created with podman --transient-store run --volume=named-volume:/path ... appears to persist after reboot but is not shown in the output of podman volume list or podman --transient-store volume list.

Steps to reproduce the issue

1. Run the following set of commands:

# review the volumes we already have
podman volume list
podman --transient-store volume list

# create a new named volume
podman --transient-store run --interactive --rm --volume=maybe-transient:/tmp/maybe_transient docker.io/alpine:latest /bin/sh<<EOF
set -ex
echo "i'm still here" > /tmp/maybe_transient/message.txt
cat /tmp/maybe_transient/message.txt
EOF

# the volume is listed only with the `--transient-store` option
podman volume list
podman --transient-store volume list

where the last line should return something like:

DRIVER      VOLUME NAME
local       maybe-transient

2. Reboot the machine

3. Now check the status of the volume created with --transient-store:

# the volume is not listed at all
podman volume list
podman --transient-store volume list

# but the volume can still be accessed
podman --transient-store run --interactive --rm --volume=maybe-transient:/tmp/not_transient docker.io/alpine:latest /bin/sh<<EOF
set -ex
cat /tmp/not_transient/message.txt
EOF

where the last line should return:
i'm still here

Describe the results you received

The volume created with --transient-store is still accessible after reboot but is not shown in the output of podman --transient-store volume list or podman volume list.

Describe the results you expected

After reboot, either the volume should not be accessible anymore and removed from the machine, or it should be listed in podman volume list.

podman info output

host:
  arch: amd64
  buildahVersion: 1.38.1
  cgroupControllers:
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.12-1.2.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: unknown'
  cpuUtilization:
    idlePercent: 97.83
    systemPercent: 0.66
    userPercent: 1.51
  cpus: 8
  databaseBackend: sqlite
  distribution:
    distribution: opensuse-microos
    version: "20250205"
  eventLogger: journald
  freeLocks: 2040
  hostname: DESKTOP-MD6O472
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.13.1-1-default
  linkmode: dynamic
  logDriver: journald
  memFree: 12079669248
  memTotal: 16557191168
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.13.1-1.2.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.13.1
    package: netavark-1.13.1-1.1.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.13.1
  ociRuntime:
    name: crun
    package: crun-1.19.1-1.1.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.19.1
      commit: 3e32a70c93f5aa5fea69b50256cca7fd4aa23c80
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-20250121.4f2c8e7-1.1.x86_64
    version: |
      pasta 20250121.4f2c8e7-1.1
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 8589930496
  swapTotal: 8589930496
  uptime: 0h 27m 21.00s
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.opensuse.org
  - registry.suse.com
  - docker.io
store:
  configFile: /home/{user}/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/{user}/.local/share/containers/storage
  graphRootAllocated: 137438953472
  graphRootUsed: 12688449536
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 25
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/{user}/.local/share/containers/storage/volumes
version:
  APIVersion: 5.3.2
  Built: 1737526969
  BuiltTime: Wed Jan 22 01:22:49 2025
  GitCommit: ""
  GoVersion: go1.23.4
  Os: linux
  OsArch: linux/amd64
  Version: 5.3.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

[none]

Additional information

[none]

[Luap99]

This is the expected behavior, volumes are part of the libpod db and transient store puts that db on tmpfs. Volume data however should persist and should not be deleted.

The main driver of the transient store was also a driver for quadlet. So you just have a quadlet volume definition that recreates the volume in the db after boot which uses the same volume data because nobody wants that to be deleted on each boot.

And in general one SHOULD NOT mix --transient-store with the normal podman, this setting should be used consistently and not switch between commands, mixing them between commands is not tested and supported and at least to my understanding was never intended to be used that way.

podman --transient-store run --interactive --rm --volume=maybe-transient:/tmp/not_transient docker.io/alpine:latest /bin/sh<<EOF

Also this comman will create the volume, if the source volume does not exist podman creates it so if you would actually check volume ls afterwards it will show up so I think this is fine.

That said I do agree that the semantics of transient store should be documented better. PRs welcome

[turtleslow]

podman --transient-store run --interactive --rm --volume=maybe-transient:/tmp/not_transient docker.io/alpine:latest /bin/sh<<EOF

Also this comman will create the volume, if the source volume does not exist podman creates it so if you would actually check volume ls afterwards it will show up so I think this is fine.

The volume does show up after running the command, but to my future self, it may feel like i'm accessing a volume out of thin air. The fact that the data persist but are not shown with one of the podman volume list commands feels like a footgun.

• I might end up mounting a volume months down the road that I did not know existed (and hopefully that doesn't break things or discloses data inappropriately).
• If I decide to use unique volume names each time I run a container my machine will fill up with volumes that are not easy to discover or clean-up (or are they (?)).

Is there some other check or command i should be using to ensure I'm not mounting an existing volume and how can i clean volumes that i may have created in the past but are not longer needed?

[Luap99]

Yeah it will "leak" the underlying volume content when you do not recreate the volume with the same name.
I don't think there is a podman command to clean the volumes up from that state (something we should consider). For the container storage there was podman system prune --external added to cleanup old storage references.

Transient mode was added for a very niche use case, I am not sure if you actually need that or not. I don't think that mode is useful outside of that but we definitely should document the behaviours around it better.

[turtleslow]

My use case was really for prototyping and, ironically, keeping my system clean in the event some error failed to explicitly remove a volume; the documentation suggested the option is useful for:

guaranteeing a fresh state on boot in case of unclean shutdowns or other problems. However it is not compatible with a traditional model where containers persist across reboots.

Thanks for the tip on the podman system prune --external command.