What causes "Could not determine binary directory" in spacedriveapp/spacedrive?

Run the CLI from a normal absolute install path (e.g. ~/.local/bin/sd) and retry

spacedriveapp/spacedrive · error · anyhow::Error

Could not determine binary directory

Error message

Could not determine binary directory

What it means

The updater takes std::env::current_exe() and asks for its parent directory to decide where to install 'sd' and 'sd-daemon'. parent() returned None, meaning the executable path is degenerate (empty or a root-like path). This is a defensive guard for a condition that is nearly impossible on healthy systems.

Source

Thrown at apps/cli/src/domains/update/mod.rs:91

	let daemon_asset = latest_release
		.assets
		.iter()
		.find(|a| a.name.contains(&platform) && a.name.contains("sd-daemon"))
		.ok_or_else(|| {
			anyhow::anyhow!("Could not find sd-daemon binary for platform: {}", platform)
		})?;

	println!("Downloading updates...");

	// Download binaries
	let sd_data = download_file(&sd_asset.browser_download_url, sd_asset.size).await?;
	let daemon_data = download_file(&daemon_asset.browser_download_url, daemon_asset.size).await?;

	// Get current binary paths
	let current_exe = std::env::current_exe()?;
	let bin_dir = current_exe
		.parent()
		.ok_or_else(|| anyhow::anyhow!("Could not determine binary directory"))?;

	let sd_path = bin_dir.join("sd");
	let daemon_path = bin_dir.join("sd-daemon");

	println!();
	println!("Installing updates...");

	// Check if daemon is running
	let daemon_was_running = check_daemon_running(&data_dir).await;
	if daemon_was_running {
		println!("Stopping daemon...");
		stop_daemon(&data_dir).await?;
	}

	// Perform atomic replacement
	replace_binary(&sd_path, &sd_data)?;
	replace_binary(&daemon_path, &daemon_data)?;

View on GitHub (pinned to 6dfeccf211)

Solutions

Run the CLI from a normal absolute install path (e.g. ~/.local/bin/sd) and retry
Reinstall both binaries with well-formed paths
Patch the updater to accept an explicit --bin-dir override if you hit this in automation

Defensive patterns

Strategy: fallback

Validate before calling

fn bin_dir() -> anyhow::Result<std::path::PathBuf> {
    std::env::current_exe()
        .ok()
        .and_then(|p| p.parent().map(|d| d.to_path_buf()))
        .or_else(|| std::env::var("SD_BIN_DIR").ok().map(std::path::PathBuf::from))
        .ok_or_else(|| anyhow::anyhow!("Could not determine binary directory; set SD_BIN_DIR"))
}

Try / catch

let bin_dir = match current_exe.parent() {
    Some(d) => d.to_path_buf(),
    None => std::path::PathBuf::from("/usr/local/bin"), // documented fallback
};

Prevention

Invoke the CLI via an absolute path from a real directory, never from a degenerate path
Offer an explicit --bin-dir flag in the updater so install location never depends on argv heuristics
Treat hitting this error as an environment smell worth investigating, not a code bug

When it happens

Trigger: Executing the CLI in a sandbox/namespace where /proc/self/exe resolves to something without a parent component; a broken exec chain returning an empty argv[0]-derived path.

Common situations: Exotic containers or chroots; essentially never seen in normal desktop/server use.

Related errors

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