Open janusn opened 2 months ago
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! 🙏
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
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.
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:
When watchertower pulled a new image and restart the container, the directory
/config/nest
in the container is mapped tosmb://10.2.3.4/cctv
instead ofsmb://10.2.3.4/cctv/ha/nest
.Steps to reproduce
Expected behavior
The subpath argument is honored by the updated container.
Screenshots
No response
Environment
Your logs
Additional context
No response