[SOLVED] win10 1803 to samba issue

timsoft · 09-04-2018, 06:49 AM

hi all, I have a win10 v1803 pc. it can see three slack14.2 samba pcs (fully patched), but one pc it will not show the shares unless i use the machine's ip address instead of name.
as it works on the other three I am at a loss as to why this problem one does not work.
the output of testparm on the problem pc is

Code:

[global]
        server string = toltest
        workgroup = ONE
        log file = /var/log/samba.%m
        max log size = 50
        guest account = netuser
        map to guest = Bad User
        server role = standalone server
        dns proxy = No
        idmap config * : backend = tdb
        guest ok = Yes
        hosts allow = 10.1.1. 127.


[homes]
        comment = Home Directories
        browseable = No
        read only = No


[printers]
        comment = All Printers
        path = /var/spool/samba
        browseable = No
        printable = Yes
        guest ok = No


[tmp]
        comment = Temporary file space
        path = /tmp
        read only = No


[part1]
        comment = part1
        path = /mnt/part1
        force group = root
        force user = root

and the output of a working pc testparm is

Code:

[global]
        server string = toldev
        workgroup = ONE
        log file = /var/log/samba.%m
        max log size = 50
        guest account = testing
        map to guest = Bad User
        server role = standalone server
        dns proxy = No
        idmap config * : backend = tdb
        guest ok = Yes
        hosts allow = 10.1.1. 127.


[homes]
        comment = Home Directories
        browseable = No
        read only = No


[printers]
        comment = All Printers
        path = /var/spool/samba
        browseable = No
        printable = Yes
        guest ok = No


[qvcstuff]
        comment = qvc dev stuff
        path = /data/qvc
        force group = root
        force user = root
        read only = No


[blah1]
        comment = testing one
        path = /data/testing
        force group = users
        force user = testing
        read only = No


[blah2]
        comment = testing two
        path = /data/testing2
        force group = users
        force user = testing2
        read only = No

the error i get on clicking the toltest pc from the win10 pc is 0x800700 and on running the windows diagnoses it says

Quote:

file and print sharing resource(TOLTEST) is online but isn't responding to connection attempts.

(on port 445)

it does work if i use the ip address, so it appears to be name resolution related in some way, but as three other slackware14.2 pc's work just fine I can't see the difference. I've compared hosts files and smb.conf files.

does anyone have any suggestions, thanks?

Olek · 09-05-2018, 03:51 PM

Try to disable Windows firewall.

kjhambrick · 09-06-2018, 05:40 AM

timsoft --

Did it work when you disabled the Windows Firewall as Olek suggested ?

I also wonder if a firewall on the Slackware side is in the way ?

And ... I've not had this problem on Win10 but it used to bite us a from time-to-time on Win7 ...

The Fix in those days was to delete cached Credentials via 'Credential Manager' the Windows PeeCee ; try to connect again with the correct Credentials and save the new Credentials.

Oh yeah ... not sure why but on some machines we had to reboot the PeeCee after deleting Credentials ... that was not a treat

HTH.

-- kjh

tomtomjkw · 09-06-2018, 06:23 AM

I would try enabling SMB 1.0/CIFS File Sharing Support in add/remove Programs -> Windows Features on your Windows 10 machine. If it does not help, check in services.msc whether you have Function Discovery Provider Host and Function Discovery Resource Publication set to automatic start.

timsoft · 09-06-2018, 07:37 AM

well to answer the suggestions. I tried dissabling the windows basic firewall, but still no difference. I can access other slack14.2 machines, but not the problem one (unless i use it's ip, in which case it works just fine). I've checked the machine (and the others), non are using a firewall. output from iptables -L is

Code:

Chain INPUT (policy ACCEPT)
Target  prot  opt  source  destination
Chain FORWARD (policy ACCEPT)
Target  prot  opt  source  destination
Chain OUTPUT (policy ACCEPT)
Target  prot  opt  source  destination

I have no problem connecting to any of the machines from windows 7, and windows 10 connects to all but the problem pc with regular browsing, which is a clean build with just slackware 14.2 and all patches, but no other non-stock packages.
I did have a look at credential manager but the only credential in there was a windows-live one, as all the network shares tested are guest only.
SMB1/cifs file sharing (automatic removal and client) is already enabled/installed

cmiranda · 09-06-2018, 07:40 AM

Have you tried specifying the minimum SMB protocol in smb.conf? See here for more details. You can also set the maximum protocol but it's probably not necessary. You'll have to restart Samba once you make the changes.

https://www.cyberciti.biz/faq/how-to...linux-or-unix/

EDIT: I just realized that you said it worked when you used the IP address but not when using the hostname. Check your nsswitch.conf and resolv.conf settings. Also, make sure you have the /etc/hosts file set up correctly. I had to set it up the following way for Samba to work correctly with Windows PCs.

x.x.x.x hostname hostname.domainname

Usually, the hostname and FQDN are flip-flopped when shown in the commented text.

timsoft · 09-06-2018, 08:14 AM

I found if I add an entry in the windows hosts file for the problem pc I can browse it just fine. This implies it is a pc name browsing issue, as adding the hosts entry just over-rides other lookups. (although the pc name shows in the network, it just fails to let me open it without the hosts entry).
That may mean it is an issue with the master browser, which is an old slackware 13.1 machine running samba 3.5.5
I have checked the hosts file on this pc and it includes an entry for the problem machine, as well as one for working ones as well.

I should mention that all pcs (windows and slackware) are on a windows workgroup, the windows pc's are home version.

EYo · 09-06-2018, 08:43 AM

Quote:

Originally Posted by timsoft

Code:

[global]
        server string = toltest
        workgroup = ONE
        log file = /var/log/samba.%m
        --snip--

the error i get on clicking the toltest pc from the win10 pc is 0x800700

What does the toltest server log say when win10 is giving the 0x800700 error? Debug level log might reveal something helpful.

timsoft · 09-06-2018, 09:00 AM

another update. I changed the netbios name on the problem machine to "mary" and it is accessible!. changing back to toltest and it is not. What could cause one network/netbios name not to work when other names work fine?

kjhambrick · 09-06-2018, 10:16 AM

Quote:

Originally Posted by timsoft

another update. I changed the netbios name on the problem machine to "mary" and it is accessible!. changing back to toltest and it is not. What could cause one network/netbios name not to work when other names work fine?

Yikes, timsoft.

That is a new one on me.

Windows seems to cache a number of networking data and who knows where the old toltest name might be cached ???

Thanks for the info though ... I'll try that out next time before I have to revert to accessing the Linux Server via IP Address ...

-- kjh

timsoft · 09-06-2018, 12:51 PM

i set the logging level to 2 (level 1 didn't provide much help) and got

Code:

[2018/09/06 18:19:44.891327,  2] ../source3/smbd/reply.c:705(reply_special)
  netbios connect: name1=TOLTEST        0x20 name2=MACDIARMIDPC   0x0
[2018/09/06 18:19:44.907282,  2] ../source3/smbd/reply.c:746(reply_special)
  netbios connect: local=toltest remote=macdiarmidpc, name type = 0

for the /var/log/samba.10.1.1.209 file (10.1.1.209 is the ip (dhcp) of the macdiamidpc which is the windows 10 pc.)
As far as I can work out, this means the win10pc was trying to talk to the slack (toltest) pc, and got a response.
why it got no further is a mystery. It will be good to get to the bottom of it. I am suspecting something weird as it is obviously not a firewall issue, or configuration issue on the machine (changing the netbios name getting it to work implies that), so it may be win10 and the local master broswer (the slack13.1 server) that are the cause somehow. I would have said it was the hosts entry on the slack13.1 machine apart from the fact that another 14.2 machine is accessed just fine with a hosts entry on the LMB, and 2 slack14.2 machines (vm's) are accessed fine without hosts entries on the LMB.

abga · 09-06-2018, 03:09 PM

Could this help on your WindowsUpdate(c) machine? (that's what I call Win10 - it's continuously updating/optimizing, impossible to do work on it)
https://social.technet.microsoft.com...ie-caches.aspx

timsoft · 09-07-2018, 04:23 AM

thanks for the link. I have tried flushing caches but it makes no difference. The slackware machine is connectable with a different name, but not with the name toltest. there is nothing innately special about that name, and there is not another machine with the same name. hence the mystery. My suspicion is on my main file server which is running samba and dnsmasq on slack13.1 (and also running other stuff like mail and web). I think that is the local master browser, and as the oldest version of slackware, is my target for blame!
What is causing it to mess up win10 file access on another slack box is unknown, but as the problem appears to be name related, rather than config or hardware related, that is the only conclusion I can come to. I'm not sure how to prove that theory, or how to fix it.
Windows saying it can't access port 445 on the machine is not helpful (no surprises) as changing the (toltest) name allows access, so it can have nothing directly to do with the toltest machines configuration. I can only imagine that somehow, for that name only, it is getting different settings from elsewhere on the network which don't work.
any pointers on how to find out have to check what settings are got from where would be great.

abga · 09-07-2018, 05:34 AM

Quote:

Originally Posted by timsoft

My suspicion is on my main file server which is running samba and dnsmasq on slack13.1 (and also running other stuff like mail and web). I think that is the local master browser, and as the oldest version of slackware, is my target for blame!

You can check if your main file server is set as the master browser by looking at its samba conf file after: local master = yes
If that's true, it will be this file server resolving netbios/wins names and you might have some old (or none) config for the toltest name defined:
https://www.samba.org/samba/docs/old...html#id2581357
https://www.oreilly.com/openbook/sam...k/ch07_03.html

On Linux machines you could play with tcpdump (+ Wireshark) or nmblookup and check who is resolving the names:
https://www.samba.org/samba/docs/3.5...blookup.1.html

And on Win10 try this:
https://scottiestech.info/2009/02/14...ows-workgroup/
Or go "professional" with windump / or Wireshark directly:
https://www.winpcap.org/windump/
https://wiki.wireshark.org/NetBIOS
https://www.wireshark.org/docs/dfref/n/nbns.html
https://wiki.wireshark.org/NetBIOS/NBNS
https://www.wireshark.org/docs/dfref/w/winsrepl.html
https://osqa-ask.wireshark.org/quest...p-and-or-range

EYo · 09-07-2018, 07:39 AM

Quote:

Originally Posted by timsoft

My suspicion is on my main file server which is running samba and dnsmasq on slack13.1 (and also running other stuff like mail and web). I think that is the local master browser, and as the oldest version of slackware, is my target for blame!

I am stabbing in the dark, can't recreate your environment here. FWIW found this post on archlinux forums:
https://bbs.archlinux.org/viewtopic....851717#p851717
it says:

Quote:

Okay, I figured the issue out after the fact. I'm posting this now in case anyone else gets a similar issue and ends up here.
I solved the problem by moving from dnsmasq to dhcpd. Dnsmasq was caching netbios names. The client was getting caches IPs that were meant for the server.

Perhaps fiddling with the dnsmasq config will lead somewhere, assuming you already looked at those logs. HTH