Posts by ARI

    According to a story by Woody Leonhard on, the Tuesday Microsoft patch for Windows 7 breaks SMBv2.

    The patches are KB4480970 and KB4480960

    Removing these patches apparently restores functionality.

    There is much discussion about OMV shares not being visible to Windows 10 computers. This is not a problem of OMV. This is an issue created by Microsoft with the latest Creators edition. Below is probably the best explanation I found at This is just a cut-n-paste.


    The Computer Browser service is broken in Windows 10 1703 and is gone from future releases of Windows. The below really applies for workgroups you may find info that helps with your issue, you should be able to remove all trace of SMB v1.0 from your network.Yes, that's right folks, after 25 years of being able to browse our networks Microsoft have decided Workgroup users don't need this functionality any more. This article from Microsoft explains:

    SMBv1 is not installed by default in Windows 10 Fall Creators Update 2017 and Windows Server, Semi-annual Channel

    They are getting rid of SMB v1.0, which is fair enough, it has real security issues. The Computer Browser service relies on SMB v1.0, rather than upgrade the Computer Browser service so Workgroup users are still able to browse their networks they are simply removing it. From the linked article:

    For home and small business users who use Network Neighborhood to locate Windows computers, you shoud map drives to the computers so that you no longer have to browse for them.

    Not even spell checked and suggesting we only do it to access data we could map drives to, indicating a total lack of understanding as to why we need network browsing. Network browsing is an essential tool for doing a visual check of which computing resources are available in a Workgroup. The command "net view" allows us to quickly report which computers are available in the Workgroup and thereby use the information to run system reports and perform various tasks. Locating and enabling printers becomes far more difficult without Computer Browsing.

    This does not affect AD users, those businesses which need to or have the luxury of being able to invest in server hardware and software. Users who's data is in the cloud, on the internet have less issue, it may only affect attaching printer resources which can be worked around. Of course all Microsoft staff fit into these groups so the lack of browsing functionality in Workgroups is probably insignificant to them.

    So what we need now is either a great little tool to browse our networks that doesn't rely on SMB 1.0 or an upgraded Computer Browser service.

    The service is broken in Windows 10 Creators 1703. If a 1703 PC is the Master Browser only that computer has Computer Browsing, if a non-1703 is the Master Browser all the non-1703 PCs have Computer Browsing. This is the reason why browsing appears to work sometimes and not others, rebooting PCs forces a Master Browser election, which will change which PC is the Master Browser and can introduce the issue.

    To work around the issue involves setting one computer to be the Master Browser. Some people have third party devices on their network they can set to be the Master Browser, all non-1703 can browse. To identify which computer is the Master Browser you can run the command

    nbtstat -a ComputerName

    for each computer in the Workgroup. The computer that is the Master Browser is the only one that has the value


    in the list.

    To set which computer is the Master Browser you need to make registry modifications on that computer. Browse to the registry key:

    Change the value of MaintainServerList from Auto toYes

    If it is not there, add a new String Value IsDomainMaster and set it toTrue

    You may need to reboot to activate this. If you want to be absolutely positive no other PC takes the Master Browser role you can set the value ofMaintainServerList from Auto to No on all other PCs in the Workgroup.

    You may even find that a non Microsoft third party device on the network attempts to take over the Master Browser role.

    I re-iterate that this is just a short term workaround, Computer Browsing for workgroups is history for Windows 10. If you know of any great tools for browsing Workgroups that don't rely on the older protocols I'd be happy to hear from you.

    840 Points

    End of cut-n-paste

    From my experience, computers that were upgraded to Creators and already had a persistent share are unaffected. But a new user on that computer, or a new Creators computer may not find the share. While I have the setting to allow OMV to become the Master Browser, that has been known to fail if a Windows 7 computer is added to the network-- even though it does not show as the MSBROWSE. Again, In my experience, only a complete shutdown of all Windows computers and booting one-by-one restores the OMV computer as the MSBROWSE. Also, if you plug-in a USB drive into a Netgear router (like a Nighthawk with ReadySHARE), that router will seize control of MSBROWSE from OMV

    If you need to add an existing share, this syntax at the command shell should work:


    You will be prompted for the user name and password (which must exist in OMV already)

    V: is drive letter you want to assign
    OMVCPUNAME is the name of the computer as it appears to windows/workgroups
    SHARENAME is the root folder name of that OMV share

    Also more syntax here:

    Not sure if this posting is a duplicate or will help anyone, but I have never found this issue to be caused by OMV.

    There are people here that know more than I but since no one responded here's my experience. I run a couple of different RAID1 OMV servers which means two drives and I have no hot swap spare installed. When a drive failed-- the system kept running. I did and orderly shutdown and removed the offending drive. I installed a new drive and restarted the system. I added the drive to the array. The system repaired itself. I did sinply take the old drive and inserted to a Thermaltake USB drive cage and wiped the drive using another Linux box.

    I am unclear as to your configuration (not enough information provided). I hope you are not trying to zero-out the offending drive on the same system. I hope you have not removed the working drive(s) to another system as the RAID will collapse. I believe there are directions on the forum from others that replace failing drives. This is not at all unusual.

    Before I deploy any RAID system server (OMV or other) I always live-crash a drive to ensure stability even when crippled and then replace the crashed drive to make certain it reconstructs. Frankly I am a coward to deploy a production system without proving it works and that most-importantly I know WTF I am doing (which is always suspect on my part) to provide repair.

    The network IP(s) maybe the same, but I have generally found that the change of the NIC (thus MAC if only using the motherboard NIC) will cause the introduction of a new eth#. If you have a second NIC in a MB slot and are using that same NIC and it is eth1, then it will probably work fine on boot in the new MB. In that event the )new_ motherboard NIC may be seen at eth2. Regardless above advice is accurate.