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
{{ message }}
Repository navigation
Volume path overlap with existing paths inside image #162
The /htdocs webroot inside the container is currently recommended to be configured as volume. However since it contains files required for the application to function, it causes issues with very common use-cases which override the volume content at mount, leaving an empty directory.
The following use-cases are currently impossible without workarounds (see below):
Bind volumes with Docker/Podman/Compose
Kubernetes volumes
A workaround is to copy the original content of the image in the volume with an init container, prior to the main container starting. But this rather hacky and not ideal.
The following changes would be required at minimum:
Allow defining the location of the SQLite database file: that way it can be configured to be read from its own dedicated (sub-)directory and configured as volume
I see a non-empty database is already present on the image's FS. If it is somehow seeded and built into the app that's also bad practice and instead it should be created from scratch at container start
Only mount /htdocs/storage/app/public as a volume to persist file uploads: AFAIK the rest of the webroot doesn't need to be persisted
changed the title [-]Volume paths overlap with existing paths inside image[/-][+]Volume path overlap with existing paths inside image[/+]on May 11, 2026
since it contains files required for the application to function, it causes issues with very common use-cases which override the volume content at mount
You're using a bind mount. The docker-compose shows using a named volume. Use a named volume and you'll get the results you want.
Activity
[-]Volume paths overlap with existing paths inside image[/-][+]Volume path overlap with existing paths inside image[/+]nathanlepori commentedon May 11, 2026
This is also the root cause for #112 and #118
bcurran3 commentedon Sep 1, 2026
You're using a bind mount. The docker-compose shows using a named volume. Use a named volume and you'll get the results you want.