Windows File Sharing Notes

Last Updated:   4/2/25  02:11            Jeffrey Knauth    jeff@jgkhome.name

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 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. However I also found a few problems, so I'm sticking with my simple configuration for now.

Contents

[click a section title to jump to it]

Overview of Network Resource Sharing

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 and there are some configuration diagrams near the end.

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 that up 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 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 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 may have no password suitable for the credential; thus that account cannot be a file sharer. Problem:  An MS account usually 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 Usual Inability To Share MS Account Resources for more on this.

Folder Sharing vs Individual File Sharing

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 web pages saying sharing can also be done on an individual file basis. (Search for "Share files in Windows".) I haven't gotten sharing to work for an individual file, but have no problems sharing the folder containing the file, thus sharing the file. (A bug? 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 sharing is really just for folders, which is fine with me. Maybe file sharing existed in the past, was later deleted, and Microsoft just hasn't deleted all the code and documentation remnants.

Terms Used in the Following Example

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.

Preparatory Setup on All the PCs

In some places in the following, I say access settings via the Windows Control Panel. Some of these may be accessed more directly by Settings in later versions of Windows. Also some minor descriptive text displayed for various settings has changed from version to version, but the concepts remain the same.

Name the PCs and set up the workgroup

Make the network profile private on each PC

Fix settings in Network and Sharing Center

  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

  Guest or 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 to help protect...  (an area not tested by me)
     Password protected sharing
       ⦿Turn ON password protected sharing
     or                                                (see PPS "off" problem)
       ⦿Turn OFF password protected sharing

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.

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.

REBOOT ALL THE PARTICIPATING PCS,  i.e., the resource sharing (owning) PCs and the resource accessing PCs.

[STEP 1]   On the Sharing PC (XPS8940), Set Up the Share

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. (A bug? A simple share setup can fail without notice.) 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 doing the following.

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, the 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. Here's how to check what, if anything, was created.

However you create shares, you can always see the current list of any shares you have created on this PC by doing this:

[STEP 2]   On the Accessing PC (XPS13-2), Set Up the Credential

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.

Control Panel > Credential Manager > Windows Credentials > Add a Windows credential > (enter credential data)
      (The "Add a Windows Credential" link looks like a column header on the right side.)

For example, jeff's XPS13-2 account might include the following credential to access XPS8940:

  • Internet or network address:  XPS8940
  • User name:  ken      (Note that the "remote" username, ken, can differ from the username creating the credential, jeff.)
  • Password:  The password for ken on 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.

See Step 2 in Overview of Network Resource Sharing for information about a default credential. 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.

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. (I think that's how it works.)

Here ken is the username for an account on the sharing PC (XPS8940) for which the XPS13-2 user has recorded that account's username and password in a credential. See the IMPORTANT ACCOUNT CONSIDERATIONS! warning about trying to use in a credential a Microsoft account with Hello configured. It is likely that it will 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, typically not the case for an MS account. There are ways around this (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. Or you could try switching Hello off/on frequently to enable/disable sharing. I haven't tested that undesirable technique.

Note 1:  If the resource owner 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).

[STEP 3]   From the Accessing PC (XPS13-2), Access the Shared Resource on XPS8940

In this example, 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 folder. 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.

Limited Test of Restricted Sharing

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:

In general, to add a specific username to a share, do this:

Problems

Below are some problems I have encountered in my testing.

  1. Missing PCs in Network Display:  Windows 10 and Windows 11 usually do not display all the PCs in the network, e.g., when clicking Network in the Navigation pane of a File Explorer window. (This is a very old problem.) This is true even if the PCs have specified shared resources in a workgroup. However creating a shortcut for \\XPS8940\zzz seems to get to the zzz shared folder reliably even if XPS8940 was erroneously not displayed as being in the network.
  2. Cannot Share Individual Files: Despite Windows documentation, sharing cannot be specified for individual files. See details about a possible bug -- probably bad documentation.
  3. Share Setups Fail without Notice:  Sometimes very simple share setup procedures fail and give no notice that a share was not created. See details about a possible bug and a workaround.
  4. Usual Inability To Share MS Account Resources:  The apparent incompatibility between MS account Hello and file sharing (see IMPORTANT ACCOUNT CONSIDERATIONS!) causes a lot of confusion. You want to have Hello on all accounts for ease of use and added security. Yet the MS account password restriction makes it harder for an MS account to share any of its resources with users on other PCs.

    To enable an MS account to share its resources, I have 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 have 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 network with only local accounts, which works well for me, I'm sticking with that for now.

    In contrast, if you have an MS account and it has 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.

  5. "Password Protected Sharing" Setting Ignored -- Appears As If Always "On":  If a user tries to access a resource on a "remote" PC, no matter whether "password protected sharing" is turned on or off in Network and Sharing Center settings, a valid username and associated password still seem to be required on that PC for the user to specify in a credential. The access fails if the username is unknown on the "remote" PC, or if the username is known but a valid password is not specified in the credential, e.g., to be used when creating a network shortcut. An internet search shows many people have hit this problem in Windows 11. However if a valid username and password are used (as the "on" setting of "password protected sharing" requires), the sharing works, independent of the on/off setting.

A final thought on problems:  If things don't work initially as expected or something stops working that had worked before, try rebooting the PCs that are involved.

Testing Some More Elaborate File Sharing

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.

Test setup:  For testing multiple sharing accounts of various types, on PC B I created twelve small folders, with four folders for each of 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 to M.

Test procedure:  I then went to PC A, signed in as jeff, aka J (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; see above.

Indirect share:  One good result of this testing was proof that an "indirect share" does work. For example in test TMK (see the diagram on the left below):  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..

Two Configurations for File Sharing

The configuration on the right 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.

The configuration on the left is the most general case: 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.

Indirect share diagram
History of Changes to This Document
Home