WD support suggested that I should feel free to do my own tests, which I have. The results of the tests suggest that the WD TV Live does not support SMB2 or 3 and therefore will no longer be able to access shares on a device without SMB1. For those faint of heart you can avoid my explanation and wait for the movie to come out. Others may persevere and stumble on tools and ideas that will shed light on other WD TV Live connectivity problems they may have.
An important consequence of the Windows 10 Fall Creator update is the loss or failure of the SMB1 master browser function. It is the master browser function that keeps track of computers/devices in the network neighborhood. It is the function that the WD TV uses to identify in the “Network Shares” window, those devices that are sharing files and folders. If the function is not working properly or not available, the WD TV cannot identify device names to select in the “Network Shares” window. If you can’t select a device in the “Network Shares” window, you can’t access the shares!
What I refer to as the “loss” of the SMB1 master browser function, is simply a result of SMB1 being deactivated or uninstalled from the device that is sharing files. The “failure” of the SMB1 master browser function is not as simple to explain. Some posts on this forum have reported that, after the Windows 10 Fall Creator update, in spite of the fact that SMB1 was not deactivated or uninstalled, the browser function did not appear to be working properly, that the updated code was somehow buggy and that if we waited long enough, Microsoft will fix the code. I haven’t been able to confirm that conclusion.
My LAN environment consists of two Windows 10 Pro desktops, a test pc that is also an audio media server, and a home production pc that is also a video media server. Both are are up 24/7. I also have a Windows 7 laptop that is turned on occasionaly. Any of these devices, when turned on, could potentially become the SMB1 master browser, keep track of the devices on the network and provide the WD TV with the device name and address. In the SMB1 network, in simple terms, when a device is turned on, the device announces its existence by broadcasting its name and address across the LAN. A pre-existing active Master Browser (say another Windows PC) will pickup and retain that information and make it available to the WD TV when you ask for source from a network share. To complicate things, if there are multiple Windows pcs on a network, they will negotiate periodically to determine which of the Windows pcs will take on the master browser function. If a master browser pc is shutdown, the responsibility is picked up by another Windows pc. To complicate things further, the WD TV Live can act as the master browser. (I understand some routers can also as master browser.)
Based on personal experience, I have learned that not all devices are created equally in performing the master browser function. Over the years, network connectiviy problems with the WD TV Live that I have experienced, had nothing to do with pc file/folder share permissions, firewall blocking, configuration errors, etc. It was simply as a result of the master browser function being passed to another device. For example, the most stable master browser is my Windows 10 Pro test pc, it has the longest up time. I have set parameters in the Windows pcs to default all negotiations for the browser function to the test pc. In spite of this, on occasion (e.g. a planned or unplanned shutdown of the test pc), one of the other devices becomes the master browser temporarily and when the test pc is restarted and becomes the master browser again, it does not have a complete list of all devices in the network (maybe the devices haven’t announced their existence). When I turn on the WD TV Live and scan for network shares, one or both of the pcs will be missing. The way I typically resolve this is by turning off all the pcs and the WD TV Live, turn on the test pc (my preferred master browser), turn on the production pc (to force an announce broadcast) and then the WD TV Live.
Now that I have demonstrated my understanding of how the SMB1 browser function works (and I welcome correction of any misunderstanding), I can explain my tests and what I think the results mean with respect to WD TV Live SMB1,2,3 support or lack thereof.
I decided that I was going to remove SMB1 from my Windows 10 home production pc with the video media shares. The test machine was up and acting as Master Browser. The WD TV Live was off. I turned on SMB1 auditing using the Windows Power Shell command “Set-SmbServerConfiguration –AuditSmb1Access $true”. Microsoft included this tool to help identify any devices on a LAN still using SMB1. A system log entry is created when a device tries to access shares on the pc with SMB1. The log entry identifying the device name and an explanation of sorts, can be found at “Computer Management : System Tools: Event Viewer : Applications and Services Logs : Microsoft : Windows : SMBServer : Audit / Operational”. I unchecked SMB1 in “Programs and Features”, and SMB1 was removed. The production pc was rebooted.
Observation one. Connections setup for auto connect between the production pc and test computer shares (and vice versa) were not effected; however, as expected the “Network” neighborhood function of the Windows File Explorer no longer displayed the test computer in the “Network” tree.
Observation two. The WD Live TV was started. The “Network Shares” menu initiated a request for device names on the network and the master browser was still aware of the production pc and its location (a more accurate way of putting that is that the master browser had not forgotten the name and location in spite of the SMB1 uninstall and reboot). Selecting the device name in the WD TV Live “Network Share” menu resulted in a user name / password error. This suggested that the WD TV Live was able to locate and communicate with the production pc but met with a rejection. The “Operational” log entry indicated “A client attempted to access the server using SMB1 and was rejected because SMB1 file sharing support is disabled or has been uninstalled.” Since Microsoft did not provide a means to log an SMB2 or 3 event, their is no evidence that the WD TV Live attempted a retry using SMB2 or 3. What this does prove however is that in spite of Windows rejecting the connection on the basis of SMB1 not installed, the WD TV Live mistakenly interprets the rejection as a userid / password error, and if it has SMB2 and 3 somewhere in its bowels, instead of doing a retry with the alternate SMB, prompts the user for an alternate userid and password.
Observation three. Both the test pc and the WD TV Live were powered off. Since SMB1 was uninstalled, the production pc did not become a master browser. The WD TV Live was powered on again. At this point, neither of the pcs are master browser and so the WD TV Live has the opportunity to become master browser. Unfortunately, the Windows production PC no longer announces itself to the master browser and therefore when you enter the WD TV Live “Network Share” menu there is no device name displayed to select. And that’s the end of that!
dbglobal, mike27oct and msdobrescu, thank you for your input.
From the description you have given of your circumstance, it is not clear if SMB1 was deactivated/uninstalled during the update. Without an indication of the status of the “Program Feature” settings for SMB1 after the update, the version of Windows 10 (Pro or not), and clean install vs update, any conclusion is speculative. Although Windows 10 Creator Update went smoothly on my test pc, a subsequent update on my production pc was a disaster and I had to go back to the previous version.
Sorry about detail. Congratulations if you have gotten this far. You indicated having WD TV access to a drive connected to a Windows USB port. If I am right that the media player only supports SMB1, that would suggest SMB1 was not removed during the update, because the share process is similar for a USB attached device. Also, if I am right, that the effect of removing SMB1 from Windows is not restricted just to the WD media but could potentially impact their NAS product line, you might want to explore other forum members experience.
Your scenario is very interesting. The fact that you are running Windows Pro and that SMB1 is still checked in Windows feature after the update suggests that SMB1 has not been removed. I am going to hazard a guess here. You didn’t indicate whether the Linux pc was up before the WD TV was turned on. From your description it appears that the WD TV live was the master browser. The Linux pc announced its name and address to the WD TV in a network broadcast. The WD TV live saw the pc name in the Network Shares and you were able to access the Linux share using SMB1 and play the music files. When you rebooted the pc and started Windows, the WD TV Live was still master browser, “remembered” the pc name and address, displayed the pc name in the “network shares” menu and successfully connected to the pc shares. Subsequently, you turned off the WD TV Live and the Windows PC became the master browser. This is where the process gets sketchy. I assume that when the WD TV Live was turned on again, the PC continued to be the master browser. Did you use a network scanner to monitor the WD TV communicating with the pc? Are you able to determine which of the two devices are acting as master browser? Have you tried shutting off both the PC and the WD TV Live, starting the media player first, and then the pc and comparing results? As I indicated above, some have reported an actual bug in the Windows Creator Update browser code that results in SMB1 connectivity issues in spite if SMB1 not being deactivated or uninstalled.
You mentioned that you have an Android device that can access the pc shares while the WD TV can’t. I have a similar situation with my iPad. I have two media player apps that have SMB support that no longer can access the video files on my production pc. I have a third app that has no problem playing the video files and my only explanation is that the third app must be using SMB2 or 3.