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.
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
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?
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?
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
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...