Where to start? Can't get Samba to function

iroc409

[H]ard|Gawd
Joined
Jun 17, 2006
Messages
1,385
I've had this file server for years, and have all the config files saved so when I need to do a periodic bare-metal rebuild all I need to do is install the software, put my config files back into place and it I'm back in no time. It has worked every time, except this one. I've been pulling my hair out for two days just trying to get Samba to run, and it runs fine, but nothing will connect to it.

I've taken a lot of stuff out of smb4.conf because I had set a lot of tuning parameters that worked well in the past but got warnings this time that I shouldn't have them

The machine is a Dell T110ii with a e3-1225v2 CPU and 32Gb RAM running FreeBSD 12.1-RELEASE-p1. The first time I compiled everything from ports, this time I installed using packages. The only things I've installed are Samba (4.10-11), NUT, and rsync. I've configured pf to run with the same simple config I've had for years.

I can't figure out the problem, but neither my OpenSuSE desktop nor my Windows HTPC can connect to it. SSH works peachy!


rc.conf:
clear_tmp_enable="YES"
hostname="servy"
ifconfig_em0="inet 172.16.12.55 netmask 255.255.255.0"
defaultrouter="172.16.12.95"
local_unbound_enable="YES"
sshd_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_logfile="/var/log/pflog.log"
samba_server_enable="YES"

smb4.conf
[global]
workgroup = WORKGROUP
netbios name = SERVY
server string = Servy
interfaces = em0
security = user
encrypt passwords = true
load printers = no
hosts allow = 172.16.12. 127.
hosts deny = all
invalid users = root nobody
printable = no

[DataShare]
comment = Data Share
path = /data/DataShare
valid users = ben MediaPC
writable = yes
write list = ben

[Ben]
comment = Ben's Files
path = /data/Ben
valid users = ben
public = no
writable = yes
write list = ben

pf.conf:
# PF configuration file, for file server duty

#variables
interface="em0"
secondary="em1"

#options and optimizations
set block-policy drop
set skip on lo0
set loginterface $interface

#Firewall settings for em1/empty NIC
block in log on $secondary all
block out log on $secondary all

#outbound rules
pass out log quick

#inbound rules
block in log on $interface all
pass in quick on $interface proto icmp all
pass in log on $interface proto tcp from 172.16.12.0/24 to ($interface) port { 139, 445 }
pass in log on $interface proto tcp from 172.16.12.0/24 to ($interface) port { 22 }
 
Last edited:
Well, I'm open to suggestions if there's anything glaring but it's not worth beating my head against the wall until it bleeds for days. I'm going to spin up a test mule and see where that goes. Obviously enough has changed I just need to start from scratch and whittle my way in to what I'm used to and see what happens.
 
Well, now that I've wasted a whole weekend on it I think it's a software glitch. It seems like Samba has been having iterations of this error, sometimes in large part, for over a decade. I haven't been about to dig any up relating to 4.10-11 yet, but tons of older versions.

I didn't think about it but had a terminal warning that popped up and checked the log:
root@servy:/var/log/samba4 # cat log.smbd
[2020/01/20 20:17:11.800888, 0] ../../source3/smbd/server.c:1788(main)
smbd version 4.10.11 started.
Copyright Andrew Tridgell and the Samba Team 1992-2019
[2020/01/20 20:17:12.043450, 0] ../../lib/util/become_daemon.c:136(daemon_ready)
daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
[2020/01/20 20:36:06.692066, 0] ../../source3/smbd/server.c:1011(smbd_accept_connection)
accept: Software caused connection abort

testparm returns normally, tried several configs including very minimal with no help, so I think this is just an error. Probably going to try one last time with 4.8 instead and see if that works. They've changed syntax on a lot of things, the socket options I've been using is now deprecated, smbpasswd is no longer the preferred password tool. A lot of things have changed, but I've tried all that and wasted a lot of time with it. Maybe 4.8 will fix it, but I'll have to install from ports instead of packages (which is usually what I do but this was so painful I don't want to keep messing with it).
 
mostly a centos guy here.. Usually when I have these issues, its because the network stack hasnt finished starting before samba starts. If that doesn't work, I'll disable se linux and try again. You may have to rip that band aid off and quit using your old commands / configs knowing that they've all been depreciated.
 
either used hosts deny, or hosts allow, not both.
also their has been some changes to authentications versioning and you may need to call a specific version. to test if that is the issue try building a share with no security and see if anything can connect to it.
 
So far, still no dice. Tried a fresh install, straight to Samba 4.8 this time, still refusing to connect from Windows or OpenSuSE. Nothing shows up in Samba's log whatsoever. I have a hunch it's a problem with DNS.

Now when I run smbclient -L servy, it retuns "Unable to initialize messaging context protocol negotiation failed: NT_STATUS_IO_TIMEOUT". If I try smbclient -L localhost, it returns "Unable to initialize messaging context Connection to local host failed (Error NT_STATUS_CONNECTION_REFUSED).

From what I've been able to dig up, others having these particular errors have had DNS issues. I can't remember what prompted this, but recently I started putting home.domain.com (with a domain that I own) on the router. With DHCP enabled it picks that up, and so I think it's trying to ask DNS for a FQDN and not getting the answer it wants and so it's just timing out. Complete swing in the dark. So, either rip out all of the home.domain.com, or set up entries in my DNS to see if that fixes it. If not, I guess it's time for a Synology LOL.


mostly a centos guy here.. Usually when I have these issues, its because the network stack hasnt finished starting before samba starts. If that doesn't work, I'll disable se linux and try again. You may have to rip that band aid off and quit using your old commands / configs knowing that they've all been depreciated.

Yeah, the only thing is it appears that the syntax for the shares is still the same--but a lot of the global stuff has changed. One of the guides indicated the old tuning syntax should be done now through the kernel config files instead of smb4.conf. Definitely starting from scratch.

As far as the network stack, in the startup stuff that gets rattled off, it indicates almost to the end / at login prompt that smbd/nmbd is fired up and ready to serve connections. The only thing that comes after that is updating motd, late filesystems, powerd, configuring vt, ssh, cron, background file system checks. The network stack seems to load well before then when I'm watching it start, but I certainly couldn't rule out

either used hosts deny, or hosts allow, not both.
also their has been some changes to authentications versioning and you may need to call a specific version. to test if that is the issue try building a share with no security and see if anything can connect to it.

I've used the hosts deny and hosts allow for years with no issue. It was in the guides that I used to build the config. That being said there's a lot of bad advice so I have no issues omitting that. I have tried some without any security, basically all I put in the global parameter was the NetBIOS name. Still times out. I started to even fire up just a blank machine without my array on it so I wouldn't crash anything, but for some reason stopped that. Overconfidence I had the process figured out maybe, but I might fire that back up so I can stop risking my data until I have this figured out LOL.
 
lsof -ni:139 and 445

check port bind..

set [bind to interfaces only] line in smb.conf to FALSE and reload samba
 
WmRbmf5.png
 
  • Like
Reactions: Mega6
like this
Well, if this won't bake your noodle. I spent all weekend on it but here's the fix. It was DNS.

When taking down my Proxmox server and going back to rPis for network services, I was looking into some of the capabilities of PiHole. The recommendation is to do conditional forwarding on the DNS so it can get hostnames for more readbable data. To set all that up you need to use a domain for the network, so I set all that up and it didn't work. All so I didn't have to set up DHCP on PiHole instead of the router... based on consensus. Which is amusing because it wasn't too long ago that running DHCP on a separate server was all the rage.

Anyway, so I backed out all the local domain stuff and (was basically using home.domain.com for a domain I own). Once I did that I set up a no-security base Samba config and it came right up just like normal. What a mess!
 
the easiest way to troubleshoot DNS is to see if you can connect via IP address. surely that was like step 2 in the troubleshooting guide? either way, at least you have a game plan now.

honestly on my networks i build everything out via the IP address and then backtrack and add in DNS entries after stuff is working. DNS is always a fist fight between the network guy and server guy and half the time they are both wrong.
 
  • Like
Reactions: Mega6
like this
the easiest way to troubleshoot DNS is to see if you can connect via IP address. surely that was like step 2 in the troubleshooting guide? either way, at least you have a game plan now.

honestly on my networks i build everything out via the IP address and then backtrack and add in DNS entries after stuff is working. DNS is always a fist fight between the network guy and server guy and half the time they are both wrong.

I always use IP addresses locally, so that's what I was using to connect from the beginning. I'm lazy and it's just easier. I think I remember from the early days of FreeBSD it freaks out if you use anything but a resolvable FQDN, or you just use a host name only. I didn't think anything about DNS because I just don't use it much.
 
ouch, that does not sound like fun.. but at the end of the day, you figured it out, it didn't kill you, you didn't give up, and now you have another experience to put into your tool bag of trouble shooting skills.
 
Back
Top