|
Apologies for long post incoming, but if anyone has a few minutes I could use some expertise. I'm having a hell of a time trying to shake this 403 error I'm getting when trying to access my self-hosted apps using my domain name, and I'm not even sure which part of my setup could be the culprit. My goal is to route my nextcloud container through nginx proxy manager using my domain name, so I can easily access nextcloud outside my LAN. I am running Fedora Server in a VM on TrueNAS Scale. I set up the network bridge between the VM and the TrueNAS storage and connected them with an NFS share. So far, I have my containers up and running for npm, cloudflare DDNS, and nextcloud all using podman compose, and I attached my domain's nameservers to my cloudflare account. I can access nextcloud ok using my.internal.ip.address:8080 but trying to access it using nextcloud.mydomain.com always returns a 403 error. I understand this could be due to a wide variety of things, so I'm trying to rule stuff out. I have checked the logs for all containers, and none contain error messages. The cloudflare DDNS container logs show that it is successfully updating my public IP address to my domain. Then in my cloudflare DNS records I have a CNAME of my subdomain pointing to my domain name as well as an A record of my domain pointing to my public IP address. To try to rule out DDNS as the problem I also tried disabling DDNS and making an A record called nextcloud with content set as my public IP address. When I ping nextcloud.mydomain.com from my server it is successful, and the IP address listed is my public IP address. I used netstat to verify my server is listening on ports 80 and 443. In my router software, I forwarded them to my VM IP address. I also turned firewalld and SELinux on and off to no effect. In netstat I found that ports 80 and 443 were being listened to by something called 'rootlessport.' I know this is related to podman, and wasn't sure if this needed extra configuration. So I respun up all of the containers in docker instead. The result was the same. I can add nextcloud.mydomain.com as a proxy host in nginx proxy manager, and successfully add the let's encrypt ssl cert. I don't see anything going wrong with the process inside npm until I try to access my domain. To try to rule out any problems with nextcloud, I tried to set up npm.mydomain.com and forward port 81 to access nginx proxy manager webui and got the same 403 error. Originally I thought the problem could be related to permissions. For npm, my understanding is that there are three places where you can set the user. There is the nginx.conf file inside the /etc directory within the container, there's the docker compose yaml, and there is the config.json file that sits adjacent to the docker compose file. I'm not exactly sure how permissions work, but I did set all three of these to the same user. And added the fedora vm user to the docker group. I originally had some problems here, but now the containers don't have any issues creating their necessary directories and files on the fedora side of the volume mapping. Since I get the same 403 nginx error when I try to access my domain even when I don't have any proxy host defined in nginx proxy manager at all, I thought there might be some kind of problem with the way I am defining my proxy host. I knew there was some other way to configure this where you can simply set the container name as the forward hostname instead of using the IP address. So I defined the same network for each service in each podman compose yaml, and set the alias for each service. Then I tried using myalias.mynetwork as the forward hostname when defining my proxy hosts in npm. This also didn't change anything. Thinking the problem might be related to my domain somehow, I tried to redo the whole process using DuckDNS as my DDNS service rather than using Cloudflare and my domain. I setup my DuckDNS account, spun up my DuckDNS container, set the DuckDNS proxy host in npm, everything appeared to be in working order with no errors, DuckDNS was listening to my public IP address, but when I would go to mydomain.duckdns.org in browser it would time out rather than display the nginx congratulations page. One last thing, I have Fedora running on my desktop as well. So I installed all the bits, spun up the npm container on my desktop, and made the proxy host which also resulted in 403. It makes me think my router is the problem, but forwarding ports is pretty straightforward, and I'm not sure what else could be the problem on that level. I did host an Astroneer server just a few months ago which required forwarding ports and that all went fine, so I don't have any cgnat or complex hardware configurations that would prevent ports from opening. As for other options, tailscale would be a viable alternative, except I need my files accessible from the web on computers that aren't able to have a tailscale client installed on them. Cloudflare tunnels also seem to have a restrictive TOS that would be incompatible with services such as nextcloud, and even though enforcement seems spotty, I don't want to rely on poor TOS enforcement for my services to work. TrueCharts was giving me the same problems when I had tried it earlier, but I wasn't sure if that was due to something completely different since I found it a bit opaque. It's not the ideal solution anyway since the app library is so limited compared to linux and the updates that cause breaking changes are a pain in the rear end. Perhaps I would be better served doing this a completely different way, but before I try to learn caddy/opnsense/nixos I'd like a better understanding of what exactly my problem is. I'm trying to learn this as I go, and boy do I feel like I learned a lot. Still didn't get anywhere though. I think there might be a gap in my knowledge somewhere, and now I'm completely out of ideas. If anyone could tell me what to do next, or if any of the above sounds wrong, I'd really appreciate it.
|
#
¿
Feb 28, 2024 20:41
|
|
|
|
| # ¿ Apr 28, 2024 23:21 |
|
|
That's fair. I have only posted after I thought I had isolated every variable I could think of, only to find myself back where I started with no more leads. Instead, I'll try using a fresh bootable usb drive to create the simplest setup that I can, and see where that goes.
|
|
#
¿
Feb 29, 2024 01:23
|
|