Hifiberry OS64: docker mount all of a sudden a directory and not a file

[msperl]

DO NOT remove the blocks below, but fill these with the requested data. Incomplete bug reports will be ignored!
You should remove this comment before posting the bug report.

Describe the bug
all of a sudden shairport-sync does not start again

HiFiBerryOS version
20240523

HiFiBerry sound card
AMP

To Reproduce
no idea how I could reproduce it...

Expected behavior

# docker ps --all
CONTAINER ID   IMAGE                                                COMMAND                  CREATED      STATUS                        PORTS     NAMES
5384624f0c3c   ghcr.io/hifiberry/extension_spotifyd:0.3.5.3         "/bin/sh /start-spot…"   7 days ago   Up 20 minutes                           spotifyd
8275dbd667e0   ghcr.io/hifiberry/extension_raat:1.1.39              "raat_app /etc/hifib…"   7 days ago   Up 20 minutes                           raat
454cd845a1a9   ghcr.io/hifiberry/extension_shairport-sync:4.3.2.4   "/run.sh"                7 days ago   Exited (127) 20 minutes ago             shairport-sync
# docker start 454cd845a1a9
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 "/etc/shairport-sync.conf" to rootfs at "/etc/shairport-sync.conf": mount /etc/shairport-sync.conf:/etc/shairport-sync.conf (via /proc/self/fd/6), flags: 0x5000: 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: failed to start containers: 454cd845a1a9
# rmdir /etc/shairport-sync.conf
# touch /etc/shairport-sync.conf
# docker start 454cd845a1a9
454cd845a1a9

then shairport-sync is starting again (but obviously without a config..

Additional context

As a note: I have seen this happen with docker on "normal" linux system when a file is mapped into the coontainer and when the file does not/no longer exists on start of the container.

Then docker creates a directory in its place (even if it actually knows it is a file - as seen above) and fails with the above error.

(we actually had this mounting /var/run/docker.sock)

[hifiberry]

Thanks for the report. We'll have a look into this. Probably the prepare-script requires some additional checks.