SQLite fail on SMB-mounted filesystems #473

Describe the bug

Running crush with a project directory on an SMB-mounted share causes SQLite migrations to fail with: Failed to apply migrations: sqlite3: disk I/O error; sqlite3: disk I/O error.

This only occurs over SMB/CIFS; the same workflow on a local filesystem succeeds. This strongly suggests SQLite’s WAL/journal/locking/fsync behavior is incompatible with common SMB mount defaults. Crush currently assumes a POSIX-local FS and does not provide a way to mitigate this (e.g., redirect DB to a local path or change SQLite PRAGMAs), so users on SMB shares hit a hard failure during startup/migrations.

Setup

• OS: macOS Sequoia 15.5
  • Hardware: MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)
  • CPU: 2.8 GHz Quad‑Core Intel Core i7
  • RAM: 16 GB 2133 MHz LPDDR3
  • GPU: Intel Iris Plus Graphics 655 1536 MB
• Shell: zsh
• Terminal Emulator: iTerm2 (also reproduced in Apple Terminal)
• Locale: UTF-8
• Storage: Project directory on SMB/CIFS share (mounted via Finder/mount_smbfs).

To Reproduce

1. Mount an SMB share (e.g., macOS Finder or mount_smbfs; on Linux, mount -t cifs with default options).
2. cd into a project directory on the SMB share.
3. Run crush (e.g., crush or crush --debug).
4. Observe error during initialization/migrations:
   Failed to apply migrations: sqlite3: disk I/O error; sqlite3: disk I/O error.

Note: Moving the project to a local disk avoids the issue. But this is not acceptable in my shared environment, as my development server is where I make code edits.

Expected behavior

Crush should either:

• Work reliably when the working directory is on SMB; or
• Detect that the DB is on a network filesystem and automatically choose safe SQLite settings; or
• Provide configuration to store Crush’s SQLite DB/state on a local path (e.g., $HOME/.config/crush) even when the project is on SMB, and/or allow overriding SQLite PRAGMAs (journal mode, synchronous, temp store).

Screenshots

N/A, here is the CLI output: Failed to apply migrations: sqlite3: disk I/O error; sqlite3: disk I/O error.

Additional context

• Root cause appears to be SQLite’s interaction with SMB locking/fsync semantics. Many SMB/CIFS mounts don’t fully support POSIX locking and durable handles by default, which can break SQLite WAL/journaling and manifests as disk I/O errors.
• Workarounds outside Crush include:
  • Running the project locally (works).
  • Tweaking SMB mount options (not always feasible for end users).
  • Forcing SQLite to non-WAL journaling (requires Crush to expose PRAGMAs).
• Proposed fixes/enhancements for Crush:
  1. Allow configuring the Crush DB/state directory separately from the project path (e.g., via crush.json or env var), so it can live on a local filesystem when projects are remote.
  2. Expose SQLite PRAGMA configuration in crush.json (e.g., journal_mode=DELETE or TRUNCATE; synchronous=FULL/NORMAL; temp_store=MEMORY).
  3. Auto-detect network filesystems (best-effort) and default to a safer SQLite mode when detected, or warn and suggest moving DB to a local path.
  4. Improve error messaging to indicate likely network-FS/locking cause and provide actionable guidance.

Implementing one or more of the above would make Crush more robust in environments where projects are on SMB shares.