Podman/Compose: "incorrect volume format" on Windows

[limitedeternity]

Issue Description

Error response from daemon: fill out specgen: C:\Users\vbespalov\Downloads\modules:/mnt/modules:rw: incorrect volume format, should be [host-dir:]ctr-dir[:option]

Steps to reproduce the issue

volumes:
  - ..:/mnt/modules

Describe the results you received

Podman compose fails to parse the volume spec (Docker ok, btw)

Describe the results you expected

The absolute path it substituted in the volume spec is parsed correctly

podman info output

Client:
  APIVersion: 5.7.0
  Built: 1762887477
  BuiltTime: Tue Nov 11 21:57:57 2025
  GitCommit: 0370128fc8dcae93533334324ef838db8f8da8cb
  GoVersion: go1.25.4
  Os: windows
  OsArch: windows/amd64
  Version: 5.7.0
host:
  arch: amd64
  buildahVersion: 1.42.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  - dmem
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.13-1.fc42.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.13, commit: '
  cpuUtilization:
    idlePercent: 98.31
    systemPercent: 1.04
    userPercent: 0.64
  cpus: 16
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: coreos
    version: "42"
  emulatedArchitectures:
  - linux/arm64
  - linux/arm64be
  eventLogger: journald
  freeLocks: 2044
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.16.10-200.fc42.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 225783808
  memTotal: 1151410176
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.16.0-1.fc42.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.16.0
    package: netavark-1.16.1-1.fc42.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.16.1
  ociRuntime:
    name: crun
    package: crun-1.25-1.fc42.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.25
      commit: d9a0adce065c7747ab88ea6ccc42b15a626e08e1
      rundir: /run/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^20250919.g623dbf6-1.fc42.x86_64
    version: |
      pasta 0^20250919.g623dbf6-1.fc42.x86_64
      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: unix:///run/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: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.1-2.fc42.x86_64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.5
  swapFree: 0
  swapTotal: 0
  uptime: 0h 43m 13.00s
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.additionalImageStores:
    - /usr/lib/containers/storage
    overlay.imagestore: /usr/lib/containers/storage
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 99252940800
  graphRootUsed: 19084902400
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.7.0
  BuildOrigin: 'Copr: packit/containers-podman-27500'
  Built: 1762819200
  BuiltTime: Tue Nov 11 00:00:00 2025
  GitCommit: 0370128fc8dcae93533334324ef838db8f8da8cb
  GoVersion: go1.24.9
  Os: linux
  OsArch: linux/amd64
  Version: 5.7.0

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

No response

Additional information

No response

[limitedeternity]

Long form also doesn't work:

- type: bind
  source: ..
  target: /mnt/modules

[kavishgr]

Issues related to podman-compose should be reported here. Using native compose with podman is recommended because podman-compose hasn't implemented all features yet.

[limitedeternity]

Using native compose with podman is recommended

You mean "docker-compose"?

[kavishgr]

You mean "docker-compose"?

Yes. Oh, I missed the windows part. No clue how this works in Windows. I used this for macOS. I think the process is the same.

[limitedeternity]

I see. I tried both before opening the ticket: docker-compose, which was offered by Podman after installation, and podman compose, which, I assume, is a built-in script. Both yielded the same result.
I think, installing "real" Docker and using its docker compose could work, but on Windows there is no separate package with just CLI tools – only Docker Desktop is offered.

[limitedeternity]

Compose does the replacement of relative path with absolute one automatically. There is no problem with .. because I know it worked before – before Docker stopped working on my machine.
The problem is probably that the script parses the volume definition head-on using something like this:

source, destination, mode = volume.split(":")

And it obviously doesn't work because there is a colon after the drive letter (C:) in the absolute path.

Thus:

replace .. with an absolute path

won't be of any help.

[limitedeternity]

The problem is somewhere there:

podman/pkg/specgen/volumes.go

Lines 236 to 237 in f526c37

	func SplitVolumeString(vol string) []string {
	parts := strings.Split(vol, ":")

podman-compose isn't the one to blame. I looked through its source code and did some testing – the bind mount argument is constructed properly and is passed to podman afterwards.

The error in the "Issue Description" is issued by podman:

podman/pkg/specgen/volumes.go

Line 94 in f526c37

volumeFormatErr := errors.New("incorrect volume format, should be [host-dir:]ctr-dir[:option]")

[limitedeternity]

However, the relative path expansion is done by podman-compose in the first place:

https://github.com/containers/podman-compose/blob/a1f3befa8ea5c9aa0c84efb9c1f7a267c6cc0c1a/podman_compose.py#L171

[limitedeternity]

No, Windows paths are handled correctly in SplitVolumeString. There are tests, even.
The only possibility of what may have went wrong is that shouldResolveWinPaths() returned false on Windows.

podman/pkg/specgen/volumes.go

Lines 238 to 240 in f526c37

	if !shouldResolveWinPaths() {
	return parts
	}

I also don't see any build constraints defined at the top of winpath_linux.go and winpath_windows.go:

podman/pkg/specgen/winpath_linux.go

Line 1 in fac259e

package specgen

podman/pkg/specgen/winpath_windows.go

Line 1 in fac259e

package specgen

As opposed to winpath_unsupported.go:

podman/pkg/specgen/winpath_unsupported.go

Line 1 in fac259e

//go:build !linux && !windows

(That's where shouldResolveWinPaths is defined)