[SOLVED] samba ip6 and windows 10 issues

my situation is as follows.
I have a samba server running 14.2 fully patched which works fine for ip4 networking. in fact my isp only offers ip4 connections so any ip6 traffic is local. the server has a fixed ip4 address.
if i disable ip6 on a win10 pc (v2004) then I can browse the local lan, and the shares on any particular machine.

by default win10 ships/installs with both ip4 and ip6, but always uses ip6 by preference. eg if i ping my server name (it also provides dhcp via dnsmasq) it will respond using ip6 addresses unless i disable ip6 on the win10 pc.
unfortunately, with ip6 enabled, the win10 pc will show the other samba servers on the network, but will error out when being told to show the shares on a machine.
I do have guest shares on the samba server, and windows 10 network config allows network discovery and file and printer sharing.
i can access the shares via ip4 address with ip6 enabled on the win10 pc.

has anyone had success with current windows10 ip6 enabled and browsing/accessing samba shares by name who could share tips?

This reads like you're still using SMB1 (for NetBIOS support)? Samba itself works with IPv6, but NetBIOS name resolution is IPv4 only.

I have both IPv6 and IPv4 enabled on a Windows 10 PC and it can reach my samba server no problem at all. However, I'm strictly using SMBv2 (samba version 4.11.5). I use the newer WS-Discovery (wsdd) protocol on the samba server so that it is 'discovered' on the Windows hosts.

FWIW
https://github.com/christgau/wsdd

Originally Posted by ferrari I use the newer WS-Discovery (wsdd) protocol on the samba server so that it is 'discovered' on the Windows hosts. FWIW https://github.com/christgau/wsdd

Brilliant!

thanks very much ferrari for the pointer. yes I was aware that netbios didn't work on ip6, and didn't know how to acheive the same net browsing results.

I haven't spotted a wsdd or wsdd2 package on slackbuilds.org and looking at the samba mailing list I couldn't see if it has been incorporated after it's initial mention in 2016. It also isn't in current that I can see. I would assume that wsdd2 would be quicker as it is written in C rather than python.

I'll see if I can create a slackbuild for it. If so, it would be a prime candidate for 15.0 as well, as using samba on a network with win10 machines is the norm these days. Getting local share browsing working without having to dissable ip6 and resort to smb1/netbios would be useful, as all my clients are win10 or slackware.
On that note, is wsdd/2 supported in the network browsers in dolphin ? it would be useful to have that available on the slackware side of things as well, rather than using fixed ip4 addresses which I use at the moment.

Yes, wsdd2 is likely better. Not all distros have packages for it (although I know openSUSE has a community package available).

I'll see if I can create a slackbuild for it. If so, it would be a prime candidate for 15.0 as well, as using samba on a network with win10 machines is the norm these days.

Yes, I agree.

On that note, is wsdd/2 supported in the network browsers in dolphin ? it would be useful to have that available on the slackware side of things as well, rather than using fixed ip4 addresses which I use at the moment.

Yes, I'm using KDE Plasma 5 (with Dolphin 20.04.3), and it has WS-Discovery working. I use it to discover my Windows samba hosts (providing shares). Works well.

BTW, if using a firewall on a Linux host, ports 5357 (TCP) and 3702 (UDP) need to be open for WSD to work.

Originally Posted by timsoft I'll see if I can create a slackbuild for it.

Looks pretty straightforward. If you end up not doing it, I'd be happy to create one. Just let me know.

I've created a slackbuild and tested it. As soon as submissions are open again, i'll get it submitted.
I now don't have to enable legacy smb1 and disable ip6 to get my samba shares visible from win10.

addendum.... without smb1 enabled in windows10 I get odd behaviour where share browsing does not work until I restart the Function Discovery Provider Host in windows. Alternatively if you click diagnose, then imediately the shares are shown without going through the steps of the fault finding wizard.

On the windows pc's the following services should be set to auto start.
Function Discovery Provider Host
Function Discovery Resource Publication
this can be done via service manager, or via setting registry keys
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\fdPHost]
Start=dword:00000002
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FDResPub]
Start=dword:00000002

which would require a windows restart.
this doesn't fix the problem entirely, but why you need to restart the FDPH to get the shares to show implies an issue with one or the other, ie either windows' fdph service is not reliable independant of anything else, or wsdd2 provides output which causes fdph to throw a wobbly.
anyone who could test this to see if they get the same problem would help, incase it is just me.
the slackbuild for wsdd2 is temporarily at http://tol.tree-of-life.co.uk/wsdd2.tar.gz

more oddness. on the windows client without smb1 it does not show the shares on the samba server, but if you click on network in file exporer, then change the view to "details", and add the extra columns "discovery method" and "ip address", then just the act of showing the preview of "details view" allows the shares to be instantly discovered.

I haven't experienced any issue with my Windows 10 Pro client. The samba server shows up in the file explorer under 'Network' > 'Computer' consistently (along with any other Windows hosts).

i'm using win10 home 64bit exclusively with slackware 14.2 fully patched. The server shows up ok, but the shares are hit and miss on machines with smb1 not enabled. I also noticed some file-save dialog boxes take a long time to list the shares (crimson editor for example). maybe they use older common-dialog forms which don't include default to wsd and try everything else before trying wsd.

The following references mention about selecting 'Automatic (Delayed Start)' for a number of services involved with Windows file sharing...
https://www.ghacks.net/2018/04/17/fi...-1803-upgrade/
https://answers.microsoft.com/en-us/...d311b14?auth=1

1. Press the Windows Key and R at the same time to bring up the Run dialog. 2. Type services.msc in the Run dialog and press Enter. 3. For each of the following services, locate the service in list, right-click the service and select Properties. Then set the Startup type to Automatic (Delayed Start) and select Apply. * Computer Browser (Browser) * Function Discovery Provider Host (FDPHost) * Function Discovery Resource Publication (FDResPub) * Network Connections (NetMan) * UPnP Device Host (UPnPHost) * Peer Name Resolution Protocol (PNRPSvc) * Peer Networking Grouping (P2PSvc) * Peer Networking Identity Manager (P2PIMSvc) 4. Restart Windows.

I'm not seeing computer browser or Browser in services. I've tried changing all the rest of the list to delayed start. i use a workgroup rather than homegroups, I'm not sure if that makes a difference. on restart I get the same behaviour. as previously reported.

I've never used homegroups (as far as I know removed from Windows 10 anyway). I can't really help further as Windows ain't my thing. I really only use it for work.

thanks for the time and help anyway. I use windows and linux and work and home, linux file/web/mail servers and windows/linux desktops (all slackware 14.2/win10) I make heavy use of cifs mounts for linux, and for windows some mounted drives for shares, the rest just browseable. The windows 10 versions are all home rather than pro versions (cheaper license). It does mean that windows domain stuff os not available, but that is an additional complication I've never really needed anyway.
I've never had any problems when mounting or browsing using ip addresses, but it is not so convenient, and for customers I need it to be fast and reliable. It's just the fact that although sometimes clicking on the server shows the shares straight away, at other times it doesn't and I have to restart the service on windows, or change the view to include discovery type, before the shares show.
i'll keep this thread marked unsolved for now and if I come accross a fix I'll post it here for anyone who is interested.