"not a directory: unknown: Are you trying to mount a directory onto a file" error produced when mounting a single file on a container

[osev]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 119E07EF-6952-4A59-B13D-E5489EF05FE9/20210614165845

Expected behavior

I am running a service which mounts a file onto the docker container. The service is define like so in the docker-compose file:

version: "2.1"

services:
    tms_make:    
        image: node:12.4.0-stretch     
        working_dir: /project    
        volumes:      
            - ./addons/tms/webpack.config.js:/project/webpack.config.js

I would expect the webpack.config.js file to mounted to the docker container.

Actual behavior

Error:

Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: rootfs_linux.go:60: mounting "/Users/sev/projects/boot/addons/tms/webpack.config.js" to rootfs at "/var/lib/docker/overlay2/febdeca9fa5544324f62938537e9423b7d520bb7aa55e98db2b9cf3d66c5b1f3/merged/project/webpack.config.js" caused: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Information

I have tried a few things to try and resolve the issue:

• Removing the container and the volumes and trying again.
• Turning the gRPC FUSE for file sharing checkbox off in the preferences. (there's a bunch of github issues on the docker github so I thought it might be a quick win)
• I also tried manually binding the file (to check if there was an issue with the file itself) and there was no errors

docker run -d \
--name testdocker \
--mount type=bind,source="$(pwd)"/addons/tms/webpack.config.js,target=/project/webpack.config.js \
node:12.4.0-stretch

and

docker run -d \
--name testdocker \
-v "$(pwd)"/addons/tms/webpack.config.js:project/webpack.config.js \
node:12.4.0-stretch

• I have tried mounting the directory and that worked fine - for some reason it's failing on single files?

• My colleagues (with the same docker desktop version) are running the same docker compose file to spin up their development environment without any issues. It seems like there's something specific to my machine / setup

  • macOS Version: Big Sur (v 11.3.1)
  • Intel chip or Apple chip: Intel
  • Docker Desktop Version: 3.4.0

Steps to reproduce the behavior

Please see above

[mat007]

Thanks for the bug report, can you tell us what docker-compose version prints?

[osev]

@mat007 - after a bit more digging, the issue seems to be only in 3.4.0.

In 3.4.0, when running the above service, a directory is created in place of the file. When removing the directories manually the build succeeds.

I'm not sure why the folders still existed on the container after I removed the volumes and containers (I may have missed something here)

Unfortunately as I no longer have 3.4.0 installed, my docker-compose version is related to the 3.3.3 which works:

docker-compose version 1.29.1, build c34c88b2
docker-py version: 5.0.0
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020

[ndeloof]

Assuming you've been using compose v2 with Desktop 3.4.0, this issue is possibly related to 726e204

Hard to confirm with a know version and a reproductible scenario

[jashby44]

I'm having the same issue after updating to 3.4.0. No issue with 3.3.0 or prior. Here are some notes to reproduce the issue.

• Mac Catalina 10.15.7
• Docker version 20.10.7, build f0df350

Mounting a single file actually works fine:

$ echo foo > ~/somefile.txt
$ cat docker-compose.yml 
version: "3.9"
services:
  myservice:
    image: alpine:latest
    volumes:
      - ~/somefile.txt:/home/somefile.txt
    command: ls -la /home

$ docker compose up
[+] Running 2/1
 ⠿ Network test_default        Created                                                                                                 3.8s
 ⠿ Container test_myservice_1  Created                                                                                                 0.0s
Attaching to myservice_1
myservice_1  | total 12
myservice_1  | drwxr-xr-x    1 root     root          4096 Jun 16 18:47 .
myservice_1  | drwxr-xr-x    1 root     root          4096 Jun 16 18:47 ..
myservice_1  | -rw-r--r--    1 root     root             4 Jun 16 18:25 somefile.txt
myservice_1 exited with code 0

No error, and the file gets correctly mounted as a file inside the container ^.

However, if you mount a directory AND a single file, then the issue happens:

$ cat docker-compose.yml 
version: "3.9"
services:
  myservice:
    image: alpine:latest
    volumes:
      - type: bind
        source: ./
        target: /home
      - ~/somefile.txt:/home/somefile.txt
    command: ls -la /home

$ docker compose up              
[+] Running 1/1
 ⠿ Container test_myservice_1  Recreated                                                                                                   0.1s
Attaching to myservice_1
Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/user/somefile.txt" to rootfs at "/home/somefile.txt" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

# after the error, the mounted file is left behind in the locally-mounted volume (/home)
$ file somefile.txt 
somefile.txt: directory

We use this pattern for local development so we can work locally on code and have it reflect inside the container. The reason for the single file (somefile.txt in this example) is so we can also mount up a config file that has secrets and thus is in .gitignore.

FWIW, I've noticed this also happens if using a different source directory on the bind mount from ./ to /tmp/somedir, so it's not the cwd.

Side note, docker compose down was run in between tests to ensure network, vols, etc... were fresh.

My workaround is to locally copy in somefile.txt explicitly prior to running docker compose up so I don't need to have that single file mount in the docker compose yaml. Not a big deal since we have a dev setup script that is easy to add this step to, but for users who want to keep it all in the yaml then it's a bit of a limitation.

[ndeloof]

I was able to reproduce this error, investigating

[ndeloof]

I actually can also reproduce this error when using docker-compose v1

➜  /usr/local/bin/docker-compose version
docker-compose version 1.29.2, build 5becea4c
docker-py version: 5.0.0
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020
➜  /usr/local/bin/docker-compose up
Creating truc_myservice_1 ... error

ERROR: for truc_myservice_1  Cannot start service myservice: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/nicolas/somefile.txt" to rootfs at "/home/somefile.txt" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

I'll try the same on my Linux box, but it looks like this is actually a Docker Desktop issue

[ndeloof]

Confirmed this is a Docker Desktop issue, not related to docker compose:

➜ docker run -v $(pwd):/home -v $HOME/somefile.txt:/home/somefile.txt alpine ls -al /home
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/nicolas/somefile.txt" to rootfs at "/home/somefile.txt" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

[thaJeztah]

Tried some variants, and it looks to be if the file mount and directory mount overlap inside the container (in your example, both are mounted to /home), so in case of nested mounts.

mkdir -p ~/Projects/test/foobar/somedir \
    && echo hello > ~/Projects/test/foobar/somedir/someotherfile.txt \
    && echo hello > ~/Projects/test/foobar/somefile.txt

(created "someotherfile.txt" just in case the directory wasn't synced if empty)

✅ This works (directory):

docker run --rm -v ~/Projects/test/foobar/somedir:/home alpine ls -al /home
total 8
drwxr-xr-x    3 root     root            96 Jun 17 07:56 .
drwxr-xr-x    1 root     root          4096 Jun 17 07:56 ..
-rw-r--r--    1 root     root             6 Jun 17 07:56 someotherfile.txt

✅ This works (file):

docker run --rm -v ~/Projects/test/foobar/somefile.txt:/home/somefile.txt alpine ls -al /home
total 12
drwxr-xr-x    1 root     root          4096 Jun 17 07:58 .
drwxr-xr-x    1 root     root          4096 Jun 17 07:58 ..
-rw-r--r--    1 root     root             6 Jun 17 07:56 somefile.txt

✅ This works (file and directory, but paths do not overlap):

docker run --rm -v ~/Projects/test/foobar/somedir:/path1 -v ~/Projects/test/foobar/somefile.txt:/path2/somefile.txt alpine ls -al /path1 /path2
/path1:
total 8
drwxr-xr-x    3 root     root            96 Jun 17 08:05 .
drwxr-xr-x    1 root     root          4096 Jun 17 08:05 ..
-rw-r--r--    1 root     root             6 Jun 17 08:05 someotherfile.txt

/path2:
total 12
drwxr-xr-x    2 root     root          4096 Jun 17 08:05 .
drwxr-xr-x    1 root     root          4096 Jun 17 08:05 ..
-rw-r--r--    1 root     root             6 Jun 17 08:05 somefile.txt

❌ This fails:

docker run --rm -v ~/Projects/test/foobar/somedir:/home -v ~/Projects/test/foobar/somefile.txt:/home/somefile.txt alpine ls -al /home

docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/sebastiaan/Projects/test/foobar/somefile.txt" to rootfs at "/home/somefile.txt" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

After running, a directory is created in ~/Projects/test/foobar/somedir

ls -la ~/Projects/test/foobar/somedir
total 8
drwxr-xr-x  4 sebastiaan  staff  128 Jun 17 09:57 ./
drwxr-xr-x  5 sebastiaan  staff  160 Jun 17 09:56 ../
drwxr-xr-x  2 sebastiaan  staff   64 Jun 17 09:57 somefile.txt/
-rw-r--r--  1 sebastiaan  staff    6 Jun 17 09:56 someotherfile.txt

(edit: didn't clean up directory between tests)

[sipani909]

I still see this error with the following. Running MacOS Big Sur 11.4. Downloaded an upgraded to docker desktop 3.5.0 this morning as it mentioned fixing this bug.

abhijit.sipani@ASipani docker % docker-compose version
Docker Compose version 2.0.0-beta.4
abhijit.sipani@ASipani docker % docker version
Client:
 Cloud integration: 1.0.17
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.16.4
 Git commit:        f0df350
 Built:             Wed Jun  2 11:56:22 2021
 OS/Arch:           darwin/amd64
 Context:           desktop-linux
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       b0f5bc3
  Built:            Wed Jun  2 11:54:58 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
abhijit.sipani@ASipani docker % docker -v
Docker version 20.10.7, build f0df350
abhijit.sipani@ASipani docker % docker-compose-v1 version    
docker-compose version 1.29.2, build 5becea4c
docker-py version: 5.0.0
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020
abhijit.sipani@ASipani docker % docker-compose run ms-perfect
Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/abhijit.sipani/.ssh/id_rsa" to rootfs at "/root/.ssh/id_rsa" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
abhijit.sipani@ASipani docker % docker-compose-v1 run ms-perfect
Creating docker_ms-perfect_run ... done
Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/abhijit.sipani/.ssh/id_rsa" to rootfs at "/root/.ssh/id_rsa" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
ERROR: 1

My docker-compose looks like the following:

version: "3.6"
services:
  ms-perfect:
    image: docker.artifactory.ikarem.io/ci/ms-perfect/ms-perfect/release/ms-perfect:latest
    network_mode: "host"
    environment:
      - USER
    cap_add:
      - SYS_PTRACE
    security_opt:
      - seccomp:unconfined
    volumes:
      - ~/.ssh/id_rsa:/root/.ssh/id_rsa
      - ~/.ssh/id_rsa.pub:/root/.ssh/id_rsa.pub
      - ${PWD}/../../../testbed/:/testbed
      - ./testbed/testbed_shared/lib/ms/poe/dependencies/:/root/

[ndeloof]

@sipani909 confirmed Docker Desktop issue is not fixed:

$ docker run -v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa -v $(pwd)/testbed/:/root/ alpine
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/host_mnt/Users/nicolas/.ssh/id_rsa" to rootfs at "/root/.ssh/id_rsa" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

[thaJeztah]

Note that, due to the nested mounts (/root/ and /root/.ssh/id_rsa / /root/.ssh/id_rsa.pub), this issue can be affected by possibly left-over directories created from previous runs; make sure the /testbed/testbed_shared/lib/ms/poe/dependencies does not have directories for .ssh/id_rsa and .ssh/id_rsa.pub. If docker previously created directories for them (as mount point), those would exist afterwards inside the local directory. When running the stack again, those directories would be mounted as part of ./testbed/testbed_shared/lib/ms/poe/dependencies/:/root/, and would cause the files failing to be mounted.

[thaJeztah]

(that is, after the issue has been fixed: those directories must be cleaned up)

[ndeloof]

@thaJeztah IIUC mounting file into /root/.ssh/id_rsa creates an empty file as mount point, and as the upper-level /root/ is already a mount point, this file is persisted on bind-mounted folder. But previous bug created this path as a folder, which make it then impossible to bind mount a file. Need manual cleanup

I have to admit I never tried to mix things this way :P

[thaJeztah]

Yes, that's the scenario I had in mind; in the "with bug" situation (not 100% sure, but this is the scenario I was thinking of);

1. docker checks if (source path) ./testbed/testbed_shared/lib/ms/poe/dependencies/ exists. If not, creates it as a directory
2. docker checks target path mount point /root/ exists in the container, if not it creates a directory
3. docker mounts /testbed/testbed_shared/lib/ms/poe/dependencies at /root/ inside the container
4. docker checks if (source path) ~/.ssh/id_rsa exists. If not (or because of BUG), it creates it as a directory (default for mounts is a "directory")
5. docker checks if target path mount point /root/.ssh/id_rsa exists, if not, it creates it (if "source path" from step 4. was a directory, it creates a directory as mount point).

In step 5., /root/ inside the directory is a bind-mount in itself, so when creating /root/.ssh/id_rsa inside the container, it's created in the bind mounted directory, which is ./testbed/testbed_shared/lib/ms/poe/dependencies/ on the host, so now that directory will be created on the host.

[sipani909]

@ndeloof and @thaJeztah Thanks for the detailed info! Can confirm that the issue was no longer observed after removal of line:

- ./testbed/testbed_shared/lib/ms/poe/dependencies/:/root/

We will try to workaround this while the issue is looked at.

[ndeloof]

@sipani909 check ./testbed/testbed_shared/lib/ms/poe/dependencies/ does not contain some unexpected .ssh/id_rsa folder created by previous bug. If so, delete this and retry.

[sipani909]

Hi @ndeloof checked and confirmed that it does not. However the path on our end should have been

- ${PWD}/../../../testbed/testbed_shared/lib/ms/poe/dependencies/:/root/

rather than

- ./testbed/testbed_shared/lib/ms/poe/dependencies/:/root/

Changed that and verified that it works with that as well. Should have caught that early on.

[sipani909]

Actually looking at directory contents, looks like it creates new files

abhijit.sipani@ASipani dependencies % pwd
/Users/abhijit.sipani/co/router/testbed/testbed_shared/lib/ms/poe/dependencies
abhijit.sipani@ASipani dependencies % ls -ltr
total 0
drwxrwxr-x  3 abhijit.sipani  staff   96 Jun 16 07:29 Sifos
drwxrwxr-x  7 abhijit.sipani  staff  224 Jun 16 07:29 bin
abhijit.sipani@ASipani dependencies % ls -a
.               ..              .bash_aliases   .bash_history   .ssh            Sifos           bin
abhijit.sipani@ASipani dependencies % ls -ltr .ssh 
total 0
-rwxr-xr-x  1 abhijit.sipani  staff  0 Jun 24 12:35 id_rsa
-rwxr-xr-x  1 abhijit.sipani  staff  0 Jun 24 12:35 id_rsa.pub
abhijit.sipani@ASipani dependencies % 

[ndeloof]

yes it does, as explained by @thaJeztah this is required to create a mount point for the nested bind mount. Same applies if you run the equivalent docker run -v ...

[thaJeztah]

Yes, the mount points have to be created; this is how Linux works; when you want to mount a file (or directory) somewhere, the target location must exist (to act as the "mount point"). Also see docker/compose#2957 (comment)

technically it would be possible for docker to clean up those directories or files afterwards (after unmounting / when the container stops), but doing so is risky, and "complex" (docker would have to keep track if the mount point existed beforehand, or if it created it, then only remove if it created it (not in any other case). Given that bind-mounts (and volumes) can be used by multiple containers, in which case there's a risk of race-conditions (and the possibility it would be deleting files created by other containers). Because of all of those, docker (currently) won't clean up mount-points.

I think I have an example written down somewhere about the mounting, let me look it up

[thaJeztah]

Found it:

mkdir example && cd example

mkdir host-dir && echo hello > host-dir/some-file-on-host.txt
mkdir host-dir2 && echo hello > host-dir2/some-file-on-host2.txt
echo hello > host-file.txt
mkdir container
mkdir container/existing-dir && echo existing > container/existing-dir/existing-file.txt

tree
.
├── container
│   └── existing-dir
│       └── existing-file.txt
├── host-dir
│   └── some-file-on-host.txt
├── host-dir2
│   └── some-file-on-host2.txt
└── host-file.txt

example: bind-mount a directory in the container:

# bind-mounting fails if the destination doesn't exist
mount -t none -o bind host-dir container/bind-mounted-dir
mount: mounting host-dir on container/bind-mounted-dir failed: No such file or directory

# so docker creates the mountpoint (empty directory) to act as mount point
mkdir container/bind-mounted-dir

# bind-mount "host-dir" at "/bind-mounted-dir" within the container's filesystem
mount -t none -o bind host-dir container/bind-mounted-dir

# listing the content of container/bind-mounted-dir now shows the content of
# the bind-mounted directory
ls container/bind-mounted-dir
some-file-on-host.txt

Note that files/directories that are mounted are the exact same files as the original files, so modifying files, or adding/removing files will modify the files in "host-dir". This would also happen if you use a "nested" mount, and a mount-point is created inside another mount:

# bind-mount "host-dir2" at "/bind-mounted-dir/nested-mounted-dir" within the container's filesystem
mkdir container/bind-mounted-dir/nested-mounted-dir
mount -t none -o bind host-dir2 container/bind-mounted-dir/nested-mounted-dir

# content now shows content of "host-dir2"
ls container/bind-mounted-dir/nested-mounted-dir
some-file-on-host2.txt

# but "host-dir" was also modified, because the mount-point was created
ls host-dir
nested-mounted-dir     some-file-on-host.txt

Same for bind-mounting a file:

# bind-mounting fails if the destination doesn't exist
mount -t none -o bind host-file.txt container/bind-mounted-file.txt
mount: mounting host-file.txt on container/bind-mounted-file.txt failed: No such file or directory

# so docker creates the mountpoint (empty file) to act as mount point
touch container/bind-mounted-file.txt

# bind-mount "host-file.txt" at "/bind-mounted-file.txt" within the container's filesystem
mount -t none -o bind host-file.txt container/bind-mounted-file.txt

# reading the content of container/bind-mounted-file.txt now shows the content
# of the bind-mounted file:
cat container/bind-mounted-file.txt
hello

Note that if the destination directory already exists, bind-mounting files or directories "hide" their content:

# before bind-mounting:
ls container/existing-dir
existing-file.txt

# bind-mount "host-dir" at "/bind-mounted-dir" within the container's filesystem
mount -t none -o bind host-dir container/existing-dir

# after bind-mounting, it shows the content of the bind-mounted directory:
ls container/existing-dir
nested-mounted-dir     some-file-on-host.txt

# but original files are accessible again after unmounting
umount container/existing-dir
ls container/existing-dir
existing-file.txt

[alanbueno]

if anyone ends up here due to volumes mounted from a Linux WSL instance not resolving:
there's this workaround of moving your project to a windows dir.

[Simon-CR]

having similar issue:

app:
  image: invoiceninja/invoiceninja:5
  container_name: InvoiceNinja5
  restart: always
  volumes:
    - ./config/hosts:/etc/hosts:ro
    - ./docker/app/public/:/var/www/app/public/:rw,delegated
    - ./docker/app/storage/:/var/www/app/storage/:rw,delegated

with error being:

Cannot start service app: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/data/compose/8/config/hosts" to rootfs at "/etc/hosts" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type ERROR: for app Cannot start service app: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/data/compose/8/config/hosts" to rootfs at "/etc/hosts" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type Encountered errors while bringing up the project. : exit status 1

looking in the /data/compose/8/config I see a folder called hosts being created systematically when trying to launch. Even after removing it.

[thaJeztah]

looking in the /data/compose/8/config I see a folder called hosts being created systematically when trying to launch. Even after removing it.

You're bind-mounting ./config/hosts from the host into the container; if /data/compose/8/ is your compose project directory, and there's no file named config/hosts, then docker will assume you're trying to bind-mount a directory, and create one.

So you either need to remove that bind-mount from your compose file, or If the intent is to provide a custom /etc/hosts for your container, then you need to create that file before running the compose file.

[nrezatash]

running this:
sudo -E bash -c "docker-compose -f docker-compose.yaml up -d"
instead of this:
docker-compose -f docker-compose.yaml up -d
worked for me.

[pencilcheck]

Basically, create the files locally before running the command fixes it since docker compose create all non existing volumes entries as directory (sometimes you need a file instead)

[galek]

Bump, is actual

checked on :
version: "3.9" # optional since v1.27.0

[dskvr]

Not fully related, but got here from a different issue. might help someone

I accidentally mounted a directory to a file in the container, and could no longer docker-compose up. had to docker container rm $CONTAINER first, and then docker-compose up fixed the issue in this context.

[dskvr]

Not fully related, but got here trying to solve a different issue, might help someone

I accidentally mounted a directory to a file in the container, and could no longer docker-compose up. had to docker container rm $CONTAINER first, and then docker-compose up fixed the issue in this context.

[hadpro24]

This bug is still now.

[jalik]

Not fully related, but got here trying to solve a different issue, might help someone

I accidentally mounted a directory to a file in the container, and could no longer docker-compose up. had to docker container rm $CONTAINER first, and then docker-compose up fixed the issue in this context.

That worked for me ! I really needed to remove the existing container with its volume before running it again, maybe something went wrong in previous runs.