Fix Server & Cloud Error: 0x80070002 – File or directory missing

You're staring at 0x80070002 on a server or cloud sync job. Annoying, right? Let's fix it.

The error text says File or directory missing. Nine times out of ten, it's not actually missing — the system just doesn't have permission to see it, or the Windows Update cache is corrupted. I've seen this on Server 2019 trying to apply patches, on Windows 10 Pro during feature updates, and even on Azure Backup jobs. Here's the direct fix.

First, try the quick fix: Reset the Windows Update components

If this happened after a failed update, the cache is almost certainly the culprit. Open PowerShell as Administrator and run:

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old

net start wuauserv
net start cryptSvc
net start bits
net start msiserver

Then try your update or sync again. This removes the downloaded update files and resets the services. Works about 60% of the time for me. Had a client last month whose entire print queue died because of this — same error, different context. The reset fixed it.

If that doesn't work, check permissions

The error often shows up when a scheduled task, cloud sync tool, or backup job can't access a file due to NTFS permissions. Typical scenario: You've got a shared folder on a server, and a cloud sync agent (like OneDrive or Azure File Sync) is trying to write to it. The sync agent runs as SYSTEM or NETWORK SERVICE, but the folder only grants access to domain users.

Here's what to check:

1. Right-click the folder/file in Explorer, go to Properties > Security
2. Click Advanced
3. Check that SYSTEM and CREATOR OWNER have Full Control (or at least Modify)
4. If it's a sync job, also add NETWORK SERVICE if that's the service account

Also check the Effective Access tab — it'll tell you exactly what permissions the sync account has. I once spent two hours on a Server 2016 box where the error kept appearing for a nightly backup. Turned out the backup service account had been removed from the folder ACL after a folder migration. Added it back, and the error vanished.

Less common variation: SMB encryption mismatch

If you're seeing this error on a file server accessed over SMB, especially with Server 2012 R2 or older clients, check SMB encryption. Sometimes a newer server (like 2022) requires encryption, but an older client doesn't support it. The error will show as 0x80070002 even though the file is there.

Fix: On the server, open PowerShell and check your SMB settings:

Get-SmbServerConfiguration | Select EnableEncryption

If it's True, set it to False temporarily to test:

Set-SmbServerConfiguration -EnableEncryption $false -Force

If the error stops, you need to either disable encryption on that share (not ideal) or update the client to support it. For Windows 7/Server 2008 R2, you won't get encryption support without a third-party tool — so disable it on the share instead:

Revoke-SmbShareAccess -Name ShareName -AccountName Everyone -Force
Grant-SmbShareAccess -Name ShareName -AccountName Everyone -AccessRight Read

That's a specific scenario, but it happens. Don't ask me why Microsoft didn't expose a clearer error message.

Prevention: Keep your permissions clean and updates lean

Preventing 0x80070002 is all about housekeeping:

• Use Group Policy to set Windows Update cache size limits and auto-cleanup. Set Configure Automatic Updates to download but let you choose install time — that avoids cache bloat.
• Audit permissions quarterly. Use icacls scripts to export folder permissions and look for orphaned accounts. I run this once a month on every client server:

icacls C:\ShareName /save C:\Backups\permissions.txt /t

Then review the file for SIDs that don't resolve to known users.

• Don't let SoftwareDistribution folder grow forever. Schedule a monthly task to stop the services, rename the folder (like the quick fix above), and restart. The folder will rebuild automatically.
• For cloud sync jobs, always use a dedicated service account with explicit folder permissions. Never rely on the Everyone group — it's a security risk and it breaks when you least expect it.

Last thing: if you're still stuck after all this, check the Windows Event Log under Applications and Services Logs > Microsoft > Windows > Windows Update Client > Operational. Filter for Event ID 20 or 41 — those often contain the exact missing file path. I've seen cases where a third-party antivirus (looking at you, Symantec Endpoint Protection) quarantined a Windows Update file, causing 0x80070002. If that's your case, restore the file from quarantine and add an exclusion.

That's the real fix. No fluff, just what works.