Thanks. That seems to be a similar, but slightly different error. I think the below may apply though.

I believe I’ve tracked down more of my issue, but fixing it is going to be a hassle:

When cloudflare proxying is enabled, there are 3 DNS records involved; A record with cloudflares ipv4, AAAA record with cloudflares IPV6, and the key to this puzzle: an HTTPS record with cloudflares ech/https config.

With pihole I can set DNS records for A/AAAA, but I have no way of blocking/setting the HTTPS record so it gets through from cloudflare.

The LAN A/AAAA records don’t match the HTTPS record from cloudflare, so browsers freak out.

Once I disabled cloudflares proxying, I no longer get HTTPS records returned and all works as intended.

I’ll either have to keep cloudflare proxying disabled, or switch pihole out for a more comprehensive DNS solution so I can set/block HTTPS records :(

Thank you @bobslaede@feddit.dk for pointing me in the right direction.

Added an AAAA record to pihole:

ombi.mydomain.example 0000:0000::0000:0000

Now nslookup returns the correct ipv4 address, and ‘::’ as the ipv6.

We’ll see if that works.

Crap, looks like that’s exactly what it is.

Now how to fix that…

I do have external acces to Ombi via cloudflare; but the device I’m seeing this problem on is permanently connected to a VPN hosted from the same server machine as ombi/nginx with ‘block all connections without VPN’ enabled. And this testing has been done from within the same LAN.

It should never see/reach cloudflare for this service.

/edit; I’ve also disabled ‘use secure DNS’ in chrome. I host a local DNS within that lan/vpn network.

Yup. Point is; if you’re not depending on just its login page to keep it secure, there’s not a whole lot needing ‘security patches’, so I wouldn’t be all that concerned about slow updates. As long as it remains bug free, I’m happy.

And security patches

Something with the power of dockge should be behind a seprate form of authentication imo.

I only access it via VPN, it’s not exposed to WAN.

I tend to just use FolderSync myself. To avoid battery issues, I have a schedule for most folders; but my DCIM/Pictures folders sync immediately upon changes. I then have a widget on my homepage that triggers a ‘sync all’. Anytime I need files synced immediately, it’s easy enough to click that button.

If you use usenet, many indexers have a requests section. I’ve had a couple filled at NZBgeek in the past.

Having to peal your ass cheeks apart to take a shit seems really unpleasant…

Just this week, I setup Homepage to monitor my server and its various docker containers at a glance, including cpu/ram/network usage and a whole bunch of information pulled from their APIs (such as how many itemes are actively downloading via sonarr+sabnzbd, or how many queries were blocked by pihole today).

That in turn lead me too Glances, both as various widgets in Homepage as well as a stand alone tool.

Note: Homepage doesn’t come with authentication. You’ll have to handle that yourself via a reverse proxy or vpn. Glances has an optional login page you can enable, but I haven’t explored that. I access services like these by connecting to my network through OpenVPN.

what does not work:

• i can not ping server.local (- for testing i have to stop the systemd-resolved.service to run the dnsmasq server, or else there are port collisions, but that should not be the problem i guess. I am happy to hear your solution :))
• i can also not use ssh to log in to server.local, ip address works

Have you added “server.local” as a DNS record in your dnsmasq container, pointing to your servers LAN IP? Sounds like dnsmasq isn’t resolving that name, which would lead to both of these ‘failures’.