compose: Secrets invalid mount config for type 'bind' mount path must be absolute
Description of the issue
Docker compose does not convert secrets source path correctly while using docker toolbox (virtualbox).
Context information (for bug reports)
Output of docker-compose version
docker-compose version 1.24.0dev, build unknown
docker-py version: 3.7.0
CPython version: 3.7.2
OpenSSL version: OpenSSL 1.1.0j 20 Nov 2018
Output of docker version
Client:
Version: 18.09.2
API version: 1.39
Go version: go1.11.5
Git commit: 62479626f2
Built: Wed Feb 13 09:02:49 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.3
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 774a1f4
Built: Thu Feb 28 06:40:51 2019
OS/Arch: linux/amd64
Experimental: false
Output of docker-compose config
(Make sure to add the relevant -f
and other flags)
secrets:
password:
file: C:\Users\Joaom\teste\secrets\password
user:
file: C:\Users\Joaom\teste\secrets\user
services:
rice:
image: alpine:3.8
secrets:
- source: password
- source: user
version: '3.6'
Steps to reproduce the issue
- Install docker toolbox latest release from Docker toolbox repository on a Windows 10 Home Edition computer.
- docker-compose up -d
Observed result
Secrets are not mounted in the container, because compose is not converting path from Windows to unix Style correctly like it does for volumes.
Expected result
secrets to be mounted successfully.
Stacktrace / full error message
Creating network "teste_default" with the default driver
Creating teste_rice_1 ... error
ERROR: for teste_rice_1 Cannot create container for service rice: invalid mount config for type "bind": invalid mount path: 'C:/Users/Joaom/teste/secrets/password' mount path must be absolute
ERROR: for rice Cannot create container for service rice: invalid mount config for type "bind": invalid mount path: 'C:/Users/Joaom/teste/secrets/password' mount path must be absolute
ERROR: Encountered errors while bringing up the project.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 11
- Comments: 24 (3 by maintainers)
Commits related to this issue
- Fix to secrets paths on Dockertoolbox #6585 — committed to Fiercely/compose by jpcmadeira 5 years ago
- fix: hardcoded secret env vars until windows issue has been resolved https://github.com/docker/compose/issues/6585 — committed to TaitoUnited/full-stack-template by keskiju 5 years ago
I am having this issue too. Any update on this?
@chris-crone The last laptop I bought 5-6 years ago came with Windows 8 (OEM) and I’ve been using this laptop for local development since then. If I had a choice when I bought it back then, it would properly be running Windows 7, my preferred edition of Windows.
@joshooaj , I’ve transformed my
compose.yaml
file according to your comment:, where
secrets
is a folder next tocompose.yaml
file containing the secrettg_bot.token
file.Unfortunately, the result hasn’t changed:
I think the difference is in the fact that I’m using Windows not inside but outside the container, i.e. on the host machine, and Docker for some reason fails to resolve the path to the secret in this format.
Anyway thanks for the suggestion!
It’s 2023 but the issue still here. I’m using Docker Desktop v4.19.0 (
docker v23.0.5
anddocker-compose v2.17.3
) with the followingcompose.yaml
file:and when launching
docker-compose up
, I’m getting the following:I’ve tried various forms of the secret path:
telebot.token
./telebot.token
c:/absolute/path/telebot.token
c:\absolute\path\telebot.token
c:\\absolute\\path\\telebot.token
but the result stays the same.
@jpcmadeira, @chris-crone , since the attached PR was not merged, is there a workaround or another issue that’s hopefully will be addressed?
Given that there still seems to be no solution for this, is there a way to request this issue be repoened, or should I open a new issue linking to this one?
@chris-crone I need Virtualbox for various projects (I’m aware VBox can theoretically work with Hyper-V enabled but last time I tried it wouldn’t work on most machines, including mine, and was reported to be extremely slow and unsupported); Vagrant, which I have tried with Hyper-V but found it to be an awful experience; and Android emulators, where the only Hyper-V compatible one I’m aware of doesn’t perform well enough for my needs.