Administrative or Admin shares have been available on most Windows client Operating systems for a long time. It is a hidden share on the computers, mainly used for remote file management by the administrators. As we are talking about the ‘Network Shares’, you have the working network setup. Follow the below steps if you face the issue of admin share not working on Windows 10, 11 or Windows 7 computers.
By default, all the local drives (Partitions) are shared for administrators to access over the network. These types of shares are called admin or administrative shares in Windows OS. It usually can be accessed by typing the Computer IP address or name with a partition letter and dollar ($) sign at the end, as shown below.
Prerequisites for Working Administrative Shares
Before further troubleshooting the administrative shares not working issue in Windows 10/11, let us understand the requirements.
- Working network: Make sure the computers are on the LAN network where they can communicate with each other. Simply try the ping command and confirm the network connectivity.
- Same Domain or Workgroup: As we are talking about a workgroup network typically applicable for home or small office (where no domain and Active Directory network exist), both computers should be in the same workgroup. If you have not changed it manually, then mostly all PCs will be on the default workgroup as below. If not, you need to change and reboot the computer. The same condition is applicable in the domain environment.
- Administrative access on the destination: You must have administrative access (Admin username and password) on the destination computer. As it is called ‘Administrative Shares’ only the administrators (or the users who are part of the administrator group) can access them over the network. It doesn’t matter if you are the admin of your (source) computer; you must have admin access on other remote computers.
- Status of Administrative Shares: It is shared by default, but the administrator can remove it for security purposes. If C$ or other admin shares are disabled manually, then it will not work. So, check and confirm that the admin shares are active. We can see them under Computer Management in Windows 10/11 and others.
- Check Firewall and Security Softwares: Some of the 3rd party security software and personal firewalls may disable the admin shares to improve the computer’s data security. Also, if any firewall or network policies block the file sharing TCP/IP protocols, it will impact the Administrative share access over the network.
If the above requirements are checked and met, follow the steps below.
It is a modification in the Windows OS registry which worked straightaway in my example. Take extra precautions while modifying the registry; take a backup before proceeding further.
How to Fix When you Can’t Access C$?
Check Admin Share on Local PC:
As described earlier, the Computer Management -> Shared Folders -> Shares will show the active shares of the local PC.
Also, we can use the below command to find out from the command prompt or PowerShell.
net share
Find Administrative Share on Remote PC
If you have appropriate access on the remote computer, the below command will output the admin shares on the remote computer.
net view \\computername /all
You can use the IP address instead of computer name as well.
Follow the steps if you can’t access C$ or other admin shares on the remote computer (after checking the above 5 prerequisites)
1) Open registry on the remote Windows 10/11 computer – Open the Run dialogue box and type ‘regedit’
2) Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
3) Add a new value DWORD (32 Bit or 64 Bit, depending on OS version), name it LocalAccountTokenFilterPolicy and give value 1.
Restart the computer and check the admin share now. It must work.
Example of registry
With the above 5 prerequisites and this registry modification, you should be able to fix the administrative shares not working in Windows 10/11 and even Windows 7.
Check the below video for more information:
After all this below including LocalAccountTokenFilterPolicy, and even making some changes using secpol.msc settings, local Security policy, the final answer was to change the password on all nodes, and this apparently cleaned out the blocked cache.
The quirky issue I had to solve was existing admin shares (C$, D$, etc worked beautifully until one day some windows update changed it, for it stopped working on 3 machines, but 2 additional nodes tested could access the shares at the same time that the other 3 could not. All nodes had the same user with the same pw when it suddenly quit working. It simply came up with a credential prompt and when logging in, it came back with error message of simply incorrect password. This included trying to log in and testing 3 ways in a workgroup (remotenodename\user, localnode\user and just user)
For these shares to be used in a workgroup environment, the same user must exist on all nodes, and apparently the SIDs match across nodes, but the passwords do not have to be the same. If the pw’s are not the same, then this will force credential prompts when typing for example: Start–> Run–> \\nodename\c$ instead of just opening it, which of course is not as convenient.
But apparently Win7 can cache credentials if set up in secpol.msc, but this cache I think is where the turd needed to be flushed to fix this issue for I tried all params here and the final fix was simply changing the password on all nodes to the same and ding, it worked !…… even though some of the security settings mentioned below were set differently on the nodes, because of testing every parameter!
( not knowing the cause makes you be cautious about the answer, but I will test, when I have another 5 hours of unbilled time to account for, after blowing it fixing this nerve myelin-sheath ripping time waster. SYSDBA
Administrative shares and share issues in Windows 7
Those who have experience with NT-based operating systems on a network will certainly be familiar with the concept of administrative shares. You access them like \\computername\c$ and only pups don’t know about them. We would be alarmed (no, pissed) or hack a side door fearing they might be gone in Win7.
Once upon a time not too long ago, mentioned here as an example of the need for admins and their admin shares, some nutcase justifying his existence tried to remove all admin shares at a large company I worked at, claiming Sarbanes Oxley said so, (yeah right, read the Bill, it does not even go near that deep). They thought it made life too easy, but if you have the pw for an admin share, you are already in his lady’s chambers.
Windows 7 still creates the administrative shares on install, but you can’t use them out of the box. First of all, you need to have File and Printer Sharing enabled. And the way to do that has once again been changed:
1.Open the control panel.
2.Go to Network and Internet.
3.Go to Network and Sharing Center.
4.In the left column, click on Change advanced sharing settings.
5.There are two profiles. You probably don’t want this on when you’re on a public network so open Home or Work.
6.Under the header File and Printer sharing, select the Turn on… option.
And now your administrative shares still don’t work You’ve just completed step 1 which implies there’s at least a step 2 and here it is: you also need to change the registry.
This also works in windows Server 2008
1.Click on the orb (= the round button with the Windows logo in the taskbar) and type regedit in the search box.
2.Open the registry editor.
3.Navigate all the way to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
4.Right-click in the pane on the right side and add a new DWORD (32-bit).
5.Give the new setting the name LocalAccountTokenFilterPolicy.
6.Double click on that setting and give it a value of 1.
It’s probably wise to reboot after doing this, although it might not be needed. I’m not sure if it works straight away because I rebooted without trying.
Anyways, if you’re lucky you will be able to access administrative shares after performing these steps. If you’re unlucky, like me, doing all these things appears to have zero effect at all. Once again don’t panick, because there’s another hint/tip/solution coming your way.
Somewhere at some point during the installation or configuration of Windows 7, you will be asked to do something with a thing called Homegroup. It’s some weird new sharing tool that looks OK but isn’t quite what you’re used to. Once you have enabled that feature, you won’t be able to use the administrative shares. So the tip is: disable the homegroup feature.
1.Open the control panel.
2.Go to Network and Internet.
3.Go to HomeGroup.
4.Click on the blue link Leave the homegroup.
The popup dialog should point out itself, but I believe I picked to first option. Once I had left the homegroup, the administrative shares started working again.
*****************************
secpol.msc settings
click the start button and type secpol.msc in the search function, or start run(always works in search function) or can use gpedit.msc and then go to security policy.
Browse to “Local Policies” -> “Security Options”. Now look for the entry “Network Security: LAN Manager authentication level” and open it. Click on the dropdown menu and select “Send LM & NTLM – use NTLMv2 session security if negotiated”. Apply the settings.
In the Advanced sharing settings page of Network and sharing center, you need to have it set as Work/Home profile. Try
-Enable network discovery
-Turn on file and print sharing
-Turn off password protected sharing
-Use user accounts and passwords to connect to other computers
The other settings such as encryption I have set as use 128 bit encryption.
Please check related policies.
1. Enter “gpedit.msc” in the Start Search box.
2. Open “Computer Configuration”/Windows Settings/Security Settings/Local Policies/Security Settings.
3. In the right pane, enable the following policies:
Network access: Allow anonymous SID/name translation
Network access: Let Everyone permissions apply to anonymous users
Also please disable the following policies.
Network access: Restrict anonymous access to Named Pipes and Shares
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and shares
Good one!
SYSDBA here again with more woes, but like I have told my subordinates, don’t bring me a problem unless you have a gameplan or the solution.
OK admin shares on win7 are quirky and I think I finally figured it out, even though Google did not help me unless I did my penance (hours of troubleshooting).
The home network or work network settings on a Win7 machine are at the source of the issue.
Quirk: When you try to access a remote admin share, Windows bring up the prompt, and you are thinking you are there by putting in the correct password, and it keeps coming back with incorrect password even though you know it is correct. The same user exists on both machines, so you try just user and then pw, and then \\machinename\user and then pw, and still no tang. Before you pull the pin on the grenade around your neck like that guy on patrick swayze gene hackman movie (Uncommon Valor) you have to show some more Uncommon Valor and stick with me here.
What I found is that if you ever accidentally enable homegroup which is very easy to do by simply selecting home network, it enables several things including IP6.
READ THIS for FIX: I found after enabling all the fixes in my first post (TokenFilterPolicy, etc) and resetting pw, the real final fix was to disable IP6 and admin shares now works repeatably. What the F*&(987. I think I will pull the pin and throw it instead, LOL. I noticed that IP6 is required for Homegroup to work and this is what led me to this fix. ADMIN SHARES DON’T WORK—DISABLE IP6
allowing netlogon tru the firewall worked for me