astrid-runtime/astrid · error
trusted Windows parent has a null DACL: {description}
Error message
trusted Windows parent has a null DACL: {description} What it means
The library treats its trusted parent directories (e.g. the private base folder) as part of the security boundary: only trusted principals may hold write/delete authority there. Before checking ACEs it reads the parent handle's security descriptor via GetSecurityInfo; if the descriptor has a null DACL (everyone has full control), it raises io::ErrorKind::PermissionDenied with this message.
Source
Thrown at crates/astrid-core/src/platform_fs/windows/acl.rs:625
// valid for the duration of the call.
let status = unsafe {
GetSecurityInfo(
handle,
SE_FILE_OBJECT,
OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION,
&raw mut owner,
null_mut(),
&raw mut dacl,
null_mut(),
&raw mut descriptor,
)
};
if status != ERROR_SUCCESS {
return Err(io::Error::from_raw_os_error(status.cast_signed()));
}
let allocation = LocalAllocation(descriptor);
let result = if dacl.is_null() {
Err(io::Error::new(
io::ErrorKind::PermissionDenied,
format!("trusted Windows parent has a null DACL: {description}"),
))
} else {
// SAFETY: GetSecurityInfo returned `dacl` inside the descriptor
// allocation retained by `allocation`.
unsafe { ValidatedAcl::from_raw(dacl, &allocation, description) }.and_then(|acl| {
validate_trusted_parent_acl_parts(&required, owner, &acl, dangerous_access, description)
})
};
drop(allocation);
result
}
fn validate_trusted_parent_acl_parts(
required: &RequiredSids,
owner: PSID,
acl: &ValidatedAcl<'_>,View on GitHub (pinned to affd8760f4)
Solutions
- Move the private root to an NTFS volume; ACL-less filesystems (FAT32/exFAT/network shares) cannot pass validation.
- Restore a proper DACL on the parent: `icacls <parent> /inheritance:r /grant:r "%USERNAME%":F /grant:r SYSTEM:F /grant:r Administrators:F`.
- Recreate the parent directory through the library's private-creation path.
- Stop backup/sync tools from resetting security descriptors on the private root.
Example fix
// before: private root on a FAT32 volume (no DACL support) let base = "E:\\priv"; // exFAT USB drive // after: use an NTFS location let base = "C:\\ProgramData\\myapp\\priv";
Defensive patterns
Strategy: validation
Validate before calling
// Ensure the parent has a real DACL before pointing the library at it (PowerShell):
// $acl = Get-Acl C:\priv-root
// if ($acl.Access.Count -eq 0) { throw "parent has null DACL - recreate on NTFS" }
// (Also confirm the volume is NTFS: Get-Volume -DriveLetter C | Select FileSystem) Prevention
- Place the trusted parent on an NTFS volume.
- Let the library create the parent directory itself rather than pre-creating it with other tooling.
- Prevent backup/restore jobs from stripping security descriptors on the parent.
When it happens
Trigger: validate_trusted_parent_acl_handle or validate_trusted_parent_acl_for_create_handle reads a trusted parent directory handle whose security descriptor reports a null DACL.
Common situations: The parent directory was created by other software without a DACL, its ACL was reset by icacls/backup tooling, or the directory lives on a filesystem (e.g. FAT32/exFAT) that does not support ACLs.
Understand the failure class
Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.
Related errors
- private Windows path has a null DACL: {description}
- private Windows path ACL is not restricted to the current us
- PermissionDenied
- mountpoint ancestor is writable without sticky protection: {
- Windows named-pipe endpoint denied access
AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09).
Data as JSON: /api/errors/f9733641704ce2c4.
Report an issue: GitHub.