volume subpath of compose file is not honored

[janusn]

Describe the bug

For containers created with compose, the volume subpath is not honored when recreating the container.

e.g. for the following compose.yaml:

---
services:
  homeassistant:
    image: linuxserver/homeassistant:latest
    container_name: homeassistant
    network_mode: host
    environment:
      - PUID=1017
      - PGID=1017
      - TZ=Europe/London
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "./config:/config:rw"
      - type: volume
        source: cctv
        target: /config/nest
        volume:
          subpath: ha/nest
    restart: unless-stopped

volumes:
  cctv:
    name: homeassistant_cctv
    driver: local
    driver_opts:
      type: cifs
      o: "addr=10.2.3.4,\
        username=user,\
        password=password,\
        file_mode=0660,\
        dir_mode=0770,\
        uid=1017,\
        gid=1017,\
        rw,\
        vers=3.0,\
        auto,\
        noserverino"
      device: "//10.2.3.4/cctv"

When watchertower pulled a new image and restart the container, the directory /config/nest in the container is mapped to smb://10.2.3.4/cctv instead of smb://10.2.3.4/cctv/ha/nest.

Steps to reproduce

1. create a container based on the above compose.yaml file
2. wait for watchtower update the image
3. check the the volume inside the container.

Expected behavior

The subpath argument is honored by the updated container.

Screenshots

No response

Environment

• Platform: Ubuntu Server 24.04.1
• Architecture: 13th Gen Intel(R) Core(TM) i5-1340P, 16 cores
• Docker Version: 26.1.4, build 5650f9b

Your logs

time="2024-08-23T05:16:06+01:00" level=info msg="Session done" Failed=0 Scanned=10 Updated=0 notify=no
time="2024-08-24T05:16:10+01:00" level=info msg="Found new linuxserver/swag:latest image (5e517efa86fa)"
time="2024-08-24T05:16:12+01:00" level=info msg="Stopping /swag (e5a749b68a8d) with SIGTERM"
time="2024-08-24T05:16:14+01:00" level=info msg="Creating /swag"
time="2024-08-24T05:16:14+01:00" level=info msg="Removing image e8fc40a76ba1"
time="2024-08-24T05:16:14+01:00" level=info msg="Session done" Failed=0 Scanned=10 Updated=1 notify=no
time="2024-08-25T05:16:08+01:00" level=info msg="Found new teddysun/v2ray:latest image (90428c02fcf3)"
time="2024-08-25T05:16:09+01:00" level=info msg="Stopping /v2ray (bb0b34fefb17) with SIGTERM"
time="2024-08-25T05:16:10+01:00" level=info msg="Creating /v2ray"
time="2024-08-25T05:16:10+01:00" level=info msg="Removing image fa97e3109e18"
time="2024-08-25T05:16:10+01:00" level=info msg="Session done" Failed=0 Scanned=10 Updated=1 notify=no
time="2024-08-26T05:16:29+01:00" level=info msg="Found new linuxserver/homeassistant:latest image (4824f0437bce)"
time="2024-08-26T05:16:33+01:00" level=info msg="Stopping /homeassistant (6853f16d79fb) with SIGTERM"
time="2024-08-26T05:16:35+01:00" level=info msg="Creating /homeassistant"
time="2024-08-26T05:16:36+01:00" level=info msg="Removing image 12289b32df4e"
time="2024-08-26T05:16:38+01:00" level=info msg="Session done" Failed=0 Scanned=10 Updated=1 notify=no
time="2024-08-27T05:16:06+01:00" level=info msg="Session done" Failed=0 Scanned=10 Updated=0 notify=no
time="2024-08-28T05:16:24+01:00" level=info msg="Found new linuxserver/homeassistant:latest image (266f3481775d)"
time="2024-08-28T05:16:30+01:00" level=info msg="Stopping /homeassistant (cd410b001528) with SIGTERM"
time="2024-08-28T05:16:32+01:00" level=info msg="Creating /homeassistant"
time="2024-08-28T05:16:32+01:00" level=info msg="Removing image 4824f0437bce"
time="2024-08-28T05:16:34+01:00" level=info msg="Session done" Failed=0 Scanned=10 Updated=1 notify=no

Additional context

No response

[github-actions]

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

[EnUfor]

I am also experiencing this issue. I originally was not sure if it was docker or portainer issue originally, but it seems to only occur to containers that are being updated with watchtower.

example sonarr compose.yml:

services:
  sonarr:
    container_name: sonarr
    image: ghcr.io/linuxserver/sonarr
    restart: unless-stopped
    environment:
      - PUID=3002
      - PGID=3001
      - TZ=America/New_York
    ports:
      - 8989:8989
    volumes:
      - /mnt/data/sonarr/config/:/config
      - type: volume
        source: truenas-download
        target: /downloads
        volume:
          subpath: deluge
          nocopy: true
      - type: volume
        source: truenas-media
        target: /tv
        volume:
          subpath: tv-shows
          nocopy: true

volumes:
  truenas-download:
    external: true
    name: truenas-download
  truenas-media:
    external: true
    name: truenas-media

Named volumes were created using:

docker volume create \
  --driver local \
  --opt type=cifs \
  --opt device=//truenas.local/download \
  --opt o=addr=truenas.local,username=REDACTED,password=REDACTED,vers=3.0,uid=3002,gid=3001 \
  truenas-download

docker volume create \
  --driver local \
  --opt type=cifs \
  --opt device=//truenas.local/media \
  --opt o=addr=truenas.local,username=REDACTED,password=REDACTED,vers=3.0,uid=3002,gid=3001 \
  truenas-media

Docker volume inspect output

docker volume inspect truenas-download

[
    {
        "CreatedAt": "2024-09-01T01:09:29-04:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/truenas-download/_data",
        "Name": "truenas-download",
        "Options": {
            "device": "//truenas.local/download",
            "o": "addr=truenas.local,username=REDACTED,password=REDACTED,vers=3.0,uid=3002,gid=3001",
            "type": "cifs"
        },
        "Scope": "local"
    }
]

docker volume inspect truenas-media

[
    {
        "CreatedAt": "2024-09-01T01:09:29-04:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/truenas-media/_data",
        "Name": "truenas-media",
        "Options": {
            "device": "//truenas.local/media",
            "o": "addr=truenas.local,username=REDACTED,password=REDACTED,vers=3.0,uid=3002,gid=3001",
            "type": "cifs"
        },
        "Scope": "local"
    }
]

As stated above, when watchtower pulls an updated image and re-creates containers, it does not honor the subpath option specified in the compose file. Redeploying the stack in portainer is enough to update the containers back to their original condition. One interesting thing is that docker inspect sonarr does not show any difference to the Mounts section with or without the subpath option specified.

Environment

• Platform: Debian GNU/Linux 12 (bookworm)
• Architecture: Dell R730XD w/ 2x E5-2660 v4 running Proxmox
• Docker Version: 27.2.0, build 3ab4256