Windows 10 Build 1809 und OMV Shares sind in der Netzwerkumgebung verfügbar.

  • I've now rebooted a Windows 10 system multiple times and my NAS is always listed in the Explorer network view. Hopefully i will not need to start and use this system (Windows) for months again now :)

    i guess you have smb1 client activated in the windows extra features - which i dont have and don't want to use :)


    i have 3 pc's 2 with the latest fast ring windows 10 (aka 19h1) and one with win10 stable - all of them have smb1 deactivated (see screenshot) so they don't use netbios to get the names of network client and then you need wsdd...


    if smbclient 1.0 is enabled you're using netbios (but i guess i don't have to tell you this :D)...



    i have tried it with all three pcs not one of them recognises omv in network as long i wont restart wsdd.py - then all of the running pc's will find and see omv unless they get rebooted... so if have tried to enable smbclinet1.0 on one machine and it doesn't matter if wsdd.py is started or not it will always find omv - but using smbclient1.0 is something i don't rly want to (i'm not that kind of security fascist but this a rly bad thing in my opinion - and afaik also disabled on new windows 10 installs)...


    i have done many tests with wsdd back in day bc i was sick and tired of not having omv in my network and wsdd2 was the only thing which has worked out without problem so far...



    yeah and i wish i can also switch to linux or back to FreeBSD on my workstations but this would not work bc i need them for work also and we have so much custom windows only software that would be a nightmare to port to *nix :)

    • Offizieller Beitrag

    I've never had any issues with any W10 machines on my network and OMV shares, but with the inclusion of WSD, OMV now displays under File Manager -> Network, I don't shutdown OMV, but laptops and my worksation are shutdown after use.

  • Curiously SMB1 was enabled, I assumed that MS defaults that to disabled. After disabling that protocol my wsdd host was not displayed after reboot.

    thx, good to hear that it is not only me that can reproduce this *pewwwww*


    yep it has become disabled with newer version but on old versions it is still activated - afaik :)


    votdev another thing i want to mention - i have seen you don't want to implement a switch for wsdd (which i'm also so as unnecessary) but if you mask wsdd.service and want to change something in smb/cifs it's becoming a real pain :D


    in my case i have worked around it by removing wsdd.service and cloning my wsdd2.service to wsdd.service and this work - but what if someone only want to mask it? :D

  • I have noticed one minor issue with the implementation of wsdd, in OMV:


    wsdd reports "workgroup" as the workgroup name by default, which ignores the workgroup name as it is set in OMV.

    you have to set your wg in the startupfile (/lib/systemd/system/wsdd.services)


    • -w WORKGROUP, --workgroup WORKGROUPBy default wsdd reports the host is a member of a workgroup rather than a domain (use the -d/--domain option to override this). With -w/--workgroup the default workgroup name can be changed. The default work group name is WORKGROUP.

    but maybe @votdev can add the following:


    set the Workgroup according to smb.conf and be verbose

    • SMB_GROUP=$(grep -i '^\s*workgroup\s*=' smb.conf | cut -f2 -d= | tr -d '[:blank:]')
    • wsdd -v -w $SMB_GROUP
  • you have to set your wg in the startupfile (/lib/systemd/system/wsdd.services)

    Is this workgroup anachronism still needed even by Windows 10 (serious question since I don't use this OS)? I mean this is sick stuff from last century which made some sense back then when we had to deal with NBT, WINS and other stuff nobody needs today any more.

    • Offizieller Beitrag

    wsdd reports "workgroup" as the workgroup name by default, which ignores the workgroup name as it is set in OMV.

    ?? Where, because mine is fine as OMV appears under File Manager -> Network


    you have to set your wg in the startupfile (/lib/systemd/system/wsdd.services)

    There should be no need to do this surely as there is a setting BindsTo=smbd.service


    Is this workgroup anachronism still needed even by Windows 10

    Yes if you want to see/locate other machines on your network. When MS implemented the Homegroup this negated the necessity of setting a workgroup option, personally I never used it, could never seem to get it to work, or to communicate with other non MS machines. W10 removed Homegroup, so you're back to setting a workgroup. What W10 does do during set up is to ask if you want your machine to be discoverable by other machines on your network, this is fine if all your machines are W10!

    • Offizieller Beitrag

    i guess you havent even taken a look at the wsdd.py readme or?

    No.


    and what has a binding to do with the broadcasted standardgroup "workgroup" of wsdd.py - it dosn't care what samba does...

    Perhaps I should have added a ? to my comment rather than leave a statement/observation.


    But why is it then I have made no changes to wsd that was added from update management but my OMV appears under File Explorer -> Network?

  • But why is it then I have made no changes to wsd that was added from update management but my OMV appears under File Explorer -> Network?

    there is no need to change anything - the question was how the by wsdd.py broadcasted "workgroup" can be changed bc it is not the same as in smb.conf - and the reason therefore is that wsdd.py broadcast workgroup as standard and dosn't care whats samba provides...


    so in readme of wsdd.py is stated how you can match this and if were using wsdd.py it isn't mabe a bad idea to do that to get it matched - in which way it's needed/helpful by/for win10 i donno but if someone asked how he can change it i tell him how if i knew it ;)

    • Offizieller Beitrag

    I understand what you're saying regarding @flmaxey comment re the question of workgroup, and I understand your comment in respect of the broadcasted "workgroup" in wsdd.py and therefore your comment re not caring what samba provides.


    But my understanding is that wsdd.service calls wsdd.py and your reply to @flmaxey is to add the wg in the startup file wsdd.service with reference to the github example "set the Workgroup according to smb.conf and be verbose"


    This is the extract from wsdd from github;
    [Unit]
    Description=Web Services Dynamic Discovery host daemon
    ; Start after the network has been configured
    After=network-online.target
    Wants=network-online.target
    ; It makes sense to have Samba running when wsdd starts, but is not required
    ;Wants=smb.service


    This is from the install of wsdd from omv's update management;
    [Unit]
    Description=Web Services on Devices (WSD) daemon
    BindsTo=smbd.service


    That was the reason why I questioned was it actually necessary to make any changes (which you answered), but wsdd does not use the hostname of omv but the workgroup name applied to smb, which should be same as omv's. So my understanding is the BindsTo would use the workgroup name from smbd.

  • Just to add to the confusion.


    I have a virtual machine that always shows up in windows explorer.


    And on the same windows machine, none of my other OMV machines show up that are bare metal.

    Curiously SMB1 was enabled, I assumed that MS defaults that to disabled. After disabling that protocol my wsdd host was not displayed after reboot.


    I opened an issue for that, see https://github.com/christgau/wsdd/issues/8.

    • Offizieller Beitrag

    To clarify:


    This issue presents when a user changes the workgroup name from the default "workgroup" in OMV's GUI. (We'll say the workgroup name is changed to "salesgroup" for example.) The wsdd service advertises the server as being in "workgroup" by default, regardless.


    This behavior ignores settings in OMV, under Services, SMB/CIF, the settings tab (the workgroup name) and System, Network (the domain name).


    And, yes, I'm aware of the options in the wsdd script to change this, but this difference is an inconsistency between what wsdd is advertising on the network and the settings in the OMV GUI.
    ____________________________________


    On the practical side of it, with Win 10, workgroup names don't really matter. Win 10 lists hosts and servers under their advertised workgroup names, in Windows Explorer under network, even if there are more names than one. As it seems, Windows 7 lists hosts and servers under more than one workgroup name as well. (With Win7, this was not the original default behavior.)


    AD domains are another matter. I don't have the setup to test that.
    ____________________________________


    The solution may involve a script that changes wsdd options based on OMV GUI settings. With a new installation, this might be one script.


    When wsdd is added by an update to OMV, as it was pushed out in the recent update (wsdd 0.3-1), another script might be needed to sync OMV's GUI settings with the options in wsdd.

    • Offizieller Beitrag

    This is this sick concept explained here, right?

    Yep that's it I tried using it under W7, to me it was one the worst options they ever included, the idea being it was easier for home users to set up sharing between windows machines.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!