zeroclaw-labs/zeroclaw · error

Could not take ownership of key file; cannot establish restr

Error message

Could not take ownership of key file; cannot establish restrictive ACL

What it means

The Err(e) arm of the same `takeown /F` invocation in apply_windows_acl: the process could not be spawned at all (as opposed to exiting non-zero). The spawn error is logged as a WARN with its io::Error text, then key publication aborts fail-closed. Typical cause is takeown.exe missing from PATH (hardened/stripped Windows images, bad PATH in service contexts); other causes include the process being blocked by policy.

Source

Thrown at crates/zeroclaw-config/src/secrets.rs:873

                &format!(
                    "Failed to take ownership of key file via takeown (exit code {:?})",
                    o.status.code()
                )
            );
            anyhow::bail!(
                "Failed to take ownership of key file via takeown; \
                 cannot establish restrictive ACL"
            );
        }
        Err(e) => {
            ::zeroclaw_log::record!(
                WARN,
                ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Note)
                    .with_outcome(::zeroclaw_log::EventOutcome::Unknown)
                    .with_attrs(::serde_json::json!({"error": format!("{}", e)})),
                "Could not take ownership of key file"
            );
            anyhow::bail!(
                "Could not take ownership of key file; \
                 cannot establish restrictive ACL"
            );
        }
        _ => {}
    }

    match std::process::Command::new("icacls")
        .arg(path)
        .args(["/inheritance:r", "/grant:r"])
        .arg(grant_arg)
        .output()
    {
        Ok(o) if !o.status.success() => {
            ::zeroclaw_log::record!(
                WARN,
                ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Note)
                    .with_outcome(::zeroclaw_log::EventOutcome::Unknown),

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Verify takeown.exe exists and is on PATH in the launch context: `where takeown` from the same shell/service account
2. Provision the key interactively first (`zeroclaw quickstart` in a full user session), so later runs only read the existing key
3. Fix PATH for the service/unit definition to include System32

#[cfg(windows)]
fn takeown_available() -> bool {
    std::process::Command::new("where").arg("takeown").output()
        .map(|o| o.status.success()).unwrap_or(false)
}

if let Err(e) = provision_key(&path) {
    if e.to_string().contains("Could not take ownership") {
        eprintln!("takeown could not be launched — check PATH/System32 and execution policy in this context");
    }
}

When it happens

Trigger: Key creation on Windows in an environment where `takeown` cannot launch: PATH stripped or broken in a service/scheduled task; Windows container/nanoserver image without takeown.exe; application-whitelisting policy (AppLocker/WDAC) denying the spawn.

Common situations: Running ZeroClaw under Windows Server Core/containers lacking the full toolset; CI agents with minimal PATH; corporate endpoints with strict execution control.

Related errors

• Failed to take ownership of key file via takeown; cannot est
• Could not set key file permissions; key file permissions may
• Cannot determine current username; ACL hardening is required
• Failed to set restrictive ACL via icacls; key file permissio
• Key file path is a reparse point — refusing to read

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/77c17f8a28794b15. Report an issue: GitHub.