[BUG] Docker/Compose has a Problem with mount Files

[Unknown-Players]

Description

I've had this problem for many versions now. It wasn't much of a problem until recently because I could always work around it, and I thought an update would fix it, but it hasn't come.

I'm running Docker on an Ubuntu 24.04 LTS server.

Other Docker projects are also running there.

However, when I try to mount a file in my current project, I get the following error message. From what I've seen, I'm not alone; the internet seems to be full of similar issues, but unfortunately, there's no solution.

Steps To Reproduce

I'm currently trying to run Mailcow's Docker Compose.

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/opt/appdata/mailcow/etc/sysctl.conf" to rootfs at "/etc/sysctl.conf": mount src=/opt/appdata/mailcow/etc/sysctl.conf, dst=/etc/sysctl.conf, dstFd=/proc/thread-self/fd/15, flags=MS_BIND|MS_REC: not a directory: 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

This happens when I have configured the volumes like this.

volumes:

- ./data/hooks/unbound:/hooks

#- ./data/conf/unbound/:/etc/unbound/

- /opt/appdata/mailcow/unbound.conf:/etc/unbound/unbound.conf

- /opt/appdata/mailcow/etc/sysctl.conf:/etc/sysctl.conf

Whether I use an absolute or relative path makes no difference here.

The fact is, it doesn't mount the volume. If, for example, I remove sysctl.conf, then it works.

I can only say that the problem arose at some point due to a Docker update. Unfortunately, you sometimes need exactly this feature to configure Docker containers correctly, and when it's this unreliable, it's quite annoying, especially when time is wasted on what is more of a bug.

Compose Version

docker compose version
Docker Compose version v5.1.4

docker-compose version
Docker Compose version v2.12.2

Docker Environment

ocker info
Client: Docker Engine - Community
 Version:    29.6.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.34.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.4
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 37
  Running: 28
  Paused: 0
  Stopped: 9
 Images: 171
 Server Version: 29.6.0
 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: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e53c7c1516c3b2bff98eb76f1f4117477e6f4e66
 runc version: v1.3.6-0-g491b69ba
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-51-generic
 Operating System: Ubuntu 24.04.4 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 11.63GiB
 Name: docker
 ID: 96cb0c2b-f7f6-4c84-a142-bedd7ad6f79f
 Docker Root Dir: /opt/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables
  EnableUserlandProxy: true
  UserlandProxyPath: /usr/bin/docker-proxy

Anything else?

What I've noticed is that there are apparently older projects that I created where this worked, and these still work. This means it only affects the newer containers or stacks that are created.

For example, I compared the configuration and also checked the file system permissions; everything is identical, so the problem lies elsewhere.