Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
JSI Tip 10080 is a January 23, 2006 guide to FileACL.exe 2.8.0.1, a freeware command-line utility for viewing and changing permissions on NTFS files and folders. It documents useful capabilities—including recursive ACL changes, ownership changes, inheritance controls, raw SID handling, and permission export—but it is historical documentation, not evidence that the utility is currently supported or safe to download. On modern Windows systems, use Microsoft’s icacls, takeown, or PowerShell instead.
What JSI Tip 10080 says
The original JSI Tip 10080, written by Jerold Schulman and published January 23, 2006, describes FileACL.exe version 2.8.0.1, credited to Guillaume Bordier. Its context is Windows NT 4.0 and Windows 2000-era NTFS administration. The page’s historical statement that the program could be downloaded from Microsoft does not establish that Microsoft hosts, supports, or verifies the executable today.
According to that documentation, FileACL could display and edit ACLs on local or remote NTFS paths; grant, set, revoke, or deny permissions; change ownership; recurse through directory trees; control inheritance; work with raw SIDs and access masks; and generate batch instructions for later permission reapplication. Those features made it relevant to legacy recovery and migration work. They do not make it a prudent default for a current production system.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →ACLs, ownership, and inheritance in brief
An access control list (ACL) is made up of access control entries (ACEs). Each ACE identifies a user or group (the trustee), an allow or deny decision, rights, and possibly inheritance behavior. A file or folder’s discretionary ACL (DACL) governs access checks. Its owner is a separate security-descriptor field; ownership can permit changes to the DACL under Windows security rules, but does not automatically grant every desired right. The system ACL (SACL) is used for auditing and requires additional privileges to read or change.
Some ACEs are explicit on an object; others are inherited from a parent. Inheritance settings matter beyond the current directory: an ACE can apply to the directory itself, files below it, child directories, or only descendants. Windows file-security concepts are described in Microsoft’s file security and access rights documentation.
How to read the legacy FileACL syntax
The JSI page gives a compact form resembling:
FILEACL [/{S|G|R|T|O|D} trustee:RWXDOPF] [options]This is a historical outline, not a verified syntax reference for a current executable. The principal operations described are:
/S: set rights for a trustee, replacing that trustee’s related ACEs./G: grant or enlarge rights./R: revoke the trustee by removing related ACEs./T: the article describes this as suppressing deny ACEs for the trustee./O: change ownership; the article notes that the Take Ownership privilege is required./D: add a deny ACE.
The legacy rights letters include R (read), W (write), X (directory change/traverse or file execute, depending on object), D (delete), O (ownership-related right), P (write permissions), and F (full rights in the article’s examples). It also lists U for unspecified or zero rights. These are shorthand, and directory rights are not identical to file rights. Avoid translating a compact legacy string by guesswork: inspect the resulting ACL and effective access.
Free tools Windows power users keep installed
One-click scans. No signup required.
Other documented switches include /SUB:n for subdirectory levels, /FILES to include files, /NODIRS to process files only, /NOROOT to skip the root when processing descendants, /FORCE to use backup and restore privileges, /PROTECT to stop parent propagation, /INHERIT to force inheritance, and /REPLACE to replace the existing ACL. Display options include /OWNER, /ADVANCED, /NOINHERITED, /RAW, and /BATCH. The old page also lists error codes 100–109 for usage, operating-system version, syntax, path, filesystem, ACL, ownership, listing, directory-reading, and inheritance-flag errors; they should not be assumed exhaustive or identical across builds.
Rank #2
Historical examples from the 2006 page
The following commands illustrate what the article documented. They are not recommendations to run an unverified legacy binary on a current system.
FILEACL d:tempacltest /S user1:RWThe page presents this as setting read/write access for user1 on the target directory. The precise treatment of descendants depends on the utility’s syntax and options.
FILEACL \serversharedir /S admingroup1:F /S usergroup1:RX/W/D /O admingroup1 /SUB:3 /FILESThis example combines grants, ownership change, and recursive processing of files and three directory levels. Such a broad combination can change access across a production share; do not run it without testing on a copy and capturing the original ACL.
FILEACL \serversharedir /S S-1-5-21-1606980848-1383384898-842925246-1008:RThe article says FileACL could apply rights using a SID when an account could not be resolved. Treat that as a claim about the documented legacy utility, not proof that modern tools accept identical syntax.
Rank #3
- Used Book in Good Condition
FILEACL d:tempacltest /INHERIT /REPLACEThe page describes this as resetting permissions so parent permissions propagate. Because replacement can remove explicit ACEs, regard it as destructive until you have inspected the result and confirmed a rollback path.
Inheritance: legacy codes versus icacls flags
The JSI article uses compact codes such as FO, FSF, SFF, and NP to express combinations of folder, subfolder, and file propagation. It also discusses Windows-style inheritance flags. In current icacls syntax, (OI) means object inherit (commonly files), (CI) means container inherit (commonly directories), (IO) means inherit only, and (NP) means do not propagate further. These flags are easier to review explicitly, but still require care: an inherited ACE can affect future descendants, not just the objects present when you run a command.
Modern replacements on Windows
For supported Windows command-line ACL work, Microsoft documents icacls. Run commands in an elevated shell when the operation requires administrative rights, and quote paths containing spaces.
Inspect permissions
icacls "C:Data"
icacls "C:Data" /T /CThe first command displays permissions for the path. The second walks the tree; /C continues after errors, so review its output rather than interpreting a successful process exit as proof every item was handled.
Grant rights with inheritance
icacls "C:Data" /grant "DOMAINUser":(OI)(CI)MThis grants Modify and marks the ACE to inherit to files and subdirectories. Common permission abbreviations include F (full), M (modify), RX (read and execute), R (read), and W (write). Shell parsing and quoting can differ between Command Prompt and PowerShell; test the exact command in the shell you intend to use.
To replace previously granted explicit permissions for that trustee rather than simply add a grant, icacls provides:
icacls "C:Data" /grant:r "DOMAINUser":MReplacement is not a generic repair operation. Inspect the existing ACL first, and understand whether inherited entries remain relevant.
Remove a grant or denial
icacls "C:Data" /remove:g "DOMAINUser"This removes grant ACEs for the specified trustee on the target. Use the documented remove forms deliberately; removing a deny or grant can materially change access. Microsoft lists the supported operations and syntax in the icacls reference.
Best Value
Save and restore DACLs
icacls "C:Data*" /save "C:Backupdata.acl" /T /C
icacls "C:Data" /restore "C:Backupdata.acl" /CMicrosoft documents these options for saving and restoring DACLs. The saved paths matter: restoration is path-sensitive, and a backup should be tested against the intended directory layout before a production restore. Keep the ACL backup somewhere protected and separate from the data being changed.
Recover ownership when necessary
takeown /F "C:Datalocked-file.dat"
takeown /F "C:Data" /R /D Ytakeown changes ownership; it does not itself grant all required access. Microsoft notes that further permission changes may be needed. Taking ownership also cannot decrypt EFS-protected content or resolve every service, share, policy, or file-lock problem.
Use PowerShell for scripted workflows
$path = "C:Data"
$acl = Get-Acl -LiteralPath $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"DOMAINUser",
"Modify",
"ContainerInherit,ObjectInherit",
"None",
"Allow"
)
$acl.AddAccessRule($rule)
Set-Acl -LiteralPath $path -AclObject $aclPowerShell is useful when ACL changes belong in a larger script, but requires you to handle rule duplication, inheritance, ordering, exceptions, and verification. Software requiring precise control should use Windows security APIs rather than depend on an undocumented interpretation of old command syntax.
Recommended Free Tools
Risks that apply to either old or modern tools
- Recursive changes can have a large blast radius. They may remove application-specific ACEs, change future inheritance, or leave some descendants untouched because of errors.
- Deny entries are not a shortcut. A deny ACE can defeat expected grants depending on token membership, ACE order, inheritance, and the requested right. Removing deny entries can expand access unexpectedly.
- Ownership is not the same as access. Owning a file may let an administrator change its DACL, but the actual access check still depends on the security descriptor and other controls.
- SMB access involves share and NTFS permissions. Changing the NTFS ACL alone may not produce the expected remote result; effective network access is constrained by both layers.
- Access denied has multiple causes. Check the DACL, ownership, share permissions, encryption, integrity policy, service identity, and whether another process or application controls the file.
- Reparse points and links need special care. Confirm which object a recursive operation reaches; do not assume the displayed path tells the whole story.
- ACLs are not encryption. Access controls govern permitted use; encryption protects data through a separate mechanism.
Before a broad change, save the current ACL, test on a representative copy or small subtree, use the narrowest path and recursion scope, capture errors, and validate access as the affected user or service account. Do not treat /C as success: it means continue despite errors. For a network share, test from the client and identity that actually needs access.
Should you use FileACL.exe now?
For archival research or a controlled legacy environment, the 2006 page remains a useful record of the utility’s intended behavior. But current availability, support, signature status, modern Windows compatibility, and behavior with present-day security descriptors are not established here. If you encounter an archival copy, verify its provenance, hash, and signature where possible, and test it only in an isolated environment. Do not execute an unknown binary on production systems because an old page called it freeware.
For current Windows administration, prefer icacls for ordinary DACL operations, takeown for ownership recovery, and PowerShell or Windows APIs for controlled automation. Microsoft deprecated the older cacls command and recommends icacls instead; see the cacls reference.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute
