Compose file-type mounts materialize as empty directories instead of files

To Reproduce

1. Create a Compose resource (sourceType: raw) with a service that has 2+ type: file mounts (via Advanced → Mounts, or the mounts.create API).
2. Reference them in the compose file the standard way: ../files/<mountPath>:<container target>.
3. Deploy.

Current vs. Expected behavior

Expected: Dokploy materializes each mount as a real file with the configured content at /etc/dokploy/compose/<appName>/files/<mountPath>.

Actual: File-type mounts are materialized as empty directories instead of files containing the content. Docker then either:

• fails outright on docker compose up with error evaluating symlinks from mount source ".../files/<path>": not a directory (when the bind target expects a file but a sibling/parent in the path is unexpectedly a plain file — see the more severe variant below), or
• succeeds in creating the container, but the container ends up with an empty directory bind-mounted where a config/init file should be, silently breaking the service (e.g. a Postgres docker-entrypoint-initdb.d SQL script becomes an empty dir and never runs, or an app's declarative-config file becomes an empty dir and the app fails to parse it / crashes / OOMs retrying).

More severe variant observed: in one case, the top-level files path itself (/etc/dokploy/compose/<appName>/files) was a plain regular file (9.3KB, containing the raw content of one of the mounts) instead of a directory — so every mount under it failed with not a directory, regardless of which specific mount was referenced.

Persistence quirk: once a container has been created with a mount pointing at one of these bad empty-directory paths, the bind mount's type (file vs. directory) appears to be locked in for that container's lifetime. Manually fixing the host-side path (removing the empty dir, replacing it with a real file via direct filesystem access) does not fix the running/restarting container — on each restart it re-establishes the same broken directory-type mount. Only removing and recreating the container (e.g. via a fresh docker compose up after the host path is corrected) picks up the fix.

I did not fully isolate the exact trigger (it was not simply "many mounts" — it still reproduced with just 2 mounts on one service, and was not resolved by reordering the mounts, changing SELinux relabel flags :z/:Z, adding a startup delay before the affected container, or removing an unrelated backup config that happened to reference the same service name).

Provide environment information

Dokploy version: v0.30.5
OS: Ubuntu (Contabo VPS)
Compose source type: raw

Which area(s) are affected? (Select all that apply)

Docker Compose

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

Workaround that resolved it for us: removed the affected mounts from Dokploy's tracking (mounts.remove) entirely and placed the files directly on the host filesystem via SSH, keeping everything else (the Compose resource itself, env vars, domain/TLS, backups) fully Dokploy-managed. This suggests the bug is specifically in the mount-materialization/write path, not in docker compose up itself or in how the compose file references ../files/....

Happy to provide more diagnostic detail (directory listings, stat output, timestamps) if useful — this was reproduced consistently across ~13 deploy attempts while debugging a self-hosted Supabase stack.

Will you send a PR to fix it?

No

Start with Dokploy's mount-materialization/write path for raw Compose resources and inspect how multiple type:file mounts are created under /etc/dokploy/compose//files. Reproduce with two mounts, then verify each generated path is a regular file containing its configured content and that a freshly recreated container receives file-type bind mounts correctly.