fix: reduce bind-mount mariadb corruption risk#598
Merged
Conversation
Some users have reported MariaDB tables becoming unreadable
("Table ... doesn't exist in engine", "Incorrect information
in file") after schema migrations on Docker Desktop, ARM hosts,
and some NAS/virtualized filesystems. The bundled MariaDB
defaulted to a bind mount on ./database, which appears to be
involved in those reports.
Default fresh installs started by ./start.sh to the named-volume
override on every platform. Existing installs with data in
./database are preserved on the bind mount and shown a migration
warning instead of being silently switched, including when --arm
is passed or an ARM host is auto-detected.
Add scripts/migrate-to-named-volume.sh, an opt-in helper that
dumps the bind-mounted database, renames ./database to a
timestamped backup directory, imports into a fresh named volume,
verifies table set and per-table row counts, and only then pins
the override in .env. The script supports a passwordless-sudo
fallback for installs where the project directory is not directly
writable, and refuses to run on ambiguous or non-default setups.
Centralize storage-mode detection in scripts/_env_helpers.sh so
backup.sh and restore.sh share the same logic and refuse to act
when both ./database and a named volume exist. Update README,
DATABASE, DOCKER, INSTALLATION, DEVELOPMENT, and TROUBLESHOOTING
docs to describe the new defaults and migration path.
Contributor
📊 Test Coverage ReportBackend Coverage
Frontend Coverage
Coverage Requirements
Coverage report generated for commit f6c0664 |
npm audit gate (--audit-level=high --omit=dev) was failing CI on GHSA-w9j2-pvgh-6h63 and related axios 1.x advisories. Run npm audit fix in both root and client/ to advance axios to 1.16.0 and pull forward follow-redirects, ip-address, and express-rate-limit within their existing semver ranges. Lockfile-only change.
mkulina
reviewed
May 7, 2026
Hardcoding the new database to utf8mb4_unicode_ci could silently change the DB-level default collation for installs whose source DB used a different utf8mb4 collation, affecting future ALTERs and any tables created by later migrations. Read DEFAULT_CHARACTER_SET_NAME and DEFAULT_COLLATION_NAME from the source schema before the dump and reuse them in the target's CREATE DATABASE. If the source default is not utf8mb4_*, fall back to utf8mb4_unicode_ci and warn. Either way, log the chosen collation so the user has a breadcrumb. Also rename the "Option 1: Bind Mount (Default)" heading in docs/DATABASE.md; with this PR fresh installs default to the named volume, so calling bind mount the default is misleading. Refs: #598
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some users have reported MariaDB tables becoming unreadable ("Table ... doesn't exist in engine", "Incorrect information in file") after schema migrations on Docker Desktop, ARM hosts, and some NAS/virtualized filesystems. The bundled MariaDB defaulted to a bind mount on ./database, which appears to be involved in those reports.
Default fresh installs started by ./start.sh to the named-volume override on every platform. Existing installs with data in ./database are preserved on the bind mount and shown a migration warning instead of being silently switched, including when --arm is passed or an ARM host is auto-detected.
Add scripts/migrate-to-named-volume.sh, an opt-in helper that dumps the bind-mounted database, renames ./database to a timestamped backup directory, imports into a fresh named volume, verifies table set and per-table row counts, and only then pins the override in .env. The script supports a passwordless-sudo fallback for installs where the project directory is not directly writable, and refuses to run on ambiguous or non-default setups.
Centralize storage-mode detection in scripts/_env_helpers.sh so backup.sh and restore.sh share the same logic and refuse to act when both ./database and a named volume exist. Update README, DATABASE, DOCKER, INSTALLATION, DEVELOPMENT, and TROUBLESHOOTING docs to describe the new defaults and migration path.