spacedriveapp/spacedrive · error · anyhow::Error

Could not determine binary directory

Error message

Could not determine binary directory

What it means

Returned by the sync transport's request path when the in-memory device registry (a read-guarded map) has no NodeId mapping for the target device UUID. The registry only knows paired-and-connected devices, so the message names the two causes directly: the device was never paired with this instance, or it is currently offline/disconnected. This fails before any stream is opened.

Source

Thrown at apps/cli/src/domains/daemon/mod.rs:47

		dirs::home_dir().ok_or_else(|| anyhow::anyhow!("Could not determine home directory"))?;
	let launch_agents_dir = home.join("Library/LaunchAgents");

	// Create LaunchAgents directory if it doesn't exist
	fs::create_dir_all(&launch_agents_dir)?;

	// Determine plist filename based on instance
	let plist_name = if let Some(ref inst) = instance {
		format!("com.spacedrive.daemon.{}.plist", inst)
	} else {
		"com.spacedrive.daemon.plist".to_string()
	};
	let plist_path = launch_agents_dir.join(&plist_name);

	// Get the current daemon binary path
	let current_exe = std::env::current_exe()?;
	let daemon_path = current_exe
		.parent()
		.ok_or_else(|| anyhow::anyhow!("Could not determine binary directory"))?
		.join("sd-daemon");

	if !daemon_path.exists() {
		return Err(anyhow::anyhow!(
			"Daemon binary not found at {}. Ensure both 'sd-cli' and 'sd-daemon' are in the same directory.",
			daemon_path.display()
		));
	}

	// Determine log paths
	let log_dir = data_dir.join("logs");
	fs::create_dir_all(&log_dir)?;
	let stdout_log = log_dir.join("daemon.out.log");
	let stderr_log = log_dir.join("daemon.err.log");

	// Build program arguments
	let mut program_args = vec![
		daemon_path.to_string_lossy().to_string(),

View on GitHub (pinned to 6dfeccf211)

Solutions

  1. Verify the device is paired (check the pairing/registry state via the device API) and re-pair if not.
  2. Confirm the target daemon is running and connected; wait for it to reappear in the registry after restarts.
  3. Validate the UUID being passed matches the currently paired device (not an old identifier).
  4. Retry the request once the peer reconnects — this is a connectivity-precondition failure, not a message-format problem.

Example fix

// before
transport.send_request(device_uuid, request).await?; // errors if offline

// after (check registry first)
let online = {
    let reg = device_registry.read().await;
    reg.get_node_id_for_device(device_uuid).is_some()
};
if !online {
    // wait for reconnect / prompt user; do not send
    return Err(anyhow::anyhow!("device offline, retry later"));
}
transport.send_request(device_uuid, request).await?;
Defensive patterns

Strategy: validation

Validate before calling

// Check the registry before sending; avoid the round trip entirely.
async fn device_available(
    registry: &tokio::sync::RwLock<DeviceRegistry>,
    device: uuid::Uuid,
) -> bool {
    registry.read().await.get_node_id_for_device(device).is_some()
}

Try / catch

match transport.send_request(target_device, request).await {
    Ok(resp) => Ok(resp),
    Err(e) if e.to_string().contains("not found in registry") => {
        // precondition failure: prompt pairing or wait for reconnect; do not blind-retry
        Err(mark_device_offline(target_device, e))
    }
    Err(e) => Err(e),
}

Prevention

When it happens

Trigger: Calling send_request (or any transport API resolving device UUID → NodeId) for a device that has not completed pairing with this node, or one whose connection dropped so it was removed from the live registry.

Common situations: Trying to sync before finishing the pairing handshake; target daemon restarted and not yet reconnected; registry populated per-session so a daemon restart clears it until peers reconnect; stale device UUID persisted by a client.

Related errors


AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16). Data as JSON: /api/errors/f7ac7340ff47783d. Report an issue: GitHub.