refusing to delete pre-existing snapshot {}: outside grok-ma

Error message

refusing to delete pre-existing snapshot {}: outside grok-managed btrfs storage

What it means

`create_snapshot_with_symlink` refuses to remove a pre-existing snapshot path because `is_safe_snapshot_delete_target` determined it lies outside the grok-managed btrfs storage area. This is a safety guard: the library will not delete anything it does not own, so snapshot creation aborts rather than clobbering an unknown path.

Source

Thrown at crates/codegen/xai-fast-worktree/src/btrfs/snapshot.rs:143

        })?;
    }

    // A pre-existing entry here would be deleted with btrfs privileges, so guard it:
    // unlink a planted symlink, and only `btrfs delete` a real contained subvolume
    // whose sibling metadata proves it belongs to THIS `dest` (never another session's).
    if snapshot_path.exists() {
        if snapshot_path
            .symlink_metadata()
            .is_ok_and(|m| m.file_type().is_symlink())
        {
            std::fs::remove_file(&snapshot_path).with_context(|| {
                format!(
                    "failed to remove planted symlink at {}",
                    snapshot_path.display()
                )
            })?;
        } else if !is_safe_snapshot_delete_target(&snapshot_path) {
            bail!(
                "refusing to delete pre-existing snapshot {}: outside grok-managed \
                 btrfs storage",
                snapshot_path.display()
            );
        } else {
            match snapshot_meta_state(&snapshot_path, dest) {
                // Recreate a stale snapshot for this worktree, or reclaim a
                // crashed-creation orphan whose metadata was never written; the
                // is_safe check above keeps the delete inside managed storage.
                SnapshotMetaState::Matches | SnapshotMetaState::Absent => {
                    tracing::warn!(
                        snapshot_path = %snapshot_path.display(),
                        "snapshot path already exists for this worktree, recreating"
                    );
                    delete_snapshot(&snapshot_path)?;
                }
                // Metadata proves a different session owns it — never delete.
                SnapshotMetaState::Mismatch => bail!(

View on GitHub (pinned to bc7f02eddd)

Solutions

Inspect the existing path from the error message; if it's not yours, choose a different dest/snapshot name and delete it manually.
If it's a stale artifact you own, delete it yourself (e.g. `rm -rf` / `btrfs subvolume delete` as appropriate) and re-run creation.
Verify your configured btrfs storage root matches the one used previously — a mismatch makes valid snapshots look 'outside managed storage'.
Align snapshot naming so concurrent/legacy sessions don't collide at the same path.
If it's a planted symlink scenario, note the library already removes symlinks safely; this error means the target is a real entry, so manual intervention is required.

Example fix

// before
// /mnt/btrfs/snapshots/wt-42 exists but was created outside the managed root
create_snapshot_with_symlink(&src, &dest)?; // refuses
// after
// manually reclaim the path first (verify ownership!)
// $ btrfs subvolume show /mnt/btrfs/snapshots/wt-42 || rm -rf /mnt/btrfs/snapshots/wt-42
create_snapshot_with_symlink(&src, &dest)?;

Defensive patterns

Strategy: validation

Validate before calling

use std::path::Path;
fn snapshot_path_is_reclaimable(snapshot_path: &Path) -> bool {
    !snapshot_path.exists()
        || is_safe_snapshot_delete_target(snapshot_path) // library helper
        || snapshot_path.is_symlink() // symlinks are removed automatically
}

Type guard

fn is_managed_snapshot(path: &Path, managed_root: &Path) -> bool {
    path.canonicalize()
        .map(|p| p.starts_with(managed_root.canonicalize().unwrap()))
        .unwrap_or(false)
}

Try / catch

match create_snapshot_with_symlink(&src, &dest) {
    Err(e) if e.to_string().contains("outside grok-managed") => {
        eprintln!("stale/unmanaged path at snapshot location: {e}");
        // require human verification before removing the path manually
    }
    r => r?,
}

Prevention

Use unique snapshot paths per worktree/session to avoid collisions
Keep the configured btrfs storage root consistent across versions and machines
Never create files manually inside the managed snapshot directory
Before reusing a dest, check whether the snapshot path already exists and clean it deliberately

When it happens

Trigger: Calling `create_snapshot_with_symlink` when the computed `snapshot_path` already exists on disk as a real file/directory/symlink that is not within the managed btrfs storage root (fails the safety check), and it is not a symlink that could be safely removed.

Common situations: A stale snapshot left by a different tool or an older library layout; user-created directory at the snapshot path; misconfigured snapshot root so the managed path resolves elsewhere; reusing a dest name across unrelated sessions.

Related errors

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/6305dbb48ba6d85e. Report an issue: GitHub.