Failed to take ownership of key file via takeown; cannot…

Error message

Failed to take ownership of key file via takeown; cannot establish restrictive ACL

What it means

apply_windows_acl runs `takeown /F <temp-key-path>` to make the current user the owner before applying a restrictive ACL (temp files inherit the parent directory's ACL on Windows, which may grant broader access). This error fires when takeown executes but exits non-zero — ownership was not established, so the hardening chain aborts and the temp key file is removed (TempFileGuard). The WARN log line just above records the exact exit code.

Solutions

Move the ZeroClaw key directory to a plain local path (e.g. under %USERPROFILE%) instead of a network/synced location
Check the WARN log entry for the takeown exit code and run `takeown /F <file>` manually in the same directory to see the native error
Exclude the ZeroClaw key directory from antivirus/sync real-time scanning, then retry provisioning

Defensive patterns

Strategy: retry

Try / catch

match provision_key(&path) {
    Err(e) if e.to_string().contains("take ownership of key file via takeown") => {
        // check the WARN log line for the exit code; common fix is moving off network/synced dirs
        eprintln!("takeown failed — move the key dir to a local NTFS path and exclude it from AV/sync");
        // safe to retry: no key was published
    }
    other => other?,
}

Prevention

Keep ~/.zeroclaw on a local NTFS volume, not SMB/FAT/synced folders
Exclude the key directory from antivirus and sync real-time scanning
Provision the key once in a normal session so services never hit this path

When it happens

Trigger: takeown fails on the just-created temp file: path on a network share/UNC where takeown semantics differ; file claim races with antivirus handles; restricted users lacking TakeOwnership privileges on the object; PATH resolves a broken takeown shim that exits non-zero. Only reachable on Windows during key creation.

Common situations: ZeroClaw home directory redirected to a synced/network drive (OneDrive, SMB share); locked-down corporate machines where ownership changes are denied; AV/security agents holding exclusive handles on new .tmp files.

Related errors

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

Appendix: source

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

        );
    };

    match std::process::Command::new("takeown")
        .arg("/F")
        .arg(path)
        .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),
                &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"
            );
        }
        _ => {}

View on GitHub (pinned to 88bb9c8533)