noNameWEB/SealShare
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

Stop the SQLite volume from hiding new migrations

Browse Source 
Uploads on share.kadenpartner.ch failed with 409 on every chunk after
the update to 2.1. The example docker-compose.yml mounts the SQLite
volume over all of /app/database. Docker fills a volume from the image
only when it is created, so the container kept the 2.0 migrations and
never saw the 2.1 one. share_files.uploaded_chunks was never created,
so the chunk endpoint read null and answered 409. SQLite takes the
unknown "completed_at" in whereNull() as a string, so nothing failed
earlier.

- The image keeps a copy of its migrations in docker/migrations. On
  startup the entrypoint adds the ones missing from database/migrations
  before migrating, so installs with the old mount recover by pulling
  the new image.
- docker-compose.example.yml and docker-compose.yml mount
  sealshare_database at /app/database/sqlite and set DB_DATABASE to the
  file in it. An existing volume can be moved there without losing
  data: its database.sqlite lands at exactly that path.
- Tested with a locally built image: a volume created by 2.0.1 with the
  old mount gets the migration once (not again on restart) and keeps
  its settings; the same volume moved to the new path keeps its data;
  a fresh volume with the new layout starts healthy.
- README and CHANGELOG (Unreleased) describe the new path and how to
  switch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Andreas Reinhold / reini
2026-09-17 10:53:27 +02:00
co-authored by Claude Opus 5
parent 7ffc1c1ead
commit c1906d2009
6 changed files with 37 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+3 -1
View File
@@ -99,10 +99,12 @@ Migrations run automatically on startup. Open your configured domain — the Set
| Volume | Path | Purpose |
|--------|------|---------|
| `sealshare_storage` | `/app/storage/app` | Encrypted uploaded files |
| `sealshare_database` | `/app/database` | SQLite database |
| `sealshare_database` | `/app/database/sqlite` | SQLite database (`DB_DATABASE: /app/database/sqlite/database.sqlite`) |
| `caddy_data` | `/data` | TLS certificates |
| `caddy_config` | `/config` | Caddy configuration |
A `docker-compose.yml` from before 2.1.1 mounts `sealshare_database` at `/app/database`, which also hides the image's migrations; the container adds the ones the volume is missing on startup, so it keeps working. To move to the layout above, mount the same volume at `/app/database/sqlite` and set `DB_DATABASE: /app/database/sqlite/database.sqlite` in both services — the existing database is at that path then, and nothing is lost.
**Large files:**
Files go up in chunks of `UPLOAD_CHUNK_SIZE_MB`, one request each, so PHP's upload limits and a proxy's request timeout do not limit a file's size. What does: