nmbd: Windows 10 browsing? about samba HOT 24 CLOSED

I forgot to mention exposing port 137 (add -p 137:137 to the command line) when enabling nmbd. I've just added a note to the README.md (it's uploading now).

If that doesn't resolve it, are they both on the same network segment? IE, no router in between. You can check by running a traceroute to your server. If the server isn't the first hop, then the broadcast from the server isn't being forwarded to the client network.

from samba.

@dperson some more infos:

• the newer version of samba / cifs don't need port 137 anymore
• i already made sure port 137 was open
• yes they are all on the same network segment (192.168/16)
• browsing works fine on mac an linux clients, just not windows 10 client

@dperson or others: can anyone confirm network browsing work / can see on any local windows clients machines of yours? What was the version of windows? Any special settings?

BTW:

I am using pipework (which sets up MACVLAN L2 bridges bound to the eth0, like VMWare's 'bridge' mode networking).

Suppose I could try changing that temporarily to host network on 1 of the containers. To see if any improvement being seen in windows. However that is not going to be any real-life solution for me as have lots of of samba servers as containers, not just a single one.

from samba.

I'll test it (I'm pretty sure I have a windows 10 VM...) when I get home tonight (UTC-5).

Please do test without the pipework networking bridge as well, and let me know your results.

Thanks.

from samba.

I have the same issue on both Win7 & Win10 laptops. They can see each other, samba share is accessible using IP, but both can't see samba share.
And samba is also visible from Linux.

docker-compose.yml

app:
  image: dperson/samba
  restart: always
  volumes:
    - /data/shared:/shared
  net: host
  ports:
    - 137:137
    - 139:139
    - 445:445
  command: samba.sh -s "Movies;/shared/movies;yes;no;yes" -n

Log

$ docker-compose up
Creating samba_app_1
Attaching to samba_app_1
app_1 | [2016/02/12 20:15:12.920527, 0] ../lib/util/become_daemon.c:136(daemon_ready)
app_1 | smbd version 4.1.17-Debian started.
app_1 | Copyright Andrew Tridgell and the Samba Team 1992-2013
app_1 | standard input is not a socket, assuming -D option
app_1 | STATUS=daemon 'nmbd' finished starting up and ready to serve connections*****
app_1 |
app_1 | Samba name server INTELNUC is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.3
app_1 |
app_1 | *****`

from samba.

This doesn't surprise me. Hmm you even did the net: host thing I was about to.

Actually I happen to have Windows Vista machine here too in addition to the Win10 computer. Just didn't get around to it yet. I am doubtful either one of them will actually work.

Ironically what is most important to me is using Samba on Mac OS X. Unfortunately there it is very slow / unresponsive to initially connect to shares. But that is nothing to do with this particular issue.

from samba.

After something (I really don't know what is changed, configuration is the same and one single action is restart of all laptops) now I can see samba server on Win10 laptop. However, it still not visible on Win7.
It is interesting because possible reason is different workgroup, but two windows laptops can see each other in same case.

from samba.

@igrybkov ok I will try net: host then.

from samba.

@dreamcat4 @igrybkov I didn't get a chance to test yet myself.(things have been a bit crazy in meat space). In case it's related (it was mentioned above) I've added an option to set the workgroup/domain for the samba server. If you use -w <workgroup_name> as an option, or set the WORKGROUP environment variable, then the specified name will be used by samba.

Thank you for reporting the issue and investigating solutions.

from samba.

Yeah NP. No time either for me so far. Still it would be immensely helpful to keep this issue open so we can continue to comment / gather more infomation.

Probably do not need speculative fixes to your image, until we can be sure the exact problem. For example maybe if I can come back later, take some wireshark logs or something, it can eventually be something more 'solid' to pass up / report to SAMBA project team.

from samba.

In this case it was something that I thought might be useful to people, even if completely unrelated to this issue.

Also yes we can definitely keep the issue open until we can come to a better understanding of what's going wrong. It may well be something that needs to be resolved in upstream (Debian or Samba).

from samba.

Well this is interesting:

That is one of them. But have not set the hostname properly in my samba containers to know which one it is. Then:

[EDIT]

Actually there's more:

It failed to fix. Yet perhaps such error msg was a valuable clue,

Hmm. Fixed networking error by following this youtube. But had to reboot the win10 box. However the server 'SMB' does not want to show up in network browsing. Lost it.

from samba.

Ok hi again,

Recently have switched networking solution from pipework --> new docker networking with external bridging. Now it seems the auto-discovery is working on my windows 10 client.

Therefore I shall close this issue. So long as nobody else wants it to remain open. Kind Regards.

from samba.

Ok hi again,

Recently have switched networking solution from pipework --> new docker networking with external bridging. Now it seems the auto-discovery is working on my windows 10 client.

Therefore I shall close this issue. So long as nobody else wants it to remain open. Kind Regards.

I wondered if you could share your own docker-compose commands to enable this functionality with dpeson/samba? I have this problem with windows 10 and would be interested to fix it but as a laymen, I don't know where to start with adding the correct network settings.

The sole purpose is just to get windows 10 to automatically discover the server like it used to with older SMB1/2 clients and NBMD.

from samba.

Several people have reported that in order for NMBd to work, you have to use the hosts network, or bridge it out so it's on the local network directly. The -p port forwarding NAT doesn't work with it.

from samba.

I have no doubt NMBd is working, in fact on my Android phone I can discover the network shares fine.

The issue in my usage case is Windows 10. NBDd doesn't work any more, possibly because of the removal of SMBv1 protocol due the security risks surrounding it. It has been replaced by WSSD hence my feature request: #271 exists.

As for the Network mode, I did what you suggested and tested out host networking. The same applies. I reverted back to bridge networking and the shares still don't show. In fact, bridge should be the default method docker uses if nothing is specified.

Given the user who got discovery working hasn't replied and this issue was made back in 2016 I am guessing this was before Windows scrapped NMBd, which is why he managed to get it working.

from samba.

Yeah WSSD isn't a part of samba, and it has the same issues with going through a docker NAT as NMBD. Together I'm not really sure about adding it.

from samba.

samba must enable SMB1.0 protocol to support netbios name browse, also start from win10 later version it has to enable SMB1.0

so the point is nmbd is a past. it's broadcast based.

from samba.

https://www.ixsystems.com/community/resources/how-to-kill-off-smb1-netbios-wins-and-still-have-windows-network-neighbourhood-better-than-ever.106/

this has more information on the topic.

from samba.

samba must enable SMB1.0 protocol to support netbios name browse, also start from win10 later version it has to enable SMB1.0

thanks, and what you say is true. However SMB v1 is a very insecure protocol and is best not used. WSSD has since replaced it in SAMBA, but as the above reply, it hasn't been implemented within this docker container.

from samba.

Well, I think win10 seems to support mDNS, which is cool, no need to run host network, and can also remove nmbd support, which is a very old netbios protocols if you don't need support old windows clients.

from samba.

This docker image has a section describe mDNS usages https://hub.docker.com/r/stanback/alpine-samba
@dperson maybe update docs so people aware of this, and can get it to work without nmbd.

from samba.

Uhm... somebody told me that multicast udp on docker is fundamentally broken. I am not certain myself however I do find getting multicast to work being a problem with my other containers too.

from samba.

Tested my self, mDNS works on mac linux and win10, there's no reason why we need nmbd anymore
mDNS is perfect it uses multicast address 224.0.0.251:5353 udp, I think this can work on docker container which doesn't require it to be host network stack, as multicast address is not subnet related any one can join it.

My working setup:
Ubuntu server 20.04.1
mDNS uses systemd-resolved as it is in the system so no need to run avahi-daemon (you can also run such in a container)
and this samba docker image

from samba.

This docker image has a section describe mDNS usages https://hub.docker.com/r/stanback/alpine-samba
@dperson maybe update docs so people aware of this, and can get it to work without nmbd.

In the link you shared it essentially points out its pointless for Windows as mDNS isn't currently supported. Only used on OSX/Unix.

This topic is about auto-discovery on Windows.

from samba.