Yeah, that error is a pain—you click a drive or a folder and Windows just slaps you with 0X80110818 and says access denied. You've probably tried the obvious stuff: checked if the drive is plugged in, rebooted, maybe even ran chkdsk. None of that helps because this isn't a hardware issue at all. It's a permissions problem, and here's the direct fix.
The Fix: Reset Ownership and Permissions
Open an elevated Command Prompt (right-click Command Prompt, 'Run as administrator') and run these two commands, replacing E: with the actual drive letter you're stuck on:
takeown /f E:\ /r /d y
icacls E:\ /reset /t /c /qThe takeown command hands the partition's ownership back to your user account. The /r flag recurses into every subfolder, and /d y just says 'yes' to the prompt that appears for each file. Then icacls /reset reapplies default permissions from the parent object—in this case, the drive root—to everything under it. /t processes all subdirectories, /c continues even if it hits a file it can't fix, and /q keeps the output quiet so you don't get thousands of lines.
After those finish, try opening the partition again. It should work. If the error pops up on a specific folder rather than the whole drive, run the same commands but point them at that folder:
takeown /f "C:\Some\Stuck\Folder" /r /d y
icacls "C:\Some\Stuck\Folder" /reset /t /c /qWhy This Actually Works
Here's what's happening under the hood. Every object in Windows NTFS has a security descriptor that stores an owner and a list of access control entries (ACEs). That list tells Windows exactly who can read, write, or delete the file. When the owner is changed—say, your user profile was moved, or you used a different admin account to set up the drive—the old ACEs can point to SIDs that no longer exist. Windows then treats the partition like a stranger's house: locked, no keys.
The error 0X80110818 specifically comes from the COM+ runtime, which uses the partition to store temporary configuration data for components like Outlook or SQL Server. When COM+ can't write to its own temp directories, it throws this exact code. But the root cause is still the ACLs.
The reason takeown works is that it forcibly writes your user SID as the new owner, bypassing the 'you don't have permission to change ownership' check. Once you own it, you have the right to modify the DACL, which is what icacls /reset does. It rebuilds the ACE list from scratch using the default inheritance rules. That's why the order matters—if you just ran icacls without takeown, you'd still get access denied because you lack the WRITE_DAC privilege.
A subtle thing about inherited permissions
If your partition is formatted as exFAT or FAT32, NTFS ACLs don't exist, so this error shouldn't occur on those filesystems. The fact that you're seeing it means the drive is NTFS, and the ACLs are definitely the culprit. Also, if the drive is a system drive (C:), be careful—resetting permissions on the entire C:\ can break Windows if you include system folders. Stick to the specific partition or folder that's failing.
Less Common Variations
Sometimes the standard fix doesn't quite cut it. Here are a few edge cases I've seen.
1. The partition is a system reserved or recovery partition
If you're getting this error on a partition that has no drive letter (like the 100MB System Reserved), you can't just run takeown because you need the volume GUID path. Mount it first:
mountvol E: /S
Then run the permissions fix on E: as usual. After you're done, unmount it with mountvol E: /D.
2. The partition is encrypted with BitLocker
BitLocker sometimes locks a partition even after you unlock it, especially if the clear key isn't available. Check if the drive shows a padlock icon in Explorer. If it does, unlock it manually via right-click > 'Manage BitLocker', then try the ACL fix again. In rare cases, you might need to suspend BitLocker temporarily: manage-bde -protectors -disable E:, run the fix, then re-enable with manage-bde -protectors -enable E:.
3. The error appears only when running a specific application
If Outlook or another COM+ client throws this, but the partition opens fine in Explorer, the issue isn't the partition itself—it's the app's service account. Check the Windows Event Log under 'Application' for entries with source 'COM+' and look for the user SID. Then grant that specific service account full control via the Security tab in the partition's properties. The ACL reset won't fix this because the app runs as a different user.
Prevention for Next Time
This mostly happens after you reinstall Windows or switch user profiles. To avoid the pain again, set a consistent admin account and always use the same profile to create partitions. If you're moving a drive from an old PC to a new one, run takeown and icacls /reset on the entire drive before you start installing apps. That way the COM+ temp folders are already owned by your new account.
Also, don't get into the habit of disabling UAC or messing with the 'Share with' security settings. Those tweaks often strip inherited permissions and leave orphaned SIDs, which is exactly the kind of mess that triggers 0X80110818 later. Keep the default inheritance, and you're unlikely to see this error again.