You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then when i use the following in auto deploy (GitHub provider), it didn't work (not mounted). But when I use raw provider (raw compose file), it worked.
volumes:
- ../files/:/files/:ro
Version: v0.29.8
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?
@finnvyrn, this looks like the same underlying issue reported in #5152. Here's what's happening:
When you deploy via the GitHub provider, Dokploy clones the repo and then runs docker compose up[1]. At that point, if the File Mount hasn't already written the host-side file, Docker's own bind-mount fallback creates an empty directory at the ../files/ path. Once that empty directory exists, Dokploy's createFileMount / updateFileMount functions silently fail to write to it — the catch block only console.logs the error without throwing, so the UI reports success even though nothing was actually written [2].
With the raw provider, the compose file is written directly to disk without a clone step [3], so the timing is different and the directory doesn't get pre-created by Docker before the file mount is written.
Activity
linear-code commentedon Aug 24, 2026
DOK-692
dosubot commentedon Aug 24, 2026
@finnvyrn, this looks like the same underlying issue reported in #5152. Here's what's happening:
When you deploy via the GitHub provider, Dokploy clones the repo and then runs
docker compose up[1]. At that point, if the File Mount hasn't already written the host-side file, Docker's own bind-mount fallback creates an empty directory at the../files/path. Once that empty directory exists, Dokploy'screateFileMount/updateFileMountfunctions silently fail to write to it — thecatchblock onlyconsole.logs the error without throwing, so the UI reports success even though nothing was actually written [2].With the
rawprovider, the compose file is written directly to disk without a clone step [3], so the timing is different and the directory doesn't get pre-created by Docker before the file mount is written.Workaround (from #5152):
rmdirthe stray empty directory (e.g./etc/dokploy/compose/<appName>/files/).docker rm -f <container>, then redeploy) so Docker picks up the corrected mountpoint.A fix for this was submitted in #5153 [2] — tracking that PR should get you a permanent resolution.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
fix: resolve relative bind mounts against code dir for git-based comp…
fix: only pin --project-directory when compose has mounts
chore(release): 0.42.0 [skip ci]
chore: rebase fork onto Dokploy v0.30.10 (#9)