WeDevs

Members
  • Posts

    1
  • Joined

  • Last visited

WeDevs's Achievements

Noob

Noob (1/14)

0

Reputation

  1. I have the exact same problem with the exact same setup. Nextcloud + mariaDB + Swag. Recent update by auto-app-updates killed nextcloud. I've confirmed swag is fine, there was a new /config/nginx/proxy.conf file pushed but i tested out old & new one. No difference (the change was to set a header to blank, this was to fix a security issue). Based on logs that this person and I am seeing I assume its something to did with PHP. I know there was a PHP8 version in the works but checking the default/normal nextcloud php version shows its PHP 7.4.25 so it shouldn't be a bad PHP upgrade? I looked through https://github.com/linuxserver/docker-nextcloud/releases and couldn't find anything that stood out, seems everything is just re-basing to latest alpine release. In the Nextcloud GUI I was already up-to-date as of at least 1-2 weeks ago. I tried downgrading the docker image from latest (== 22.2.0-ls160) to 22.2.0-ls156 which is from about 1 month ago but that didn't help either. I'm out of idea's. PHP error logs don't show anything useful. Update 1) changing log level to "debug" for php7 does not show any more information. I guess crash/shutdown happens too quickly. I looked at logs from 1 month ago and they are the same as today/OP in regards to fpm shutting down. Nextcloud was working at that time. I saw a warning regarding increasing max children in those older logs. I just increased pm.max_children = 300 from the default 5. Its the only thing i could see in the past logs. Didn't make a difference. Update 2) I think it might be caused by DNS but still investigating. I use pihole for DNS. /etc/resolve.conf in nextcloud has the correct local DNS server IPv4 address. When i try to ping local servers using their local DNS entries in pihole (from within nextcloud docker container), it fails to resolve. I know pihole DNS entries are working in my web browser it should not be caused by pihole. I also see HTTP 302's in nextcloud logs (as there should be) but no errors. Update 3) Probably not a DNS issue. Ran NSLookup from within containers and they can resolve DNS address just fine. If i go to Nextcloud WebUI from within unraid-->docker menu it goes to unraid IPv4:<nextcloud port>. This is good. This then redirects to correct DNS address as configured in nextcloud. That is a SWAG docker container within unraid. This container runs on custom network using macvlan driver (so it can get its own IPv4 static address from home router). Swag acts as reverse-proxy for nextcloud. Looking at its logs it says "2021/11/01 09:49:43 [error] 497#497: *1 connect() failed (111: Connection refused) while connecting to upstream," for <unraid Ipv4>:<nextcloud_port-mapping>. All address and DNS stuff looks correct. I tried curl from SWAG container to unraid GUI, it failed. I tried to <unraid Ipv4>:<nextcloud_port-mapping> and it failed. Possibly issue with networking between SWAG & unraid. Update 4) Logs and tests seem to show that my swag container cannot reach unraid IPv4 address. I thinking the custom/special network I created for the swag container will probably need to be recreated. Maybe there was some docker or unraid update that modifying some default settings? Because Swag cannot reach the UnRaid host IPv4 address it cannot act as a reverse proxy. Update 5) Turned docker on/off from UnRaid GUI. This seemed to fix whatever weird issue caused swag not to be able to access UnRaid IPv4 address. I guess the solution of turn it off & on is still the best solution that exists. I was just turning off/on the wrong things. (Note i did enable the docker option of preserving user networks at startup. This shouldn't matter because i didn't create any networks).