Custom node data location fails on macOS with NAS (SMB mount)

[brianp]

Bounty: Fix Custom Node Data Location on macOS with NAS (SMB Mount)

Tier: M — 60,000 XTM

Description

The custom node data location feature (merged in PR #3068) does not work on macOS when the target directory is a NAS via SMB mount. Users selecting a network-mounted path encounter an error when attempting to move/use the node data on the remote volume. Investigate and fix the issue so that SMB-mounted volumes work, or provide a clear error message explaining the limitation.

Acceptance Criteria

• The failure when using a NAS (SMB mount) as the custom node data location on macOS is reproduced and root-caused
• Either: the fix allows SMB-mounted volumes to work end-to-end, or: the UI detects network-mounted paths and shows a clear error message before attempting the move
• Root cause and chosen approach are documented in the PR description

Context

• Issue opened by @brianp
• Original feature: Mainnet db is huge (116Gb) : can we move it elsewhere ? #3057 (Mainnet db is huge, can we move it elsewhere?)
• Pitch: [Pitch] Install Directory Settings #2304 (Install Directory Settings)
• Implementation: PR feat: node data location settings #3068 (feat: node data location settings)
• Platform: macOS 15.7.3, NAS local network SMB mount

How to Claim

1. Comment on this issue to signal intent (courtesy, not a lock)
2. Fork the repo and do the work
3. Submit a PR that meets the acceptance criteria
4. First PR that passes review and gets merged wins the bounty
5. On acceptance, XTM payment is processed

Notes

• AI-assisted development is expected and encouraged
• If you get stuck, ask in Discord
• If you can't complete it within 14 days of claiming, let us know so someone else can pick it up

[jhaayushkumar]

@brianp assign this to me i want to work on this issue

[metalaureate]

Original issue description (preserved before bounty rewrite)

Description

The custom node data location feature (merged in #3068, closing #3057) does not work on macOS when the target directory is a NAS via SMB mount. Users selecting a network-mounted path encounter an error when attempting to move/use the node data on the remote volume.

Related:

• Original issue: Mainnet db is huge (116Gb) : can we move it elsewhere ? #3057
• Pitch: [Pitch] Install Directory Settings #2304
• Implementation PR: feat: node data location settings #3068

Platform: macOS 15.7.3, NAS local network SMB mount

Acceptance criteria

• Validate and reproduce the failure when using a NAS (SMB mount) as the custom node data location on macOS
• Fix the issue so that network-mounted volumes are supported, or provide a clear error message explaining the limitation
• Custom node data location works end-to-end on macOS with an SMB-mounted NAS

Size: M

[Ltbltbltbltb]

Your PR #3068 adds custom node data location support, but it fails when users point to an SMB-mounted NAS on macOS—likely due to path handling differences or permission/capability restrictions on network mounts.

I'll start by reproducing the error locally (macOS + SMB mount simulation), then trace the data location code to identify the break point. Common culprits: hardcoded path assumptions that don't account for network mounts, missing capability checks before filesystem operations (rename, lock files), or symlink/mount point resolution issues specific to macOS/SMB.

The fix will either:

1. Enable SMB volumes by handling mount-specific edge cases (respecting SMB permission models, avoiding unsupported operations), or
2. Detect and reject gracefully, validating the path before the move and showing users exactly why SMB mounts aren't supported with clear error messaging and documentation.

I'll document the root cause and chosen approach in the PR description.

Timeline: 1–2 days (reproduction, investigation, implementation, acceptance criteria verification).

What specific error message or behavior occurs when the move fails—does it hang, throw a filesystem exception, or silently create a broken reference?

[0xPepeSilvia]

Claiming this bounty. Will have a PR up within the 14-day window.