Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Error response from daemon: invalid mode: rw,nocopy,www when using Volume subpath #12075

Closed
stivyw opened this issue Aug 22, 2024 · 6 comments · Fixed by #12078
Closed
Assignees
Labels

Comments

@stivyw
Copy link

stivyw commented Aug 22, 2024

Description

I'm getting error when trying to use volume with subpath.
Error response from daemon: invalid mode: rw,nocopy,www when using Volume subpath

Steps To Reproduce

What does not work

volumes:
  myvol:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: /sw/etc/balance

services:
  test:
    image: alpine
    command: sh -l -c 'ls /myvol && ls /var/myvol/* && ls /etc/myvol/*'
    volumes:
      - myvol:/myvol
      - type: volume
        source: myvol
        target: /var/myvol
        volume:
          # nocopy: true
          subpath: www
      - type: volume
        source: myvol
        target: /etc/myvol
        volume:
          nocopy: true
          subpath: etc
...

With local driver and opts, I continue with the same issue.

Error response from daemon: invalid mode: rw,nocopy,www

BUT When volume is external, it works:

mkdir -p $PWD/volume/etc $PWD/volume/www
touch $PWD/volume/etc/ETC $PWD/volume/www/WWW
docker volume create -d local -o type=none -o o=bind -o device=$PWD/volume testvol

docker-compose.yaml

volumes:
  myvol:
    name: testvol
    external: true
    # driver: local
    # driver_opts:
    #   o: bind
    #   type: none
    #   device: $PWD/volume
services:
  test:
    image: alpine
    command: sh -l -c 'ls /myvol && ls /var/myvol/* && ls /etc/myvol/*'
    volumes:
      - myvol:/myvol
      - type: volume
        source: myvol
        target: /var/myvol
        volume:
          # nocopy: true
          subpath: www
      - type: volume
        source: myvol
        target: /etc/myvol
        volume:
          nocopy: true
          subpath: etc

Result

sws:/sw/apps/test$ docker compose up
[+] Running 2/1
 ✔ Network test_default   Created                                                                                                                                                             0.2s 
 ✔ Container test-test-1  Created                                                                                                                                                             0.1s 
Attaching to test-1
test-1  | etc
test-1  | www
test-1  | /var/myvol/WWW
test-1  | /etc/myvol/ETC
test-1 exited with code 0
sws:/sw/apps/test$ 

So, I think maybe this is a docker-compose issue.

Compose Version

Docker Compose version v2.27.0
Docker Compose version v2.27.0

Docker Environment

Client:
 Version:    26.1.5
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 4
  Running: 3
  Paused: 0
  Stopped: 1
 Images: 9
 Server Version: 26.1.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3a4de459a68952ffb703bbe7f2290861a75b6b67
 runc version: 51d5e94601ceffbbd85688df1c928ecccbfa4685
 init version: 
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.43-0-lts
 Operating System: Alpine Linux v3.20
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.664GiB
 Name: sws
 ID: bc9f87c4-621f-4201-b6a0-9e9faebeab52
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

No response

@ndeloof
Copy link
Contributor

ndeloof commented Aug 22, 2024

caused by:

I'm investigating for a fix with risks for potential regressions in mind

@stivyw
Copy link
Author

stivyw commented Sep 25, 2024

@ndeloof I think that was not fixed with #12078 .
Screenshot 2024-09-24 at 22 36 37

@ndeloof
Copy link
Contributor

ndeloof commented Sep 26, 2024

#12078 has been reverted as change in API we use has too many impacts

@ndeloof
Copy link
Contributor

ndeloof commented Sep 27, 2024

the root cause is https://github.com/docker/compose/blob/main/pkg/compose/create.go#L1107-L1110
As compose is responsible to create such a volume, and detect use of local driver as a plain bind mount, it converts the volume definition accordingly (mount type=bind). But then, as we process binds to call the moby API https://github.com/docker/compose/blob/main/pkg/compose/create.go#L825-L826 we have to select use of the legacy bind API for backward compatibility, and only use the newer mount one for others. But as we converted a volume (with subpath) definition into a bind (which has no support for subpath) we just pass the raw bind string, which unfortunately includes configured subpath option, while being not supported.

IMHO we need to revisit 919f351 as considering volume definition (which includes new subpath options introduced by the mount API) is equivalent to a bind is wrong - those are not strictly equivalent by the way engine API is set.
cc @jhrotko

@stivyw
Copy link
Author

stivyw commented Oct 2, 2024

I Understood. Thank's @ndeloof

@ndeloof
Copy link
Contributor

ndeloof commented Oct 3, 2024

@ndeloof ndeloof closed this as completed Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants