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
- Read the inner error text after the colon — it identifies which subsystem failed.
- Verify the data dir passed to init exists and is writable by the daemon user.
- Check key manager state files are present/valid (or remove them to force re-provisioning if re-pairing is acceptable).
- 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
- Provision data-dir ownership/permissions in deployment (chown to daemon user).
- Fail startup loudly with the inner error; do not swallow the wrapper without logging the cause.
- Health-check networking availability (services.networking().is_some()) before offering sync features.
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
- Cannot set key: {}
- Could not determine home directory
- Could not determine binary directory
- File transfer protocol not registered
- No library selected
AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16).
Data as JSON: /api/errors/2dcb683abed3b18f.
Report an issue: GitHub.