Interferences with a SMB server

Expected Behaviour:

I am using Pi-hole within an LXC container with Proxmox VE as a hypervisor on some generic Chinese mainboard with an Intel Embedded Chip. Furthermore, I am running a couple of home servers, even one Hackintosh which works great with Pi-Hole. Basically, everything works fine.
I expect Pi-Hole not to affect any file shares within the local network.

Actual Behaviour:

I am experiencing issues with my Ubuntu 18.04 LTS Server running SMB and Nextcloud.
If the Pi-Hole server is online for a couple of days I can't access the SMB shares anymore. The simply timeout. The weird thing is: I access the files on my Nextcloud through an SMB share. That means the SMB service is not experiencing general updates.
Restarting the Pi-Hole system via the GUI always solves the problem.

Debug Token:

https://tricorder.pi-hole.net/lncy6jz1jr

I hope someone experiences the same issues and found a solution or a workaround. Of course, I could restart the Pi-Hole system via a cronjob, what I am currently doing but that's not really convincing for such a great piece of software.
Thanks a lot already :slight_smile:

Restarting the whole system or just the DNS server?

Restart the system! Restarting the Resolver doesn’t solve the problem.

Then it is unlikely to be an issue of Pi-hole. It seems you need to restart the whole system so also the SMB server is restarted. Can you check if restarting the SMB server alone fixes it as well?

Well, maybe I expressed myself unclearly.
The SMB/ Nextcloud server is one device.
The pihole server is running on a physically different server.

I am using Pi-hole within an LXC container with Proxmox VE as a hypervisor on some generic Chinese mainboard with an Intel Embedded Chip

That's where the problem lies. Two completely separate machines "interfering" with each other is quite strange...

The only way I can think of Pi-hole may interfere is if you were accessing your SMB mounts by name and Pi-hole wouldn't be able to resolve those names.

However, if that would be the case, I would expect the issue to manifest itself immediately.

Could you confirm you access the shares by local names?
Where did you define those names?

And in order to confirm it would be a DNS issue, could you provide dig or nslookup results for those respective local domains once your shares have become inaccessible?

1 Like

The SMB shares are of course accessed by the NetBIOS name of the server. In the macOS Finder, they show up with the respective name of the server. The dialogue where credentials must be entered doesn't open and connection times out.

nslookup output

nslookup 10.32.8.4 <-- IP-adress of the SMB server
Server: 10.32.8.8 <-- Pi-Hole
Address: 10.32.8.8#53
4.8.32.10.in-addr.arpa name = n50nas.fritz.box. <-- resolves to the correct name

If you were indeed using NetBIOS names to access your shares, then Pi-hole wouldn't be involved - those would be resolved via lmhosts files and/or a local WINS server. Furthermore, they are limited to 15 characters and may not contain any dots.

On the other hand, the name produced by your reverse nslookup output is a DNS name (also, it is longer and contains dots).

If that nslookup was indeed run after your SMB have become inaccessible as I requested, it would again suggest that DNS is working.

But I'm not entirely sure you ran that command as intended, as it is a reverse lookup using an IP.
I asked for a lookup for a local domain that you use in a failed attempt to access an SMB share, run right after accessing the share failed.
Running the command in that way would help to pinpoint if and how DNS could be involved.

Aaah ok, thank you for your explanation.
Running nslookup as you intend gives the following result, which still suggests, that DNS ist working properly.

nslookup n50nas
Server: 10.32.8.8 <— the Pi-Hole server
Address: 10.32.8.8#53

Non-authoritative answer:
Name: n50nas.fritz.box
Address: 10.32.8.4 <— the SMB server

Now one could think the SMB server is the problem. But then the question is: Why does a Pi-Hole restart solves the problem, while restarting the SMB server (the service or the whole server) has no effect at all.
Thanks for your patience :slight_smile:

Sorry for being stubborn:
Did you run that nslookup after your SMB have become inaccessible?

I'm asking because you said (emphasis mine):

So I wouldn't expect you to provide results straight away, but only after the issue did reoccur at some later time.
Was this indeed the case?

Yes, this this morning it was actually the case. So I could not access the SMB share when I ran nslookup.

Thanks for clarifying. :wink:

At the time you tried to access the share unsuccessfully, did Pi-hole register any related DNS queries?

The following command may help with that:

grep -n n50nas /var/log/pihole.log

First I have to apologise for my "every few days". It happen to fail more often than I anticipated, because I don't access the share very single day. So it was a little Bir misleading.
Via the admin interface I had a live look at the live log while I tried to access the share which failed.

Apr 27 16:23:37 dnsmasq[334]: query[A] n50nas.fritz.box from 10.32.8.15
Apr 27 16:23:37 dnsmasq[334]: forwarded n50nas.fritz.box to 10.32.8.1
Apr 27 16:23:37 dnsmasq[334]: reply n50nas.fritz.box is 10.32.8.4

So 10.32.8.15 is my Mac from which I've send the query. For me is looks alright. Pi-Hole doesn't blocks anything or fails resolving the address.
Thanks for your help so far.

Yes, this looks alright, and confirms DNS is working, making it harder to attribute your observation to Pi-hole.

Could you share the corresponding SMB share you were tyring to access?

Also, would IPv6 be available in your network?
While it wouldn't explain outright permanent failures, it could explain an only temporary failure or slowdown before falling back to IPv4, as most current OSs would prefer IPv6 over IPv4.
(edit: assuming an AAAA record for n50nas would be missing)

That's the share from the smb.conf file, if you mean that.
To clarify: The problem is, that I don't even see the login dialog in Mac OS.

[Benedict]
comment = Benedict
path = /mnt/3tb_2/shares/Benedict
write list = benedictbolender,smbadmin
valid users = benedictbolender,smbadmin
force user = smbadmin

But here are good news, showing the problem is surely not based on DNS resolving issues, because a Windows PC can connect properly. (also through Pi-Hole)

So maybe the issue is Mac OS related. But maybe someone anyways can help me solving it...

https://www.mankier.com/8/vfs_fruit

Thank you so much! I will try that tonight but I am quite optimistic it'll work.