This is probably something simple and I'll kick myself later ... I've move a computer that does Samba shares to a different network and IP. Now I can't connect to it. I can ssh, http and POP/SMTP to it, but not samba mount. All I get in my /var/log/messages file is:
I'm doing:
Where should I look for the problem?

Hopefully 24.142.999.99 is a made-up address, since it is not a valid IP.

Please check /proc/filesystems. If cifs is not present, you may need to load filesystem support with:

If that was the problem you can add an entry to /etc/modules-load.d/ to automatically load the cifs module at boot.

Define what you mean by move to another network.

Do you have a specific hosts allow directive in your smb.conf?

Yes, it is fake.
cifs was not present, but this same config worked find before I moved the computer. Nevertheless, I triled the modprobe cifs (and verified it was loaded). It didn't help.
I mean that I had this on my local LAN with IP 192.168.0.15. Then I phyiscally move this computer to another location with a public/static IP. As mentioned, all other ports work.
I did not, but I added one to smb.conf. No go.

I have ports 139 and 445 configured with iptables. Doing 'telnet localhost 139' (or 445) works. Doing 'telnet FDQN 139' (or IP) does not. Do you suppose the ISP is blocking these ports?

Did you check your "interfaces" setting in smb.conf? There you can set it to only listen on certain interfaces, certain subnets, on a certain address. If those are set and you change network without re-setting it to match you would expect this behavior.

Later ... Yes! The ISP, Spectrum, does block ports 139 and 445: https://www.spectrum.net/support/internet/blocked-ports. I've added 'smb ports = 9999' (also fake) to smb.conf and changed my mount to:
That worked! I could mount this share!!

But that's Linux. Now I have to figure out how to mount that with Windows 10 ...

IMHO it is a very bad idea to use SMB directly over the internet which is why ISPs block those ports. smb3 is better but is not 100% secure either IMHO. Better to use VPN. Even though you change ports the script kiddies will eventually find you.

2 members found this post helpful.

I agree, that's why I am going to try to set up using NFS for now. If I can mount the NFS exports locally, I can then Samba/cifs share those NFS mounts on my local linux host for mapping by my local Windows computer. I've done this before.

Thus far I have configured the NFS export of the remote computer:
and opened port 2049 on the firewall.

I am running nfsd, rpc.mountd and rpc.statd. I can now mount via nfs:
Note that I needed nfsvers=4. Using nfsvers=3 I got the error:
even though rpc.statd was running.

I've also successfully Samba-shared this NFS mount and mapped it from my local Windows 10. All seems to work, but much slower than when this was all local.

Next I will try using a nfs4 tunnel of ssh. Here's on link, but I haven't tried it yet. https://web.archive.org/web/20130526...-nfs4-over-ssh

I am not an expert in nfs security but you probably should be using version 4 with kerberos authentication over the internet. I suggest using a VPN like wireguard or OpenVPN. I thought about suggesting using sshfs -> samba share but I do not think that would be reliable.

There is NO kind of drive sharing that is very secure over wild network (the internet as one example). CIFS and NFS are fine in secure environments. Over secured VPN they suck, can be problematic, and are still less than secure. SSHFS is my choice, and only brought up on-demand for short periods. I find better ways to operate than drive mounts wherever possible.

I figure we will invent a perfectly secure drive mount system one day, and two days later some hacker will figure out how to break it.

michaelk and wpeckham: Thanks for your feedback. Background: For 20 years I've had my main "work" computer in my home office with my own mail server on a dynamic IP. I've logged into that from a Linux workstation, also at home, running KDE and that workstation would mount some of the folders via cifs for access by Dolphin, Kate, etc. This workstation also runs a Windows 10 Virtual Machine, and the cifs mounts were useful for mapping these same folders for access by Windows. Originally, that was all on an internal 192.168.0.0/24 network.

Lately, services like gmail have been cracking down and not allowing mail from dynamic IPs. Therefore I had the choice of getting a static IP for my home office, or moving the main "work" server to an office location with a static business IP. I chose the latter ... for now.

So far things are working OK with the NFS mount to my linux workstation and cifs mounts from Windows to the linux workstation. I am using nfs v4. I'll add tunneling when I get a chance. I have restricted the nfs export to just my home IP address.

More feedback is welcome, but I think since my original question has been answered I should probably mark this as solved.