spacedriveapp/spacedrive · critical · anyhow::Error

Unknown config key: {}

Error message

Unknown config key: {}

What it means

Wrapper error thrown when NetworkingService::new(device_manager, key_manager, data_dir, logger) fails during service initialization. The inner error string after the colon carries the actual cause — typically key-manager/crypto setup failures, data-dir I/O problems, or p2p stack (node identity) creation errors. On failure self.networking stays None, so later networking calls see an uninitialized service.

Source

Thrown at apps/cli/src/domains/config/mod.rs:61

			table.add_row(vec!["update.repo", &config.update.repo]);
			table.add_row(vec!["update.channel", &config.update.channel]);

			println!("{}", table);
			println!();
			println!(
				"Config file: {}",
				CliConfig::config_path(&data_dir).display()
			);
		}
		ConfigCmd::Get { key } => {
			let value = match key.as_str() {
				"current_library_id" => config
					.current_library_id
					.map(|id| id.to_string())
					.unwrap_or_else(|| "(not set)".to_string()),
				"update.repo" => config.update.repo.clone(),
				"update.channel" => config.update.channel.clone(),
				_ => return Err(anyhow::anyhow!("Unknown config key: {}", key)),
			};
			println!("{}", value);
		}
		ConfigCmd::Set { key, value } => match key.as_str() {
			"update.repo" => {
				config.set_update_repo(value.clone(), &data_dir)?;
				println!("Set update.repo = {}", value);
			}
			"update.channel" => {
				config.set_update_channel(value.clone(), &data_dir)?;
				println!("Set update.channel = {}", value);
			}
			_ => return Err(anyhow::anyhow!("Cannot set key: {}", key)),
		},
	}

	Ok(())
}

View on GitHub (pinned to 6dfeccf211)

Solutions

  1. Read the inner error text after the colon — it identifies which subsystem failed.
  2. Verify the data dir passed to init exists and is writable by the daemon user.
  3. Check key manager state files are present/valid (or remove them to force re-provisioning if re-pairing is acceptable).
  4. Re-run the daemon with RUST_LOG=sd_core::service=debug to get detailed initialization logs.

Example fix

# before
ls -la /var/lib/sd   # owned by root, daemon runs as 'sd'

# after
chown -R sd:sd /var/lib/sd && systemctl restart sd-daemon
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight the data dir before initializing networking.
use std::path::Path;

fn data_dir_ready(p: &Path) -> bool {
    p.exists() && p.is_dir() && writable(p)
}

fn writable(p: &Path) -> bool {
    std::fs::File::create(p.join(".writecheck")).and_then(|f| std::fs::remove_file(p.join(".writecheck")).map(|_| f)).is_ok()
}

Try / catch

match services.init_networking(device_mgr, key_mgr, &data_dir).await {
    Ok(()) => {}
    Err(e) => {
        tracing::error!(error = %e, "networking init failed; continuing without P2P");
        // degrade gracefully: mark networking unavailable, surface in health
    }
}

Prevention

When it happens

Trigger: Calling the init function at service/mod.rs:189 during daemon startup with an unreadable/unwritable data_dir, an uninitialized or corrupt key manager state, or missing OS networking prerequisites for the p2p stack.

Common situations: Fresh environment where the data dir permissions are wrong (daemon runs as different user); corrupted persisted node keys from a crash; containerized deployment missing /dev/net or required capabilities; disk full.

Related errors


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