Server 2012 System Error 5 When Connecting to Administrative Shares
Because Microsoft Windows is made by a bunch of *********** that can't figure out that System Administrators, Engineers, and Help Desk Analysts don't want to be forced into doing things their way we now have the following.
This is a chronicle of the steps I am taking to fix a problem with users not being able to open default administrative shares that they have access too.
The Problem
- Server 2012 (now called s12) has a drive with letter "E".
- The security group "Special-APP" have read/execute permissions to drive letter "E" as well as full access to a sub directory.
- Users are not able to access \\s12\e$ with a prompt from their workstations asking for user name and password.
- If a user enters their domain credentials they are denied access.
- If you try to access the share using
C:\net use \\s12\e$
You get asked for your credentials, and then are given
System error 5 has occurred
The Attempts to Fix
1.
I found the server had the wrong time zone, because someone other than myself installed it. Made the correction, still can't access the share.
2.
[1]There was mention that a registry entry was to blame for this (All problems in Windows are blamed on the registry, and the users). But as I looked the entry was not available, but someone online said that creating the entry will also work. So
- Open regedit
- Clicked on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- Created REG_DWORD (32-bit) entry with Value LocalAccountTokenFilterPolicy and Data 1.
Well that didn't work.
3.
[2] The next thing I needed to try was to disable UAC. The moron that built the server was kind enough to set UAC to "Never notify". But Microsoft won't just let you be the system adminstrator without a fight. You have to edit the registry again to disable UAC for real.
- Open regedit
- Click on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
- Edit EnableLUA
- Modify Data from 1 to 0
- Reboot (Because if you sneeze near a Windows server, you must reboot it).
Scheduled a reboot, problem persists.
So it ends up that somehow the Domain Users group was added to the Users group on s12, removing them from this group fixed the problem and all was well with the world again. Until the next day when we reverted to having the same problem without the settings being changed.
The Fix
(Haven't Found One Yet)
