Windows Client, Linux Server, relative volume path regression

[djherbis]

Copied from my comment: #7762 (comment)

I execute docker-compose on Windows, with a remote docker host on Linux. The 'relative path' expansion/abs path transformation from #7762 ends up converting Linux absolute paths in my config (like /path/from/root), into Windows-style paths (like C:/path/from/root), which ends up as an invalid path on the remote filesystem (and caused my volumes to report that the 'device' changed even though I haven't changed my docker-compose file in years).

Example error:

ERROR: Configuration for volume config specifies "device" driver_opt C:\volume1\MEDIA-SHARE\config, but a volume with the same name uses a different "device" driver_opt (/volume1/MEDIA-SHARE/config). If you wish to use the new configuration, please remove the existing volume "config" first:
$ docker volume rm config

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.27.4, build 40524192
docker-py version: 4.3.1
CPython version: 3.7.4
OpenSSL version: OpenSSL 1.1.1c  28 May 2019

Output of docker version

Client:
 Version:           19.03.12
 API version:       1.39
 Go version:        go1.13.12
 Git commit:        0ed913b8-
 Built:             07/28/2020 16:36:03
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.8
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11
  Git commit:       3a371f3
  Built:            Fri Mar 13 06:44:35 2020
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker-compose config
(Make sure to add the relevant -f and other flags)

version: '3.8'
volumes:
  config:
    driver: local
    driver_opts:
      device: C:\volume1\MEDIA-SHARE\config
      o: bind

Actual config file

version: '3.8'
volumes:
  config:
    driver: local
    driver_opts:
      device: /volume1/MEDIA-SHARE/config
      o: bind

Steps to reproduce the issue

1. Setup a docker host on linux.
2. Setup docker-compose on windows, point DOCKER_HOST to the linux docker server.
3. Add a docker-compose.yaml with a volume with a linux-style path.
4. Try to run docker-compose up for that config and observe the incorrect paths (starting from C:\ instead of the linux root).

Observed result

I get errors about the volume path being different, even though it hasn't changed. Thankfully my volume already exists, or else I expect docker-compose just wouldn't be able to create the volume.

Expected result

This should work as it did before the change, and the volume path should be relative to the server filesystem, not the docker-compose client filesystem.

Stacktrace / full error message

ERROR: Configuration for volume config specifies "device" driver_opt C:\volume1\MEDIA-SHARE\config, but a volume with the same name uses a different "device" driver_opt (/volume1/MEDIA-SHARE/config). If you wish to use the new configuration, please remove the existing volume "config" first:
$ docker volume rm config

Additional information

Windows 10 docker-compose client
Linux docker host.

[thaJeztah]

I guess it needs something similar to docker/cli#1990 (but then in Python of course 😅)

@aiordache PTAL

[sti0]

Faced the same issue with secret files defined in a compose file. On running docker-compose up with DOCKER_HOST=remote tcp the linux file paths are converted to absolute Windows paths with a leading C:.

[OJFord]

This is slightly related to #7838 (relative paths expanded client-side, into an absolute paths that don't exist on the remote) in that the underlying issue in both cases is client-side interpretation of volume paths when a remote daemon is in use.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[djherbis]

Bump to prevent staleness, this is blocking docker upgrades for me.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stuartin]

Also hitting issues with this. Would be great to get it fixed! 🙏🤞

[LaXiS96]

Hello, this problem has been reported multiple times, but no dev (@aiordache) seems to reply and I've not been able to upgrade Docker Desktop since October 2020 because this completely breaks my deployment setup.

See some relevant issues: #7856 #7893 #8051 and also comments in the PR #7762

Please see #7856 (comment) for an analysis of the cause.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[djherbis]

Bump to prevent staleness, this is still blocking docker upgrades for me.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[djherbis]

Is there a workaround here? I feel like it's reasonable to be using docker compose from a windows client to a linux server.

[djherbis]

Actually the solution looks to be just to switch to docker compose v2

[laurazard]

Hi @djherbis,

Yes, currently Docker Compose V1 is EOL and not receiving any new updates other than critical security issues.

I'm closing the issue since it seems Compose V2 is working appropriately :)