Below I describe how I think Windows network file sharing works. I list the settings I now use successfully in my mixed Windows 10 22H2 and Windows 11 24H2, Pro and Home, Wi-Fi and Ethernet network. My usual network is very simple, with just local accounts and allowing Everyone access, but it seems to work reliably between any pair of PCs and with the sharing able to go in either direction. I'll cover the simple, reliable setup here, as well as some extensions that worked in my recent testing, including the participation of Microsoft accounts. However I also found a few problems, so I'm sticking with my simple configuration for now for my normal network.
As I understand it, full-blown network sharing of a resource is a three-step process. This section gives an overview. Details for each step are provided in the later three STEP sections. There are some configuration diagrams near the end of this document.
This credential is used by Windows when passing to the "remote" PC the user's request to access the "remote" shared resource. It is as if the user has walked over to the PC that has the desired shared resource and signed in (in a limited sense) with the username and password specified in the credential for that "remote" PC. Then the user could attempt to access the shared resource via that "remote" account, restricted by whatever was specified in Step 1 for the username specified in the credential.
Possible simplifications: The actual creation of a credential is not required in one likely common case. That is if the user has matching accounts on the two PCs, i.e., exactly the same username and password for each of the two accounts -- (1) the account in the "remote" PC and (2) the account in which the credential would have been created and from which access to the "remote" resource will be attempted. Of course, the account on the "remote" PC still must have been given access to the shared resource via Step 1.
The above uses the default credential username and password for the user's account, i.e., just the username and password for that account. Thus if your network has just one user with the same username and password on all the PCs, you don't need to create any Windows credentials. In contrast, if you had the same username on all the PCs, but the username had a different password for each PC, then your account on each PC would need to have a credential for each of the other PCs that your account needed to access. Each such credential is required just to specify the PC-unique password used for the common username to access the various PCs.
Sharing access restrictions: The simplest of the following procedures are lenient in that the owner of a shared resource on a PC specifies that the Everyone group on that PC (i.e., every user account) has access to the resource. There are ways to make the local sharing more restrictive. However I don't need such restrictions and haven't tried to exhaustively test those configurations. For my simple, one-user network, I specified that "Everyone" has full access in each share I defined. That makes sharing setup easier and it works for me. You can look at the Limited Test of Restricted Sharing section below if you are interested in an experiment I did for a more restrictive configuration. Setting up that didn't seem too hard to do. See also Testing Some More Elaborate File Sharing where I describe a number of tests I did for configurations other than the simple one I normally use. Those tests involved using multiple usernames and multiple account types in the sharing path as well as giving resource access to less than Everyone.
IMPORTANT ACCOUNT CONSIDERATIONS: The username in the credential created in Step 2 must have an account with a password on the shared resource's PC. That's the password specified in the credential. Apparently if the username's account is an MS account (Microsoft account) with Hello configured, the account might not(?) have a password suitable for the credential; thus that account cannot be a file sharer. Problem: An MS account possibly(?) cannot be a file sharer. In contrast, a local account can use Hello (or not) and the account's password is always available for use in a credential for that account's username; thus local accounts are always available for sharing. See Inability To Share MS Account Resources for more on this, including recent test results.
Network sharing is done on a folder basis, at least as far as I'm concerned (see the following paragraphs). You set up a share for a folder and thus provide access to all the files, folders, subfolders, etc., that outer folder contains, i.e., the whole tree for that shared folder becomes shared when accessed thru that outer folder (unless overridden at a lower level in the tree -- beyond the scope of this document). I consider the term "file sharing" to actually mean "folder sharing", in which the contained files are also shared.
I have seen Microsoft Support web pages saying network sharing can also be done on an individual file basis. For example, see both the Windows 11 and Windows 10 writeups here. I haven't gotten such sharing to work for an individual file, but have no problems network sharing the folder containing the file, thus sharing the file. (A bug? Network sharing an individual file does not work.)
Procedures described below work for folders, but not for individual files. For example, if you right-click a file and try to select "Give access to > Specific people...", those selections may not even be in the context menu for the file (or the "Show more options" extension thereof in Windows 11). If the menu selections are there for a particular file, clicking thru the procedure acts as if a share has been created (no errors indicated), but \\localhost does not show the supposed share, in contrast to folder shares. Ditto if you try to set up a network shortcut; the supposed share name is not available. Moreover, if you right-click a file, and select Properties, there is no "Sharing" tab on any file I have tried; the tab is always there for folders.
Bottom line: I assume network sharing is really just for folders, which is fine with me. Maybe network file sharing existed in the past, was later deleted, and Microsoft just hasn't deleted all the code and documentation remnants.
To make the sharing process clearer, in the following example I'll focus on two PCs: XPS8940, which has some files to be shared, and XPS13-2, which needs to access those files over the network. Of course the roles could be reversed. Any PC could have files it allows other PCs to access, but that PC could also access files owned and shared by other PCs. Just apply the sharer (owner) procedures or accessor procedures or both to each PC as appropriate for what that PC is supposed to do for the particular file sharing to be done.
Per the Windows direction, I have used the Settings path rather than the Control Panel path to say how to get to most settings areas. However the Control Panel still needs to be accessed for some things. See Where Is the Control Panel? if you need help finding it.
1. Name the PCs and set up the workgroup
2. Make the network profile private on each PC
3. Fix settings in Network and internet section
Private networks Network discovery ⦿Turn ON network discovery Windows 10: ☑ Turn on automatic setup of network connected devices Windows 11: ☑ Set up network connected devices automatically File and printer sharing ⦿Turn ON file and printer sharing Public networks Network discovery * Turn off network discovery (an area not tested by me) File and printer sharing * Turn off file and printer sharing (an area not tested by me) All Networks Public folder sharing * Turn off public folder sharing... (an area not tested by me) File sharing connections * Use 128 bit encryption... (an area not tested by me) Password protected sharing ⦿Turn ON password protected sharing or (see PPS "off" problem) ⦿Turn OFF password protected sharing
4. Handle SMB feature settings
* SMB 1.0/CIFS File Sharing Support
- SMB 1.0/CIFS Automatic Removal
? SMB 1.0/CIFS Client
? SMB 1.0/CIFS Server
? SMB Direct
I'm very unclear about this area, but for me the above seems to work for the "?" items. I think I used to have to leave the Client and Server items turned on. However the above seem to be good settings for file sharing now. Note that these settings may break something else I am unaware of.
5. Ensure relevant services are started
The above list of services may be outdated (too many or too few listed). This list is from years ago, but it's still what I do and sharing still works with this list used. You will probably find that these services are already running, so no change is required, but the above ensures they get started.
6. REBOOT ALL THE PARTICIPATING PCS, i.e., the resource sharing (owning) PCs and the resource accessing PCs.
The following does Step 1, described briefly in the Overview of Network Resource Sharing section.
Often you want to give the Everybody group (all accounts on the PC) access to a resource -- very permissive. The next two procedures show how to do that. An example of a less permissive procedure, e.g., restricting access to just one or more specific accounts (maybe to just the owning account), is shown in the Limited Test of Restricted Sharing section below.
Unfortunately there seems to be a problem with the Microsoft-documented simple way to set up a share giving the Everybody group access. So first I'll describe a more complicated procedure, one that always works for me. I recommend using it instead of the simpler procedure.
The more complicated, but very reliable way to give Everyone access
If you want to specify your own share name instead of the one Windows proposes, or if you want to give Everyone different permissions than the default, or you just want the procedure to work reliably, you could do this:
The simpler way, which can fail invisibly
Instead you could use the simpler procedure shown below, which is often mentioned on the internet; however it often fails. For example, for me it works for sharing a folder in the root folder, but fails (invisibly) for sharing a folder on the Desktop. (Perhaps it's related to whether sharing has been done higher in the tree?). It seems to go thru normally, producing no error messages as if the share had been created. However in fact no share was created. You always need to check to be sure it worked. If you find it didn't, use the longer procedure described above. Here's the simple procedure:
In theory access is then given to Everyone, although "Everyone" (the default) is not shown in the list. In fact in the above you could even explicitly select Everyone (or anyone else) in the dropdown list, and it can still fail without notice. After doing the simple procedure above, you should always verify the share was created by using the procedure described below.
How to check that a share was created exactly as you wanted
Note that the required checking adds more steps to the total than if you had used the more complicated way to begin with. The trick seems to be that even though you might click a bunch of "Share" buttons along the way, thinking that will create the share, the most important thing is to get to the "Advanced Sharing" dialog and mark the "Share this folder" box. That's what seems to actually create the share in all cases even if you didn't click any of the "Share" buttons before this. Here's how to check what, if anything, was created.
How to view the current share list
However shares were created, you can always see the current list of any shares on this PC by doing this:
Each Windows account has its own set of credentials, managed by the Credential Manager. The account's credentials are used to access resources outside that PC, e.g., on another PC in the network. For a particular accessing user (with an XPS13-2 account) to be able get to resources on the sharing PC (XPS8940), the user of the XPS13-2 account must first do the following to show they know how to sign in to the appropriate XPS8940 account. This is Step 2, described briefly in the Overview of Network Resource Sharing section.
For example, jeff's XPS13-2 account might include the following credential to access XPS8940:
WARNING: Be sure to reboot the PC right after making any changes with the Credential Manager. Otherwise the pre-change credential settings may still be used until the next reboot and you may wonder why things aren't working as you expected.
Credential facts: See Step 2 in Overview of Network Resource Sharing for information about the default credential for an account. Also note that for each account on XPS13-2 there can be at most one credential for XPS8940, i.e., that particular XPS13-2 account can remotely "sign in" to only a single account on XPS8940. However different accounts on XPS13-2 could have different credentials for accessing XPS8940, i.e., each XPS13-2 account could "sign on" using a different XPS8940 account.
Logic flow for the above example: When the XPS13-2 user jeff with the above credential data later tries to access a shared resource owned by (or at least accessible to) ken on XPS8940, the information from the Credential Manager is passed to XPS8940. There the username and password are checked to be sure ken is a valid XPS8940 account user and is authorized to appropriately access the specified resource. The XPS13-2 user jeff is then temporarily "signed in" as ken on XPS8940 (in a very limited sense), at least enough to try to access the specified shared resource accessible by ken on XPS8940.
Possible MS account problems and a workaround: See the IMPORTANT ACCOUNT CONSIDERATIONS warning about trying to use in a credential a Microsoft account with Hello configured. It may not work. Having an installation account that is able to easily share its files can be a challenge, particularly if Windows was installed using a Microsoft account with Hello configured (which Microsoft pushes). You probably want that installation account to be able to share some of its resources across your network. However for that to be possible it must have a username and password suitable for a credential, possibly not the case for an MS account. There may be ways around this if the problem occurs (ways not covered here), which may have some problems of their own. Of course you can set up a second account separate from the installation MS account, and make the second one local, thus allowing sharing for the resources it can access (even if not directly own). But adding more accounts and providing them with appropriate access to resources they don't own can get complicated.
Note 1: If the owner of a resource has given Everyone access to that resource, an account in another PC in the network should be able to access the resource as long as the credential for the sharing PC is good. The credential could name an explicit account on the sharing PC or the procedure could use the default credential as long as the accessing account's username and password matched such an account on the resource-sharing PC.
Note 2: An indirect share can get around the Microsoft account sharing problem. Suppose username mary on XPS8940 (possibly in an MS account) is the owner of a resource X on XPS8940 and she has given resource access to another XPS8940 account, username ken. Then the ken account can be used by an XPS13-2 account, e.g., username jeff, to access mary's resource X on XPS8940. See the diagram on the left, where the usernames are abbreviated as "M", "K", and "J".
To complete the setup, jeff must add a credential for ken to jeff's account on XPS13-2. Then mary's X resource can be indirectly accessed by jeff thru ken's account. Note that for ken's local access to the XPS8940 resource X, either mary must have explicitly given access to ken or mary must have given it implicitly thru the Everyone group. See the Limited Test of Restricted Sharing section below for ideas about how to explicitly add a non-Everyone account to a share. See my tests for indirect sharing for a number of tests I ran, validating this procedure (for most configurations).
In this example, after Steps 1 and 2 are done, XPS13-2 should now be able to access the shared resource on XPS8940. The most reliable way to do that seems to be to set up a network shortcut on XPS13-2. In the shortcut the target address should be \\XPS8940\zzz, where zzz is the share name that was set up on XPS8940 for the shared resource. See Step 1: On the Sharing PC (XPS8940), Set Up the Share for how this was done. Double-clicking the network shortcut should access the shared resource.
If in the wizard dialog to create a network shortcut you enter just \\XPS8940\ for the "location" (note the final "\"), the system will (eventually) display all of XPS8940's shares. You can select any one, but the shortcut will then fail (and say it failed!) if you are not authorized for the selected share. You might be asked to provide a proper credential and be given an option to have that information recorded, presumably as if you had originally entered the proper data via the Credential Manager.
I did experiment a little with restricting the access in a share to just a single named account, the owner of the resource, vs giving access to Everyone or to a specific account other than the owner's. It's more complicated than the "Everyone procedure" described above, but tightens up "who can access what" in a system with multiple users. I did the following, which seemed to work:
Giving just the owner access (removing Everyone):
In general, to give a specific username access:
If things don't work initially as expected or something stops working that had worked before, try rebooting the PCs that are involved. Below are some problems I have encountered in my testing.
To enable an MS account to share its resources, I had previously seen internet posts saying you have to somehow temporarily disable Hello for the MS account to make its password available for use in resource sharing, then turn Hello on again after the other user has accessed the shared resource. For possibly a less on/off/on technique, I had seen this post. I have not tested any of these Hello-less MS account sharing procedures to see if they really work; I'm just noting some posts I have seen. Given that I set up my production network with only local accounts, which works well for me, I'm sticking with that for now, not depending on the possibly ephemeral "It now works with an MS account." test result noted above.
In contrast, if you have a recalcitrant MS account with resources that need to be shared, I did test setting up another account, this one local, then using the indirect share technique described in Note 2 in the Step 2: On the Accessing PC (XPS13-2), Set Up the Credential" section. That does work reliably.
Windows is slowly moving settings from the Control Panel to Settings. However some key settings needed for network file sharing are currently still in the Control Panel, which can be hard to find. An easy way is to type Control Panel in the Settings "Find a setting" search box. Then click Control Panel and (if needed) View by: Category > Small icons to display the full item list. There are also ways to put a Control Panel shortcut on the Desktop or pin one to the taskbar if you use the Control Panel frequently.
PCs used for testing: Below I describe details of the two PCs I used to do recent testing of some share capabilities I don't normally use. Earlier I had used these PCs and several other PCs just to make sure my simple, standard "local account jeff on all my PCs with Everyone permitted access" still worked in my newly expanded network. It did, so I went on to test some more elaborate configurations in case I might need them later.
(FYI, in account conversion I describe my experiences with converting the Microsoft install account to the "J" local account used for the file share testing described here.)
Because of the way it was installed (manually, well after the Windows install), this "M" account may have some different characteristics than an MS account created as part of the installation process. For example, I found that even though it uses Hello I was able to create a good credential on PC A for the PC B item 3 MS account username and the MS account password. In contrast, the MS account used for installation used Hello and no working credential could be created for it. (This was before I converted it to a local account.) I don't know what I might have done to enable use of the MS password for the item 3 MS account. Apparently it is possible; although I had done nothing intentionally to cause it, e.g., toggling any Hello settings or the "For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device" setting.
Searching the internet on this topic yields confusing results. I plan to stick with local accounts for my production accounts. They seem much less prone to go off in unexplained and maybe unreliable directions. See Inability To Share MS Account Resources for more on this.
Test setup: For testing multiple sharing accounts of various types, on PC B I created twelve small folders, with four folders each for the three J, K, and M accounts. I signed in on each account to create its four folders, making that account the definite owner of its four folders. As the owner I then did a share for each of the folders. The first folder was shared with Everyone, E, with full control permission. For the remaining three folders, Everyone was deleted and just one account (either J, K, or M) was then given full control access permission for the folder. I put a small text file in each folder, so write access could be tested. The files were named T{owner}{permitted sharer}. For example, TJE was the name of the folder owned by J, who had given access permission to Everyone; TKM was owned by K, who had given access permission only to M.
Test procedure: I then went to PC A, signed in as jeff (that's the only account on that PC), and one by one used the PC A Credential Manager to set the PC B credential to null, J, K, or M with the appropriate password. I carefully rebooted every time I changed the PC B credential. I ran a full set of tests under each credential setting before changing the credential to the next username to run the tests for it. Note that the null setting (no credential for PC B) results in using the jeff username and password by default since the credential was being set up under the jeff account on PC A.
While under each of these four credential settings on PC A, for each of the 12 folders on PC B, I asked Windows to create a network shortcut. Either the request failed (a "no permission" error pop-up appeared) or it succeeded. If a network shortcut was created, I double-clicked it to open the shared folder. I then verified that from PC A I could open, read, and modify the file in that shared folder on PC B.
Test results: For almost all of the 48 cases, things worked as you would have expected (and hoped for). If the credential on PC A matched an account on PC B (username and password) and that account had been given share access to the resource by the owner (either explicitly by username or implicitly by Everyone), then the folder's text file could be read and modified by the PC A user. Otherwise, the shortcut properly failed with the "no permission" pop-up.
Anomalies: I was surprised that in these tests the M (MS account) did work for sharing, i.e., its password was valid in the credential, even though that MS account had Hello PIN configured. The TJM, TKM, and TMM cases all worked. In contrast, in my very early tests right after the Windows 11 install with a different MS account, that installation MS account was not able to share its files because its MS password would not work in a credential.
Two other cases out of the 48 produced unexpected results, the TJE tests failed under both the K and M credential settings, but should have worked since Everyone had been given share access. Yet the test worked under the J and null credential settings, as expected. Maybe this has something to do with the unusual history of the J account on PC B; see above.
Indirect share: One good result of this testing was proof that an "indirect share" does work. For example, for test TMK see the diagram on the left below. In the left diagram J has only an account on the accessing PC, none on the "remote" PC, so needs some help there from a non-J username, K. On PC B, M owns a resource and has permitted (via a share) local access for the resource to K, as well as giving the resource the share name of X. On PC A a credential is set up in J's account for getting to K on PC B. Finally J on PC A sets up a network shortcut which uses the share name X of the resource plus the credential for PC B (which has K's username and password) to get to K's account on PC B and indicate access to X is desired. The share name X is then used on PC B to identify the resource so K's permission to access it can be verified. If all is good, then J can now access X thru K. That would be handy if M owned some critical file that needed to be shared, but the MS account was not in the mood to have a password that could be used in a credential on other PCs. This configuration is shown in the diagram on the left in the next section.
Configuration on the right: This often occurs in small home networks. The user J has an account on both involved PCs. In fact if the J username has the same password on both PCs, the user does not even have to create a credential for PC B in J's account on PC A. Windows will assume a default credential to access PC B, using J's PC A account username and password.
In this example of a typical small home network, J on PC B is the owner of the resource. More generally the resource might be owned by another account on PC B, which has given access to J. In the right diagram, imagine replacing the PC B part with the PC B part from the left diagram, but with "K" changed to "J" and "M" left as is.
Configuration on the left: This is the most general case. The accessor, J, does not have an account on PC B. Then for J on PC A to get to PC B, some other account on PC B must be used as an intermediary. In the diagram K's account is used. To enable this, J must create a credential for K in J's account on PC A.
In the most general case, as shown by the left diagram, K is not the owner of the resource. However, in a simpler case K could be the owner. That would be along the lines of the bottom of the diagram on the right with "J" replaced by "K".
Changing the window width changes the diagram size.
