Skip to content

fix: reduce bind-mount mariadb corruption risk#598

Merged
dialmaster merged 3 commits into
devfrom
fix/mitigate-DB-data-corruption-risk
May 7, 2026
Merged

fix: reduce bind-mount mariadb corruption risk#598
dialmaster merged 3 commits into
devfrom
fix/mitigate-DB-data-corruption-risk

Conversation

@dialmaster
Copy link
Copy Markdown
Collaborator

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.

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.
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 5, 2026

📊 Test Coverage Report

Backend Coverage

Type Coverage Status
Lines 82.65% 🟢
Statements 82.48% 🟢
Functions 84.33% 🟢
Branches 75.56% 🟡

Frontend Coverage

Type Coverage Status
Lines 86.26% 🟢
Statements 84.86% 🟢
Functions 76.49% 🟡
Branches 78.87% 🟡

Coverage Requirements

  • Minimum threshold: 70% line coverage
  • Backend: ✅ Passes
  • Frontend: ✅ Passes

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.
Comment thread scripts/migrate-to-named-volume.sh Outdated
Comment thread docs/DATABASE.md Outdated
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
@dialmaster dialmaster merged commit 282a51d into dev May 7, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants