Fix STG_E_SHAREREQUIRED (0x80030106) on Windows Server
This error hits when Windows can't access a file or folder because the path needs to be shared. Usually happens with mapped drives or UNC paths in scripts.
When This Error Hits
You're running a backup script or a file copy job on Windows Server 2016 or 2019, and it fails with "STG_E_SHAREREQUIRED (0x80030106)". The exact moment? You're trying to access a file on a mapped drive (say, Z:) from a scheduled task or service account. Or maybe you're using a UNC path like \\server\share\file.txt and it bombs out mid-execution. The error is vague — it just says "share required" — but the trigger is almost always a session that doesn't have proper network permissions.
Root Cause
Windows treats mapped drives as user-specific. A scheduled task running as SYSTEM or a different user can't see your Z: drive. Same goes for network shares — if the account running the job doesn't have explicit share permissions, you get this error. The underlying issue? The file or folder path isn't actually shared at the network level, or the security context doesn't have the rights to traverse it. It's not a disk error. It's a permission gate.
The Fix
Step 1: Replace Mapped Drives with UNC Paths
Stop using mapped drives in scripts or services. They're session-bound and unreliable. Switch to the full UNC path:
\\ServerName\ShareName\Folder\File.txtIf you're using PowerShell, replace Z:\ with \\ServerName\ShareName\. Test the path manually first to make sure it resolves.
Step 2: Verify Share Permissions
Right-click the shared folder on the server. Go to Sharing tab → Advanced Sharing → Permissions. Make sure the account running the job has at least Read access under share permissions. Don't rely on NTFS alone — share permissions are a separate gate.
Step 3: Check NTFS Permissions
Go to Security tab on the same folder. The account needs Read & execute, List folder contents, and Read. If it's a service account (like NT AUTHORITY\SYSTEM), add it explicitly. Domain computer accounts need DOMAIN\COMPUTERNAME$.
Step 4: Run the Job Under the Right Account
If it's a scheduled task, set it to run as a domain user that has permission to the share. In Task Scheduler, under General tab, check Run whether user is logged on or not. Test it immediately — right-click → Run. If it works, you're golden.
Step 5: Registry Tweak for Mapped Drives (Last Resort)
If you absolutely must use a mapped drive, enable this registry key on the machine running the job:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnectionsSet it to 1 (DWORD). Reboot. This lets SYSTEM and service accounts see mapped drives created in user sessions. But it's a hack and can cause other weirdness — avoid it if you can.
What to Check If It Still Fails
- Firewall: Make sure the Windows Firewall on the file server allows File and Printer Sharing (ports 445, 139).
- DFS Namespace: If you're using DFS paths like
\\domain\share\folder, try the direct UNC instead. DFS referrals can break for service accounts. - Kerberos double-hop: If the job connects to Server A, then tries to access a share on Server B, you might hit delegation issues. Use
CredSSPor run the job directly on the file server. - Event Logs: Check System and Security logs on the file server around the time of the error. Look for Event ID 5140 (share accessed) or 4625 (failed logon).
Bottom line: 9 times out of 10, it's a permission mismatch. Fix the account or the path. Don't waste time on disk checks or reinstalling anything — this is a networking and permissions problem, plain and simple.
Was this solution helpful?