Problem
The native MariaDB provider can report descriptor readiness as ready, then fail every real service allocation because the FUSE-mounted ext4 data directory is not writable by mariadb-install-db.
Reproduction
On an unprivileged Linux host with the complete documented toolchain (mariadbd, mariadb-install-db, mariadb, prlimit, truncate, mkfs.ext4, fuse2fs, fusermount3):
- Run runtime descriptor discovery and observe native MariaDB
ready.
- Allocate the same native MariaDB service through a recipe.
- Observe initialization failure inside the mounted image:
Can't create test file ... Errcode: 13 "Permission denied"
Can't create/write to file './ddl_recovery.log'
The FUSE mount is created with root_owner=<caller uid>:<caller gid>, but the real initializer cannot write through it. The lightweight readiness probe does not exercise the same initialization path and therefore returns a false positive.
Expected contract
- Native readiness executes the same ownership/write semantics required by real
mariadb-install-db.
- A
ready descriptor guarantees that a disposable native MariaDB allocation can initialize and reach service readiness.
- FUSE mount ownership permits the unprivileged provider-owned initializer while preserving the existing bounded filesystem and cleanup guarantees.
- If host FUSE semantics are incompatible, descriptor readiness returns a stable unavailable reason before recipe execution.
Acceptance criteria
- Deterministic integration coverage reproduces real initialization through the mounted ext4 image.
- Fix mount ownership/options or initialization ownership without weakening UID, path, geometry, resource, or teardown validation.
- Descriptor probe and real allocation share one provisioning primitive or prove equivalent semantics.
- Permission failure retains bounded lifecycle diagnostics and verified cleanup.
- Dedicated native MariaDB integration passes on the affected unprivileged Linux host.
Existing tracker review
Closed #2225 covers PHP.Wasm managed-database environment bridging and closed #2227 covers connection diagnostics. Neither covers descriptor readiness succeeding while real native FUSE initialization is unwritable.
AI assistance
OpenAI GPT-5.6 Sol (gpt-5.6-sol) via OpenCode reproduced the native allocation, inspected lifecycle evidence and MariaDB initialization output, deduplicated existing trackers, and drafted this report under Chris Huber's direction. Chris remains responsible for the report.
Problem
The native MariaDB provider can report descriptor readiness as
ready, then fail every real service allocation because the FUSE-mounted ext4 data directory is not writable bymariadb-install-db.Reproduction
On an unprivileged Linux host with the complete documented toolchain (
mariadbd,mariadb-install-db,mariadb,prlimit,truncate,mkfs.ext4,fuse2fs,fusermount3):ready.The FUSE mount is created with
root_owner=<caller uid>:<caller gid>, but the real initializer cannot write through it. The lightweight readiness probe does not exercise the same initialization path and therefore returns a false positive.Expected contract
mariadb-install-db.readydescriptor guarantees that a disposable native MariaDB allocation can initialize and reach service readiness.Acceptance criteria
Existing tracker review
Closed #2225 covers PHP.Wasm managed-database environment bridging and closed #2227 covers connection diagnostics. Neither covers descriptor readiness succeeding while real native FUSE initialization is unwritable.
AI assistance
OpenAI GPT-5.6 Sol (
gpt-5.6-sol) via OpenCode reproduced the native allocation, inspected lifecycle evidence and MariaDB initialization output, deduplicated existing trackers, and drafted this report under Chris Huber's direction. Chris remains responsible for the report.