Non-actionable error message: 'Error: unsupported transport "docker" for looking up local images'

[rwmjones]

Issue Description

Using a podman command with a docker:// URI I get this error:

Trying to pull docker.io/kubevirt/fedora-cloud-container-disk-demo:latest...
Getting image source signatures
Copying blob 7e9e1841b94b done   | 
Copying config ce9e1ebe44 done   | 
Writing manifest to image destination
Error: unsupported transport "docker" for looking up local images

This error doesn't tell me what to do to fix the problem, ie. it is a non-actionable error message.

Steps to reproduce the issue

Steps to reproduce the issue

1. Install podman
2. Do some podman command with a docker:// URI

podman info output

host:
  arch: amd64
  buildahVersion: 1.32.0
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-3.fc39.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 92.74
    systemPercent: 5.85
    userPercent: 1.41
  cpus: 32
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: server
    version: "39"
  eventLogger: journald
  freeLocks: 2048
  hostname: cash.home.annexia.org
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 6.3.7-200.fc38.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 26751377408
  memTotal: 66495799296
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.7.0-2.fc39.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.7.0
    package: netavark-1.7.0-2.fc39.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.7.0
  ociRuntime:
    name: crun
    package: crun-1.8.6-1.fc39.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.6
      commit: 73f759f4a39769f60990e7d225f561b4f4f06bcf
      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-0^20230627.g289301b-1.fc39.x86_64
    version: |
      pasta 0^20230627.g289301b-1.fc39.x86_64
      Copyright Red Hat
      GNU Affero GPL version 3 or later <https://www.gnu.org/licenses/agpl-3.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: false
    path: /run/user/1000/podman/podman.sock
  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: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-16.fc39.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 8241360896
  swapTotal: 8589930496
  uptime: 3632h 25m 25.00s (Approximately 151.33 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/rjones/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/rjones/.local/share/containers/storage
  graphRootAllocated: 1636315430912
  graphRootUsed: 1064969011200
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/rjones/.local/share/containers/storage/volumes
version:
  APIVersion: 4.7.2
  Built: 1698762097
  BuiltTime: Tue Oct 31 14:21:37 2023
  GitCommit: ""
  GoVersion: go1.21.3
  Os: linux
  OsArch: linux/amd64
  Version: 4.7.2

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

No

Additional environment details

Fedora Rawhide

Additional information

No response

[giuseppe]

@mtrmac PTAL

[rwmjones]

The commands which lead to this are:

$ podman pull docker://kubevirt/fedora-cloud-container-disk-demo 
Trying to pull docker.io/kubevirt/fedora-cloud-container-disk-demo:latest...
Getting image source signatures
Copying blob 7e9e1841b94b skipped: already exists  
Copying config ce9e1ebe44 done   | 
Writing manifest to image destination
ce9e1ebe442a8c85fc9c6664c4d9de61aac7a51d76bca65935d514e836683020
$ podman save --format oci-dir -o /tmp/dir2 docker://kubevirt/fedora-cloud-container-disk-demo 
Error: unsupported transport "docker" for looking up local images

I still haven't found a way to fix it.

[mtrmac]

@rwmjones So are you saying that pull worked once, then save failed, and later pull is broken?

Or is the report only that save rejects the docker:// syntax?

If it is the latter, that’s expected behavior — save means “export an image in local storage”, and docker://… is not a way to refer to an image in local storage.

[mtrmac]

… and the way to run save correctly should be to just drop the docker:// prefix, turning the argument into a reference to the already-pulled image.

---

(BTW, if the only purpose of these commands were to create the OCI directory, I’d expect skopeo copy docker://… oci:… to be significantly faster).

[rwmjones]

So this used to work at some point in the past and is now giving this error.

How do I know that I can just drop the docker:// prefix to refer to an image in local storage?

Never heard of skopeo before.

[rwmjones]

For example these commands work fine, having the same "pattern" of "pull the thing then save the thing" without needing to change the container URI:

$ podman pull quay.io/kubevirt/fedora-cloud-container-disk-demo 
$ podman save --format oci-dir -o /tmp/dir2 quay.io/kubevirt/fedora-cloud-container-disk-demo 

[mtrmac]

The docker:// syntax specifically refers to an image on the registry. Using podman save docker://… is just a category error.

This situation is the containers equivalent of

wget https://example.com/document
cat https://example.com/document # why doesn’t this work??!

If that was previously accepted, I’m afraid that’s just a bug (https://docs.podman.io/en/latest/markdown/podman-pull.1.html documents that it accepts the transport:details syntax, https://docs.podman.io/en/latest/markdown/podman-save.1.html does not). I’m open to an argument that no longer accepting podman save docker://… is a compatibility breakage and that we need to keep that working; I don’t have an immediate opinion on that.

I could also see an argument that this should be accepted purely for symmetry and user convenience; I’m far less sympathetic to that view, because there’s an inherent ambiguity / semantics conflict. If the contents of the registry tag change, should podman save docker://… refer to the image as it exists in local storage (even if obsolete), or to the latest version as it exists on the registry? docker:// means on the registry, after all.

---

podman pull quay.io/…; podman save quay.io/… work because those inputs are intentionally designed as an user convenience, and heuristically parsed (in quite a few, some possibly surprising ways) [and because those inputs must be compatible with docker(1)]. The ultimate case of this heuristic/convenience aspect is that podman run example.com/foo will either refer to an image in local storage, or automatically pull it; the input carries both semantics depending on the current situation.

docker:// is the conceptual opposite to that: the transport:details syntax is intended to be non-ambiguous and explicit — but that also means that users that choose an explicit syntax have to say precisely what they mean, and not expect that the computer will figure it out.

[rwmjones]

But the error message says nothing about how to fix this. It implies that podman save docker:// could work if only docker: was a supported transport, perhaps by installing an extra package. That's the root cause problem here, the error message is meaningless and non-actionable.

[rwmjones]

Another way to put it: 95% of your users are not experts on when to use a URI and when to use a local image reference. They'll look up the error on their favourite search engine and find nothing useful about how to solve this (as I found too).

[rhatdan]

You got this error, what error:

$ podman save --format oci-dir -o /tmp/dir2 docker://kubevirt/fedora-cloud-container-disk-demo 
Error: unsupported transport "docker" for looking up local images

What error message would have helped?

[rwmjones]

It could say something like:

Error: podman save: "docker://kubevirt/fedora-cloud-container-disk-demo" is
not the name of a downloaded image.  If you want to save from a URI, use
podman pull first, and then use the name of the local image[*]

[*] or whatever is the appropriate term for a pulled/downloaded image, as that's not clear to me

BTW I checked the man page for podman-save and it starts with "podman save saves an image to a local file or directory". This doesn't imply to me that the "image" must be a local, already downloaded image. In fact it doesn't say anywhere in the man page that you to have already pulled/downloaded the image. Literally the words "pull" or "download" don't occur on the page, and "local" is only used to refer to the "local file".