@Tal Floodthis wouldn't be a hardware problem; it's an OS configuration issue. And access issues like this typically require making some sort of change on the system hosting the share, not the one connecting to it, since that's where all of the sharing settings actually apply. A system's file/folder sharing settings don't come into play in contexts where the system is a client connecting to a network share hosted somewhere else; they only apply to files/folders being hosted from that system. The fact that the prompt for credentials is sporadic definitely doesn't help, but please check the following:
- Please clarify exactly how you're attempting to "see" these other PCs. Are you mapping a network drive letter to them by manually entering a share path, such as \\WifesPC\SharedFolder? Or are you just browsing in Windows Explorer? If the latter, can you try the former to see if it makes a difference? The reason I ask this is that Windows 10 1809 and newer have an old and very insecure protocol called SMBv1 disabled by default for new installations, but people who upgraded to that release from an earlier release might still have it enabled. And SMBv1 affects the ability to discover network systems by broadcast, which is what happens when browsing. So if your new XPS 15 came with 1809 or later out of the box, it might not discover other systems reliably (or at all), even though your Win7 system and a Win10 system that started out on an earlier release would be able to do that.
- Make sure that all systems have your network configured as Private rather than Public, since that affects the firewall rules that are in place. If you find any that were set to Public, then I would go back and recheck your "password-less" folder sharing settings, because a) you may need to enable that again on the Private firewall profile, and b) enabling password-less folder sharing on networks configured as Public is a security risk, since that would make your files available even when you had your laptop joined to public WiFi networks such as airports, coffee shops, etc.
You might find that you can access your systems more reliably (and efficiently) by mapping a drive letter to them or simply just entering \\TargetPC\NetworkShare into a Windows Explorer window rather than browsing around every time.
@Tal Flood in addition to my note above, if you're using this folder sharing to facilitate backups, I would strongly advise you against disabling password-protected file sharing, because that means you're enabling read and write access without requiring any sort of authentication. The reason that's a major risk is that if one of your systems ever gets hit by ransomware, it will hop right on over to those other systems that are allowing unauthenticated write access and lock up those files too. Ransomware absolutely looks for network targets that it can attack. Using password-free sharing to grant read-only access for use cases like sharing a media library is one thing, but using it for read/write access is a really bad idea. One best practice for handling this scenario of backing up to a network location is the following:
Create a share on the host PC dedicated to storing backups, separate from any other data.
Configure permissions such that one particular user has read/write access to the share and everyone else has read-only. Optionally create a user account on this host system for this purpose.
Store the credentials of the read/write user with your backup application so that it can get the access it needs to perform backups. The mechanism and feasibility of this depends on what application you use. I use Macrium Reflect for backups, and it supports this just fine.
When you want to connect to the share yourself within Windows, do so using read-only credentials, because normally that's all you need anyway since normally you'd just be accessing backups in order to restore some data out of them. If you need read/write access, then temporarily connect using those other credentials, but do not leave that connection open persistently.
The end result here is that the only place that will have read/write credentials is your backup application, which means that if ransomware hits, unless it knows how to extract stored credentials from that specific backup application, the only access available within your Windows users session will be read-only, if even that, which means it will not be able to damage your backups.
@Tal Flood You don't have to do anything special to enable SMB protocol overall. You only have to do that if you specifically want to enable SMBv1 on Win10 1809, but that is a very bad idea. This Microsoft blog is a solid write-up, but basically SMBv1 was designed long before anybody was thinking about security, it has been leveraged in a number of security exploits and malware/ransomware outbreaks, and SMBv2 which is not only more secure but also much faster has been around since 2007, so there's really no good reason to re-enable SMBv1. If anything, Microsoft was long overdue for disabling it by default, but they tend to be that way to preserve compatibility since some people insist on continuing to run ancient hardware. I just helped someone last week who's still got a system running Windows 98.
The ability to browse your system by clicking "Network" should not be considered sufficiently valuable to justify opening your systems to the types of security risks created by SMBv1. I personally would go around and actively disable it on your other systems.
If your backup is failing halfway through, that suggests a connection stability issue, which would have nothing to do with your sharing settings because those only come into play when opening the connection in the first place. I realize you said browsing and VPN work fine, but backups try to push a lot more traffic than typical network usage, so it's possible to see problems there while other more typical usage patterns work fine. I've seen that myself. If you happen to have an Ethernet to USB adapter, it would be interesting to see what happens when you connect that way. If sharing works and network connections are stable in that setup, then it's a WiFi issue, in which case check for WiFi driver updates, router firmware updates (could be an interoperability issue between the router and the specific WiFi chipset in your XPS even if other systems work fine), and maybe at least as a test bring your laptop closer to your router.
I realize you need reliable nightly backups and that you want them to occur in an automated fashion. But nothing about that sentence requires you to use password-less file sharing. There are multiple ways you can have an automated, scheduled backup job open an authenticated connection to a network target just prior to the job and then close it afterward. It just depends on the tool you're using and how exactly it implements scheduled background jobs.
It did come with 1809 out of the box. I am now on 1909.
I expect that when I am in File Explorer and I click Network, the other computers on the network will appear as icons I can click on. It's worked that way for me since early Win7 and I understandably expected it to work this way on this new Win10 machine as well.
Based on some other things I saw I did type a share path into the address bar yesterday, and it did work. Her computer wasn't visible under network but it did create that connection. But like I say, connection comes and connection goes. I go through a backup process, and halfway through it will fail because "network path not found".
I did enable SMB connections as described on a Windows 10 forum, and I am still where I am today. Also, my network is already configured as private.
I suppose I could map a drive letter to her machine and click on it when I want to go into it, but in actuality, I almost never go into her folders and manipulate files and whatnot. The main reason I want network to her machine is so I can backup up files to it each night, which I want to do as a schedule process that occurs overnight while I am in bed. For it to work properly, the connection has to be active on a reliable basis. I don't want to have to be there to manually kick off the backup process. Otherwise, if I can't automate the scheduled process, what are computers for?
jphughan
9 Legend
•
14K Posts
0
April 13th, 2020 11:00
@Tal Floodthis wouldn't be a hardware problem; it's an OS configuration issue. And access issues like this typically require making some sort of change on the system hosting the share, not the one connecting to it, since that's where all of the sharing settings actually apply. A system's file/folder sharing settings don't come into play in contexts where the system is a client connecting to a network share hosted somewhere else; they only apply to files/folders being hosted from that system. The fact that the prompt for credentials is sporadic definitely doesn't help, but please check the following:
- Please clarify exactly how you're attempting to "see" these other PCs. Are you mapping a network drive letter to them by manually entering a share path, such as \\WifesPC\SharedFolder? Or are you just browsing in Windows Explorer? If the latter, can you try the former to see if it makes a difference? The reason I ask this is that Windows 10 1809 and newer have an old and very insecure protocol called SMBv1 disabled by default for new installations, but people who upgraded to that release from an earlier release might still have it enabled. And SMBv1 affects the ability to discover network systems by broadcast, which is what happens when browsing. So if your new XPS 15 came with 1809 or later out of the box, it might not discover other systems reliably (or at all), even though your Win7 system and a Win10 system that started out on an earlier release would be able to do that.
- Make sure that all systems have your network configured as Private rather than Public, since that affects the firewall rules that are in place. If you find any that were set to Public, then I would go back and recheck your "password-less" folder sharing settings, because a) you may need to enable that again on the Private firewall profile, and b) enabling password-less folder sharing on networks configured as Public is a security risk, since that would make your files available even when you had your laptop joined to public WiFi networks such as airports, coffee shops, etc.
You might find that you can access your systems more reliably (and efficiently) by mapping a drive letter to them or simply just entering \\TargetPC\NetworkShare into a Windows Explorer window rather than browsing around every time.
jphughan
9 Legend
•
14K Posts
0
April 13th, 2020 11:00
@Tal Flood in addition to my note above, if you're using this folder sharing to facilitate backups, I would strongly advise you against disabling password-protected file sharing, because that means you're enabling read and write access without requiring any sort of authentication. The reason that's a major risk is that if one of your systems ever gets hit by ransomware, it will hop right on over to those other systems that are allowing unauthenticated write access and lock up those files too. Ransomware absolutely looks for network targets that it can attack. Using password-free sharing to grant read-only access for use cases like sharing a media library is one thing, but using it for read/write access is a really bad idea. One best practice for handling this scenario of backing up to a network location is the following:
The end result here is that the only place that will have read/write credentials is your backup application, which means that if ransomware hits, unless it knows how to extract stored credentials from that specific backup application, the only access available within your Windows users session will be read-only, if even that, which means it will not be able to damage your backups.
jphughan
9 Legend
•
14K Posts
0
April 13th, 2020 13:00
@Tal Flood You don't have to do anything special to enable SMB protocol overall. You only have to do that if you specifically want to enable SMBv1 on Win10 1809, but that is a very bad idea. This Microsoft blog is a solid write-up, but basically SMBv1 was designed long before anybody was thinking about security, it has been leveraged in a number of security exploits and malware/ransomware outbreaks, and SMBv2 which is not only more secure but also much faster has been around since 2007, so there's really no good reason to re-enable SMBv1. If anything, Microsoft was long overdue for disabling it by default, but they tend to be that way to preserve compatibility since some people insist on continuing to run ancient hardware. I just helped someone last week who's still got a system running Windows 98.
The ability to browse your system by clicking "Network" should not be considered sufficiently valuable to justify opening your systems to the types of security risks created by SMBv1. I personally would go around and actively disable it on your other systems.
If your backup is failing halfway through, that suggests a connection stability issue, which would have nothing to do with your sharing settings because those only come into play when opening the connection in the first place. I realize you said browsing and VPN work fine, but backups try to push a lot more traffic than typical network usage, so it's possible to see problems there while other more typical usage patterns work fine. I've seen that myself. If you happen to have an Ethernet to USB adapter, it would be interesting to see what happens when you connect that way. If sharing works and network connections are stable in that setup, then it's a WiFi issue, in which case check for WiFi driver updates, router firmware updates (could be an interoperability issue between the router and the specific WiFi chipset in your XPS even if other systems work fine), and maybe at least as a test bring your laptop closer to your router.
I realize you need reliable nightly backups and that you want them to occur in an automated fashion. But nothing about that sentence requires you to use password-less file sharing. There are multiple ways you can have an automated, scheduled backup job open an authenticated connection to a network target just prior to the job and then close it afterward. It just depends on the tool you're using and how exactly it implements scheduled background jobs.
Tal Flood
4 Posts
0
April 13th, 2020 13:00
Thank you for your input. I will take your admonitions under consideration.
Tal Flood
4 Posts
0
April 13th, 2020 13:00
@jphughan
It did come with 1809 out of the box. I am now on 1909.
I expect that when I am in File Explorer and I click Network, the other computers on the network will appear as icons I can click on. It's worked that way for me since early Win7 and I understandably expected it to work this way on this new Win10 machine as well.
Based on some other things I saw I did type a share path into the address bar yesterday, and it did work. Her computer wasn't visible under network but it did create that connection. But like I say, connection comes and connection goes. I go through a backup process, and halfway through it will fail because "network path not found".
I did enable SMB connections as described on a Windows 10 forum, and I am still where I am today. Also, my network is already configured as private.
I suppose I could map a drive letter to her machine and click on it when I want to go into it, but in actuality, I almost never go into her folders and manipulate files and whatnot. The main reason I want network to her machine is so I can backup up files to it each night, which I want to do as a schedule process that occurs overnight while I am in bed. For it to work properly, the connection has to be active on a reliable basis. I don't want to have to be there to manually kick off the backup process. Otherwise, if I can't automate the scheduled process, what are computers for?