zeroclaw-labs/zeroclaw · error

Failed to set restrictive ACL via icacls; key file permissio

Error message

Failed to set restrictive ACL via icacls; key file permissions may be insecure

What it means

After ownership, apply_windows_acl runs `icacls <path> /inheritance:r /grant:r <user>...` to strip inherited ACEs and grant only the current user. This error is the Ok-but-non-zero arm: icacls ran and refused, so the restrictive ACL was not established. Per the fail-closed contract, key publication aborts (temp file is removed) rather than leaving a key readable with inherited directory permissions. The WARN log above records icacls' exit code.

Source

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

    }

    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),
                &format!(
                    "Failed to set key file permissions via icacls (exit code {:?})",
                    o.status.code()
                )
            );
            anyhow::bail!(
                "Failed to set restrictive ACL via icacls; \
                 key file permissions may be insecure"
            );
        }
        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 set key file permissions"
            );
            anyhow::bail!(
                "Could not set key file permissions via icacls; \
                 key file permissions may be insecure"
            );
        }
        _ => {}

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Run `icacls <keydir>\<file> /inheritance:r /grant:r "%USERNAME%:F"` manually to see icacls' native error message
2. Move the key directory to a local NTFS volume with standard ACL support
3. If the username is unusual, provision under an account with a simple name, or pre-create the key file manually with correct ACLs so ZeroClaw only reads it

match provision_key(&path) {
    Err(e) if e.to_string().contains("Failed to set restrictive ACL via icacls") => {
        eprintln!("run manually to see the native error: icacls {} /inheritance:r /grant:r \"%USERNAME%:F\"", path.display());
        eprintln!("if the volume lacks ACL support (FAT/network), move the key dir to local NTFS");
    }
    other => other?,
}

When it happens

Trigger: icacls rejects the grant argument (username with unusual characters that build_windows_icacls_grant_arg escaped into an invalid ACE string); applying to a file on a filesystem without ACL support (FAT32 USB, some network shares → icacls "not supported"); group policy/ownership mismatch denying the DACL write; SID resolution failure for the user.

Common situations: ZeroClaw data on a FAT/exFAT drive or SMB share where NTFS ACLs do not apply; usernames with domain prefixes or special characters; the earlier takeown succeeded partially so the DACL write is denied.

Related errors

• Cannot determine current username; ACL hardening is required
• Failed to take ownership of key file via takeown; cannot est
• Could not set key file permissions; key file permissions may
• Could not take ownership of key file; cannot establish restr
• The '{}' backend does not support automatic key generation.

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